ARIA

WAI-ARIA — Accessible Rich Internet Applications — is a W3C specification that fills a specific gap: when native HTML elements aren’t enough to describe a custom UI control, ARIA provides a vocabulary of roles, states, and properties that assistive technologies (especially screen readers) can understand.

What ARIA is and isn’t

ARIA is a layer on top of HTML. It does not add behaviour. Putting role="button" on a <div> makes a screen reader announce it as a button, but it does not make the <div> focusable, doesn’t add keyboard handling, and doesn’t add the visual styling. You have to add all of that yourself.

This is the source of most ARIA bugs in production: developers add the role and stop, then ship a “button” that doesn’t respond to Enter or Space, isn’t reachable by Tab, and has no focus indicator.

The first rule of ARIA

If you can use a native HTML element with the semantics and behaviour you require, then do so.

Every line of ARIA you write is a line of HTML semantics you’ve decided to re-implement by hand. <button> already announces as a button, is focusable, responds to Enter and Space, and has a focus ring — for free. <div role="button" tabindex="0"> with custom keyboard handlers gets you to the same place, fragilely, with more code.

The big categories

ARIA defines three kinds of attributes:

• Roles — what the element is (role="button", role="dialog", role="navigation", role="alert"). The full role list is over 80 entries; the WAI’s ARIA Authoring Practices Guide groups them into landmark roles, widget roles, and document-structure roles.
• States — what the element’s current condition is (aria-expanded="true", aria-checked="false", aria-disabled="true"). States change at runtime.
• Properties — what the element’s relationships are (aria-labelledby="title-id", aria-describedby="help-id", aria-controls="menu-id"). Properties are typically static.

ARIA’s three remaining rules

The W3C’s five-rule sequence after “use native HTML when possible”:

2. Do not change native semantics, unless you really have to. (<h1 role="button"> confuses screen readers about whether it’s a heading or a button.)
3. All interactive ARIA controls must be usable with the keyboard.
4. Do not use role="presentation" or aria-hidden="true" on a focusable element.
5. All interactive elements must have an accessible name.

Following those five rules eliminates 80%+ of ARIA bugs.

Where to look

The most useful operational reference is the ARIA Authoring Practices Guide (APG), which gives end-to-end implementation patterns for common widgets — comboboxes, dialogs, treeviews, tabs — including keyboard interaction tables and DOM examples.