ARIA
ARIA attributes must be allowed on their role
- Rule:
aria-allowed-attr - Severity: Critical
- WCAG level A
Why it matters
An attribute the role does not support is ignored by some assistive technology and misread by the rest, so the control announces a state it is not really in.
How to fix it
- Look up which aria-* attributes the element’s role supports and remove the rest.
- If the state you need is not supported, the role is probably wrong — pick the role that owns that state.
- Prefer a native element (button, input, select) which carries the right states for free.
In markup
<div role="button" aria-checked="true">Bold</div><div role="button" aria-pressed="true">Bold</div>The requirement behind it
This rule is one way of failing the following WCAG 2.2 success criteria. The W3C, which writes the standard, explains each of them:
- 4.1.2 Name, Role, Value (opens in new tab) — WCAG level A
Further reading
Deque University on aria-allowed-attr (opens in new tab)
Deque maintains axe-core, the open-source engine our scanner runs. Their page documents the rule as the engine implements it.
Automated checks find failures a browser can prove. They cannot judge whether a caption is accurate, whether an alt text is useful, or whether a page can be operated end to end with a keyboard — those need a person.