ARIA, short for Accessible Rich Internet Applications, is a W3C specification that defines roles, states and properties which authors add to markup to tell assistive technologies what an element is, what condition it is in and how it relates to other elements. In accessibility, ARIA fills the gap when native HTML cannot express the semantics of a custom widget such as a tab panel, a combobox or a live notification.
ARIA changes only the accessibility tree, the structure that browsers expose to screen readers and other assistive technologies. It does not add behavior, styling or keyboard support. That single fact explains both its power and most of the errors made with it.
How ARIA works in the accessibility tree
Browsers build an accessibility tree in parallel with the DOM. Each node has a role, an accessible name, optional states and properties, and relationships to other nodes. Platform accessibility APIs pass this information to screen readers, voice control software and switch devices.
Native HTML elements populate the tree automatically: a button element receives the role button, its text becomes the accessible name, and the disabled attribute becomes a state. When a developer builds a control from a generic div, the tree contains no useful semantics. ARIA attributes overwrite or supplement those values, so a div with role="button" is announced as a button.
The crucial limitation is that the browser does not supply the matching behavior. A real button is focusable, responds to Enter and Space and submits forms; an ARIA button does none of this unless the author adds tabindex="0" and keyboard event handling in script.
Roles, states and properties
ARIA attributes fall into three categories. Roles define what an element is, while states and properties describe its current condition and characteristics. States usually change during interaction, and properties tend to stay stable.
| Category | Purpose | Examples |
|---|---|---|
| Widget roles | Identify interactive controls | button, checkbox, tab, slider, combobox, menuitem |
| Composite roles | Group widgets that manage focus together | tablist, menu, listbox, grid, tree |
| Landmark roles | Mark page regions for navigation | banner, navigation, main, complementary, contentinfo |
| Live region attributes | Announce dynamic content changes | aria-live, aria-atomic, role status, role alert |
| States | Describe changing conditions | aria-expanded, aria-checked, aria-selected, aria-invalid |
| Properties | Describe names, relations and constraints | aria-label, aria-labelledby, aria-describedby, aria-controls |
Naming attributes deserve special attention because every interactive element needs an accessible name. The browser computes it in a defined order: aria-labelledby first, then aria-label, then native labeling such as a label element or the element’s text content. Using aria-label on an element that already has visible text can create a mismatch between what is seen and what is announced, which breaks voice control commands.
Live regions use two politeness levels. aria-live="polite" waits until the screen reader finishes speaking, while aria-live="assertive" interrupts immediately and should be reserved for urgent messages such as errors that block progress.
The rules of ARIA use
The W3C guidance on using ARIA summarizes good practice in a short set of rules. The first is widely quoted: if a native HTML element provides the needed semantics and behavior, use it instead of repurposing an element and adding ARIA.
| Rule | Meaning | Typical violation |
|---|---|---|
| Prefer native HTML | Use button, a, input, select, details before ARIA | div with role button and click handler only |
| Do not change native semantics | Avoid overriding an element’s built-in role | h2 with role tab instead of a nested element |
| Make controls keyboard operable | Every ARIA widget must work without a mouse | Custom menu reachable only by pointer |
| Do not hide focusable elements | Never apply aria-hidden true to focusable content | Hidden close button still receives focus |
| Provide an accessible name | Every interactive element needs a name | Icon-only button with no label |
A common shorthand states that no ARIA is better than bad ARIA. A wrong role or a stale state actively misleads users, whereas a missing role at least leaves the native semantics intact.
ARIA in relation to WCAG and native HTML
ARIA is a technique, not a conformance standard. WCAG defines outcomes to achieve, such as success criterion 4.1.2 on name, role and value, and ARIA is one of several ways to meet them in custom components.
| Concept | What it is | Relationship to ARIA |
|---|---|---|
| Native HTML semantics | Built-in roles and behavior of elements | First choice; ARIA supplements it |
| WCAG | Testable accessibility success criteria | ARIA helps satisfy name, role and value requirements |
| ARIA Authoring Practices | Design patterns for common widgets | Shows expected roles and keyboard models |
| Accessible name | Text that identifies an element to assistive technology | Set or referenced through ARIA naming attributes |
| Screen reader | Software that speaks or brailles the interface | Consumes the semantics ARIA exposes |
The ARIA Authoring Practices Guide is particularly useful because it defines keyboard interaction models. A tablist, for example, expects arrow keys to move between tabs and Tab to move into the panel, a convention screen reader users rely on across sites.
Common mistakes and how to test
Most ARIA defects come from adding attributes without matching behavior or from states that are not updated when the interface changes. Automated checkers catch invalid attribute values, but they cannot judge whether the announced meaning matches reality.
- Static states: aria-expanded stays false after a menu opens because script never updates it.
- Redundant roles: role button on a native button adds nothing and signals uncertain code.
- Overused aria-label: labels on non-interactive elements such as generic div or span are ignored by many screen readers.
- aria-hidden on a parent of focusable content, which produces focus on invisible elements.
- Copying widget roles such as menu for ordinary site navigation, which forces an application keyboard model on simple links.
Reliable testing combines automated scanning, keyboard-only navigation and manual screen reader testing with at least two common screen reader and browser pairings, because support for newer attributes still varies between combinations.
The short version
ARIA is a set of labels that developers attach to parts of a web page so that assistive software understands them. A blind person using a screen reader cannot see that a box looks like a button. ARIA tells the software that it is a button and whether it is pressed.
The labels only describe things. They do not make anything work. A developer who adds the button label must still make the element respond to the keyboard. That is why plain, standard page elements are usually the safest choice.
Where it makes a difference
An online banking team builds a custom accordion for frequently asked questions using clickable div elements. A screen reader user hears only plain text, cannot tell that the questions expand, and cannot open them with the keyboard. An accessibility audit flags a failure of WCAG criterion 4.1.2.
The team replaces each clickable div with a native button inside the heading and adds aria-expanded and aria-controls, updating the state in script whenever a panel opens. Keyboard users can now reach every question with Tab, screen reader users hear “button, collapsed” and “button, expanded”, and retesting with two screen readers confirms that the issue is resolved with fewer lines of code than the original.