Accessible Rich Internet Applications — a set of HTML attributes that communicate the role, state, and properties of dynamic interface elements to assistive technologies like screen readers. ARIA bridges the gap when standard HTML semantics don't adequately describe the purpose of interactive components, but should only be used when native HTML falls short.
Common contexts
- Adding aria-expanded and aria-controls to a custom accordion component built with divs
- Marking a modal dialog with role='dialog' and aria-labelledby to give it a proper screen reader context
- Annotating a live search results region with aria-live so screen readers announce updates
Use when
Reach for ARIA only when you're building a custom interactive widget — a datepicker, a combobox, a drag-and-drop list — that native HTML can't express. Before adding an ARIA attribute, confirm whether a semantic HTML element like <button>, <select>, or <fieldset> would do the job with zero JavaScript.
Avoid when
Bad ARIA is significantly worse than no ARIA — adding incorrect roles or states to elements actively misleads screen readers and creates a broken experience for blind users. Never add ARIA attributes speculatively to 'help' with accessibility if you haven't tested the output with an actual screen reader.
The first rule of ARIA is to not use ARIA — native HTML semantics are more robust, better supported, and require no maintenance compared to custom attribute implementations.
Real-world examples
- Twitter's web app uses ARIA live regions to announce new tweet counts to screen-reader users without requiring a page refresh.
- Google Docs applies ARIA roles and labels to its custom toolbar controls so assistive technologies can identify Bold, Italic, and other non-native buttons.
- Airbnb's date-picker uses ARIA attributes to communicate selected dates and available ranges to users navigating with a keyboard and screen reader.