What Is ARIA? Semantics for Accessible Interactive Components
ARIA is a set of roles, states, and properties that help assistive technologies understand complex or custom interactive components. Learn when to use ARIA and when native HTML is better.
Key Takeaways
- No ARIA is better than Bad ARIA.
- This W3C APG reminder matters because incorrect ARIA can misrepresent an interface to assistive technologies.
- ARIA stands for Accessible Rich Internet Applications and is often written as WAI-ARIA.
- ARIA adds roles, states, and properties that help assistive technologies understand custom components.
- ARIA is not a universal fix. Use native HTML first whenever it provides the needed semantics and behavior.
What does ARIA mean?
ARIA is a set of W3C WAI specifications that adds semantic information for complex web applications. When developers build custom controls with div, span, or JavaScript, browsers and assistive technologies might not know whether something is a button, tab, dialog, or live region.
ARIA can provide extra semantics and state through attributes such as role, aria-expanded, aria-controls, aria-live, and aria-label.
Use native HTML first, then ARIA
The most important practical rule is: use native HTML first. Native button, input, select, dialog, and anchor elements often provide built-in keyboard behavior, roles, and states that browsers and assistive technologies understand.
If you use a div with role="button", you still need to implement keyboard behavior, focus management, disabled states, names, and interaction feedback yourself. Missing any of those details can create new accessibility problems.
Common ARIA uses
ARIA is useful when native HTML cannot fully express a complex interaction, such as tabs, disclosure widgets, dialogs, menus, live updates, and custom component states.
- role: communicates what kind of component something is.
- aria-label / aria-labelledby: provides an accessible name.
- aria-expanded: communicates whether content is expanded.
- aria-controls: connects a control to the content it controls.
- aria-live: announces dynamic updates.
- aria-describedby: connects help text or errors.
Incorrect ARIA can make things worse
ARIA changes the semantics exposed to assistive technologies, but it does not automatically add behavior. role="button" does not automatically support Enter or Space. aria-expanded does not automatically expand content.
Incorrect ARIA can make screen reader users hear the wrong role, state, or name. That can be worse than having no ARIA at all. ARIA needs to be tested with real interaction, keyboard behavior, and screen readers.
ARIA checklist
When checking ARIA, do not only check whether attributes exist. Confirm that they match the actual behavior and state.
- Can native HTML be used instead?
- Does the component have a correct accessible name?
- Does the role match the actual interaction pattern?
- Do states such as aria-expanded, aria-selected, and aria-current update correctly?
- Does keyboard behavior match user expectations?
- Is focus managed correctly?
- Can screen readers understand the name, role, state, and description?
Frequently Asked Questions
Can ARIA fix all accessibility problems?
No. ARIA mainly provides semantic and state information. It does not automatically add keyboard behavior, focus management, visual cues, or content quality.
When should ARIA not be used?
When native HTML already provides the correct semantics and behavior, ARIA usually should not replace it. Incorrect or unnecessary ARIA can confuse assistive technologies.
How does ARIA relate to screen readers?
ARIA affects the name, role, state, and description exposed to screen readers. It can help users understand custom components, but only when it matches the actual interaction.