Avoid ARIA attributes that are prohibited for an element’s role
Accessibility isn’t only about avoiding violations — it’s about ensuring your product can be used confidently by everyone. This guide explains the principle of this rule, shows what goes wrong in real-world code, and provides a verified fix that meets WCAG and the European Accessibility Act (EAA).
Why this matters and how to fix it
Why this matters
Each ARIA role defines a specific set of supported and prohibited attributes. Adding attributes that are not allowed for a given role can create conflicting semantics. Assistive technologies may ignore or misinterpret the element entirely, resulting in unpredictable or inaccessible behavior.
How to fix this issue
Review the WAI-ARIA 1.2 specification for valid attribute-role pairings. Remove any disallowed attributes or change the element’s role to one that supports them. Prefer using native HTML elements instead of trying to fix semantic mismatches with ARIA attributes.
Developer guidance
This issue often occurs when developers attempt to customize interactions or repurpose components without checking the ARIA spec. Include ARIA validation rules in your linter and accessibility QA process. Tools like axe-core or the ARIA Authoring Practices Guide validator can detect prohibited combinations automatically.
Code examples
Incorrect Implementation
<button aria-checked="true">Submit</button>Correct Implementation
<button>Submit</button>
Trusted by organizations across Europe working toward WCAG and EAA conformance