ARIA (Accessible Rich Internet Applications)
ARIA (Accessible Rich Internet Applications) is the W3C specification for adding accessibility semantics to web content when native HTML cannot express them. ARIA defines roles, states, and properties that assistive technologies (screen readers, voice control software) use to understand interactive content. ARIA 1.2 is the current standard (June 2023).
Also called: WAI-ARIA, ARIA roles, ARIA attributes · Last updated: May 27, 2026 · By Joseph W. Anady
Why it matters.
ARIA bridges the gap between dynamic JavaScript-driven web applications and assistive technologies. Native HTML elements (button, link, input, etc.) carry built-in accessibility semantics. Custom interactive widgets built with divs and spans lack those semantics — ARIA fills the gap. But ARIA is also widely misused, which can make accessibility worse than no ARIA at all.
How it works.
ARIA adds three categories of attributes: roles (declare what an element is — role='button', role='dialog'), states (declare current state — aria-expanded='true', aria-checked='false'), and properties (declare semantic relationships — aria-labelledby, aria-describedby, aria-controls). Screen readers and other AT use these to provide accurate information to users about page structure, interactive elements, and dynamic changes.
2026 reality check.
ARIA usage has become more disciplined post-2024. The 'no ARIA is better than bad ARIA' guidance has spread. Modern frameworks (React with proper button components, headless UI libraries like Radix) handle ARIA correctly by default. The remaining ARIA failures usually trace to: misused role='button' on divs (without keyboard handlers), missing aria-label on icon-only buttons, incorrect aria-expanded state management on accordions.
Data points
- ARIA 1.2 W3C Recommendation June 2023
- Three categories: roles, states, properties
- First rule of ARIA: don't use ARIA when native HTML expresses the pattern
- Maintained by W3C Web Accessibility Initiative (WAI)
- Misused ARIA is more harmful than no ARIA (broken semantics worse than missing semantics)
First-hand insight from ThatDeveloperGuy.
ThatDeveloperGuy applies the first rule of ARIA religiously: 'don't use ARIA when native HTML can express the pattern.' Most TDG sites use ARIA sparingly — semantic HTML5 elements (header, nav, main, button, dialog) carry the necessary accessibility. ARIA is added only for custom widgets where native HTML truly cannot express the pattern (custom dropdowns, tab panels, modal dialogs, complex tree views). Misused ARIA is more common than missing ARIA — being conservative is the safer practice.
How TDG approaches it
TDG's ARIA discipline: native HTML5 first, ARIA only for custom widgets that genuinely require it, ARIA state management synchronized with visual state (aria-expanded matches accordion open/closed), aria-label on icon-only interactive elements, aria-hidden only on decorative elements that are also not interactive. Automated CI testing via axe-core catches the most common ARIA mistakes.
Common mistakes.
- Adding role='button' to a div without also adding keyboard event handlers
- Using ARIA to override native HTML semantics (don't add role='img' to a button)
- Forgetting to update aria-expanded state when toggling accordions/menus
- Missing aria-label on icon-only buttons (screen reader announces 'button' with no purpose)
- Adding aria-hidden='true' to interactive elements (hides from AT but not from keyboard focus — broken state)
FAQ.
When should I use ARIA?
Only when native HTML cannot express the pattern. Use button, not div role='button'. Use heading elements, not div role='heading'. Use form fields, not div role='textbox'. Reserve ARIA for custom widgets where no native HTML equivalent exists.
What's the most common ARIA mistake?
Adding role='button' to a div without keyboard event handlers. The role declares 'this is a button' but native keyboard behavior (Enter/Space to activate) is missing. Always pair ARIA with the JS to make the pattern functional.
Does ARIA improve SEO?
Indirectly. Better accessibility correlates with better SEO via Page Experience signals and lower bounce rates. ARIA itself isn't a direct ranking factor.
Should I add ARIA labels to everything?
No. Native HTML elements (button, link with text content, input with label) already have accessible names. Adding redundant aria-label can confuse screen readers. Use aria-label only when native naming is insufficient.
What's the difference between aria-label and aria-labelledby?
aria-label provides the accessible name directly (aria-label='Close dialog'). aria-labelledby references another element's text as the accessible name (aria-labelledby='dialog-title'). Use labelledby when the visible text serves as the label.
Maintained by Joseph W. Anady at ThatDeveloperGuy. Back to glossary · Suggest a term