ARIA attributes used in ways the role does not allow
Automated check aria-conditional-attr, run with axe-core
- WCAG
- 4.1.2 Name, Role, Value (Level A)
- Severity
- Serious: completable, but painful
- Typical effort
- Moderate, 1 to 4 hours
- Category
- Code quality
Who this affects
Screen reader users.
Why it matters
Some ARIA attributes are only valid in certain situations, for example aria-checked on a native checkbox. Misused, they make assistive technology announce a state that contradicts what is on screen.
How to fix it
Remove the conflicting attribute and let the native element convey its own state, or adjust the markup to the pattern the role expects.
Check your own website
The free scan tests 3 pages against WCAG 2.2 A and AA in about 30 seconds. No sign-up.
Related checks: Code quality
- ARIA attributes used on the wrong elements
- ARIA roles that do not suit the element
- Braille-only ARIA attributes have no spoken equivalent
- Deprecated ARIA roles are used
- The page body is hidden from assistive technology
- ARIA labels placed on elements that cannot carry them
- ARIA roles are missing their required attributes
- Menus, lists or tabs are missing their required child elements