ARIA: When to Use It and When Not To
Attributes that describe roles, states and properties to assistive technology, for cases where native HTML cannot.
Marcus Adeyemi
Why does it matter?
ARIA is powerful and frequently makes accessibility worse, because incorrect ARIA overrides correct native semantics.
What are the numbers?
- First rule of ARIA do not use ARIA if a native element will do
- Effect ARIA changes what is announced, not how anything behaves
- Keyboard behavior must be implemented separately
- Common misuse roles applied to elements that already have them
- Authoring practices the W3C publishes patterns for common components
What should I do?
- Use native elements wherever one exists
- Follow the published authoring practices for custom components
- Implement keyboard behavior alongside any ARIA role
- Test with a screen reader after adding ARIA
- Remove ARIA that duplicates native semantics
What should I avoid?
Avoid:
- role=button on a button element
- ARIA added without the corresponding keyboard behavior
- Inventing roles and patterns rather than following published ones
- Using aria-hidden on focusable content
When should I get help?
Short answer Bring in help when custom components need building accessibly, when ARIA has made things worse, or when an audit has flagged incorrect roles across a library.
Where this comes from
- W3C Web Accessibility Initiative — ARIA Authoring Practices
- MDN Web Docs — ARIA reference
- Deque University — ARIA usage
The figures and practices above come from the sources listed.
Working on something like this?
We take on Performance & Accessibility work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.
Where to go next
Spotted something wrong? Report an error on this page. We correct on the page and say what changed.
