Use ARIA attributes only when allowed for a 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
Misusing ARIA attributes can create contradictory signals for assistive technologies. For instance, using aria-label on a purely decorative element or combining mutually exclusive attributes can confuse screen readers. When assistive technology receives inconsistent semantics, it might misrepresent the structure or purpose of the interface, reducing both usability and accessibility.
How to fix this issue
Validate your ARIA attributes against the role’s specification. Remove attributes that are not permitted for the element or role, and always prefer semantic HTML when possible. Use automated accessibility testing tools to detect invalid ARIA combinations. If the component must remain custom, verify with real assistive technologies that behavior and context are consistent.
Developer guidance
Conditional ARIA misuse typically happens when attributes are applied programmatically without role validation — for example, when component props dynamically spread accessibility attributes. Build safeguards in your component architecture to ensure ARIA properties are type-checked and documented. Use static analysis or schema validation to detect incompatible attribute-role pairings before runtime.
Code examples
Incorrect Implementation
<div role="presentation" aria-label="Info"></div>Correct Implementation
<div aria-label="Info"></div>
Trusted by organizations across Europe working toward WCAG and EAA conformance