ARIA: Accessible Rich Internet Applications

What is ARIA?

ARIA (Accessible Rich Internet Applications, also written WAI-ARIA) is a W3C specification of HTML attributes that tell assistive technology what an element is, what state it is in and how it relates to other elements. It exists for custom widgets that plain HTML cannot describe, such as tabs, comboboxes and live-updating regions.

ARIA changes only what assistive technology is told. It adds no behaviour: it does not make an element focusable, clickable or keyboard-operable. That still needs HTML and JavaScript.

Roles, states and properties

WAI-ARIA 1.2, the current W3C Recommendation, defines three kinds of attribute:

• Role: the main indicator of what an element is, for example role="tablist" or role="dialog".
• Property: a characteristic of the element that changes rarely, for example aria-label or aria-controls.
• State: a characteristic that changes with user action or script, for example aria-expanded or aria-checked.

The rules of ARIA use

W3C's "Using ARIA" guidance sets out four rules. The first one is the one most often broken:

1. Use native HTML first. If an element or attribute already has the semantics and behaviour you need, use it instead of adding ARIA to something else.
2. Do not change native semantics unless you really have to.
3. All interactive ARIA controls must be usable with the keyboard.
4. Do not put role="presentation" or aria-hidden="true" on a focusable element, or users land on something that seems to be nothing.

<!-- Native: no ARIA needed -->
<button type="button">Save</button>

<!-- Avoid: a div pretending to be a button -->
<div role="button" tabindex="0">Save</div>

The native button is focusable, responds to Enter and Space and is announced correctly with no extra work. The div needs all of that rebuilt by hand. A screen reader only announces what the markup tells it.

Example: a disclosure button

A button that shows and hides a panel is a case where ARIA adds real value, because HTML alone cannot say whether the panel is open:

<button type="button" aria-expanded="false" aria-controls="faq-1">
  Shipping details
</button>
<div id="faq-1" hidden>Orders ship within two days.</div>

Your script must flip aria-expanded to true when it removes hidden, and back again when it closes. For icon-only controls, a name from aria-label is needed:

<!-- Icon-only button: no visible text, so it needs a name -->
<button type="button" aria-label="Close dialog"><svg aria-hidden="true">...</svg></button>

Common roles and live regions

• dialog for modal dialogs, tablist, tab and tabpanel for tabs, combobox for autocomplete fields.
• Landmarks such as navigation and main, which native <nav> and <main> already provide.
• aria-labelledby and aria-describedby to point at visible text that names or explains an element.
• aria-current="page" to mark the current link in a navigation.

Live regions announce changes the user did not trigger by moving focus. role="status" is polite and waits for current speech; role="alert" is assertive and interrupts, so keep it for errors that need immediate attention.

<div role="status">Draft saved</div>
<div role="alert">Connection lost</div>

Common mistakes

• ARIA instead of the right element. The most common one: a div with a role where a button, link or select would do.
• Roles with no keyboard support. A role="tab" without arrow-key handling is announced as a tab and behaves like nothing.
• Stale states. aria-expanded="false" left in place after the menu opens tells users the opposite of what they see.
• Hiding focusable content. aria-hidden="true" on a button or link leaves it reachable by keyboard but silent.
• Labels that contradict visible text. If a button reads "Search" but its aria-label says "Go", voice-control users cannot say what they see. See also accessible forms.
• Never testing with assistive technology. Valid markup does not guarantee a sensible announcement.

ARIA and accessibility testing

ARIA is one part of meeting WCAG, since several success criteria depend on elements exposing a name, role and value. Automated tools catch ARIA misuse that can be checked from markup alone: invalid role values, attributes not allowed on a role, or aria-hidden on focusable elements are all in the Lighthouse accessibility score. They cannot judge whether a widget works, so pair them with keyboard testing, a screen reader pass and automated accessibility testing in CI. Our accessibility testing tools comparison covers the options. LoadFocus page speed monitoring records the Lighthouse Accessibility category with every audit, so you can track the score over time.

FAQ: ARIA

What is the first rule of ARIA?

Use a native HTML element or attribute that already provides the semantics and behaviour you need, rather than repurposing another element and adding ARIA. Native elements come with keyboard support and correct announcements built in.

Does ARIA make an element keyboard accessible?

No. ARIA only changes how an element is described to assistive technology. Focus, key handling and behaviour still have to be built with HTML and JavaScript.

Is no ARIA better than bad ARIA?

Often yes. Incorrect roles and stale states can leave users worse off than plain, correct HTML. Add ARIA when native HTML cannot express the widget, and test it.

What is the difference between aria-label and aria-labelledby?

aria-label supplies the accessible name as a text string. aria-labelledby points to the id of another element whose visible text becomes the name. Prefer visible text where you can.

Where do I find tested ARIA patterns?

The W3C ARIA Authoring Practices Guide (APG) describes design patterns for common widgets, with functional examples for each. Follow a pattern rather than inventing keyboard behaviour.