In one paragraph
Elements must only use supported ARIA attributes means an otherwise recognised property is not supported in the tested role context. Choose semantics from the actual function and use the matching state model. A valid attribute name and token do not make the combination correct. Do not change a role merely to permit an attribute without implementing the required interaction and relationships.
Why it matters
Properties are associated with specific roles and native semantics. A toggle button and a checkbox both express choices, but do not automatically use the same state property. A tab's selected state belongs within a complete tab model, not an arbitrary button that only looks like a tab.
The goal is a coherent contract between visible behaviour and accessibility exposure. Changing aria-checked to aria-pressed can be correct for a true toggle button, but not if the application actually needs a switch or a radio group.
This is separate from prohibited naming, misspelled attributes, invalid values, and missing required properties. Even properties often described as global need review against applicable host-language constraints and current specification status rather than a blanket claim that all are permitted everywhere.
How WebAuditOS evaluates this finding
The supplied aria-allowed-attr implementation compares applicable declared properties with the effective explicit or implicit role and its known supported set, including documented exceptions and review paths.
Critical impact maps to high severity. Some custom-element or deprecated-property cases can be returned for review and omitted from the violations report. A pass does not establish correct role selection, accurate state, keyboard operation, or broad user-agent support.
How to fix it
- Identify the actual control and desired user interaction. Inspect the native element, computed role, and current property values rather than choosing a state based only on a design-system name.
- Use a native control when it provides the intended semantics. Avoid replacing a working checkbox with a generic button merely because a library's default property is easier to change.
- For a real toggle button, an illustrative structure is:
<button type="button" aria-pressed="false">Bold</button>Its action must update the formatting and pressed state coherently. This example does not implement the handler or editor behaviour.
- For disclosure, selection, checked state, or numeric ranges, follow the complete applicable pattern. Names, ownership, focus, and required values differ; a supported property is only one piece.
- Remove meaningless state declarations from generic layout elements. If a component is genuinely interactive, provide the appropriate semantics and behaviour instead of leaving a styled div with unsupported properties.
- Fix the generating component so stale defaults are not emitted on every variant. A base component that spreads all ARIA props onto unrelated hosts can create systematic mismatches.
- Test initial and changed states through keyboard and pointer interaction. Compare visible behaviour, stored or submitted values, and computed accessibility information after each transition.
- Rescan related attribute and role checks, including conditional native-state restrictions. Keep specification and checker versions in view when a newly supported feature produces a compatibility warning.
What the fix can break
A property swap can change what assistive technology announces without altering application logic. Verify that the new declaration is truthful rather than merely accepted.
Changing the role can impose a different keyboard model and parent-child requirements. Do not solve one rule by creating an incomplete widget elsewhere.
Removing all ARIA indiscriminately can discard useful state on custom controls. Prefer targeted correction and native semantics where they actually fit.
Questions
Is this the same as an invalid attribute name?
No. A recognised name can be unsupported for a particular role. Vocabulary and compatibility are distinct checks.
Does every button use aria-checked?
No. A real toggle button commonly uses pressed state, while other choice patterns have different semantics.
Does a supported value prove it matches the UI?
No. Test behaviour and transitions separately from syntactic and role acceptance.
Which related checks help?
Review permitted attributes, conditional properties, and attribute names.
What severity does this get in the report?
High. An axe finding takes its severity from the impact axe reports for the element that failed, and the report maps critical and serious to high, moderate to medium, minor to low. This rule is declared critical in axe-core 4.13.0, so every failure arrives as high.