Q7 of 24 · Accessibility
What is ARIA and when is it appropriate to use it in your markup?
Short answer
Short answer: ARIA (Accessible Rich Internet Applications) is a set of HTML attributes that modify the accessibility tree — adding roles, states, and properties that native HTML elements don't express. Use it only when no native HTML element provides the correct semantics. The first rule of ARIA: no ARIA is better than bad ARIA.
Detail
ARIA fills the gap between what HTML natively expresses and what complex web applications need. A native <button> element has built-in role, keyboard behaviour, and state. A custom combobox, date picker, or tree widget has no HTML equivalent — ARIA is required to make it accessible.
When ARIA is appropriate:
- Adding live region behaviour to dynamically updated content (
aria-live="polite") - Expressing compound widget semantics that have no HTML equivalent (
role="tablist",role="tab",role="tabpanel") - Adding descriptions to form fields beyond the label (
aria-describedby) - Indicating expandable state (
aria-expanded) - Hiding decorative elements from assistive technology (
aria-hidden="true")
When ARIA is wrong:
- Using
role="button"on a div instead of using<button> - Adding
aria-labelto suppress a redundant icon label when the better fix is removing the icon's text from the accessibility tree - Adding roles that duplicate what HTML already expresses (
<nav role="navigation">— the nav element already has that role) - Adding ARIA without also managing the corresponding state (
aria-expandedon a button whose expansion state is never updated by JavaScript)
The danger of bad ARIA is worse than no ARIA: a role="button" on a <span> tells screen readers to expect button keyboard behaviour (Enter and Space activation), but without the event handlers that behaviour doesn't exist. The user is confused and stuck.