ARIA Deep Dive

What is ARIA?

WAI-ARIA (Web Accessibility Initiative — Accessible Rich Internet Applications) is a W3C specification that defines a set of HTML attributes — roles, properties, and states — that can be added to markup to communicate semantic information to assistive technologies that HTML alone cannot express.

ARIA does not change how elements look or behave in the browser — it only affects how they are communicated to the accessibility tree, which assistive technologies read.

ARIA is defined in WCAG 2.2 Principle 4 (Robust), particularly SC 4.1.2 which requires that name, role, and value are programmatically determinable for all UI components.

The First Rule of ARIA

"If you can use a native HTML element or attribute with the semantics and behavior you require already built in, then do so instead of re-purposing an element and adding an ARIA role, state, or property to make it accessible."

— W3C, Using ARIA

Roles

ARIA roles define what an element is. They are divided into categories:

Landmark Roles

Landmark roles identify major page regions. Most have native HTML equivalents — prefer those.

Widget Roles (No HTML Equivalent)

These roles communicate complex interactive patterns that have no semantic HTML equivalent:

Document Structure Roles

Used to describe structural relationships when HTML semantics alone are insufficient.

Properties & States

Properties define characteristics that are unlikely to change (e.g., aria-label). States are dynamic values that change in response to user interaction (e.g., aria-expanded). States must be updated via JavaScript when the UI changes.

Live Regions

Live regions announce dynamic content changes to screen reader users without requiring a page refresh or focus move. They are essential for single-page apps, form validation, and status messages (WCAG 2.2 SC 4.1.3).

Example: Announcing form submission

<div role="status" aria-live="polite" aria-atomic="true">
  <!-- Initially empty -->
</div>

// JavaScript: After form submission
document.querySelector('[role="status"]').textContent =
  'Your message has been sent. We\'ll respond within 24 hours.';

Common Patterns

Modal Dialogs

Modals must manage focus — moving it into the dialog on open and returning it to the trigger on close. Focus must be trapped within the dialog while it is open.

<div
  role="dialog"
  aria-modal="true"
  aria-labelledby="dialog-title"
  aria-describedby="dialog-desc"
>
  <h2 id="dialog-title">Confirm Deletion</h2>
  <p id="dialog-desc">This action cannot be undone.</p>
  <button type="button">Cancel</button>
  <button type="button">Delete</button>
</div>

Tabs

Tab navigation uses arrow keys to move between tabs (not Tab key). The Tab key moves focus to the selected tabpanel.

<div role="tablist" aria-label="Pricing options">
  <button role="tab" aria-selected="true" aria-controls="monthly-panel">Monthly</button>
  <button role="tab" aria-selected="false" aria-controls="annual-panel" tabindex="-1">Annual</button>
</div>
<div role="tabpanel" id="monthly-panel" aria-labelledby="monthly-tab">
  <!-- Monthly pricing content -->
</div>

Accordions

Disclosure patterns (accordions) use a button to toggle a panel. The button's aria-expanded state must be updated dynamically.

<h3>
  <button
    aria-expanded="false"
    aria-controls="section1-panel"
  >
    What is web accessibility?
  </button>
</h3>
<div id="section1-panel" hidden>
  <p>Web accessibility means...</p>
</div>

Custom Dropdowns (Combobox)

Custom select/autocomplete widgets require significant ARIA work. Consider using the native <select> element when possible — it is accessible and well-supported.

<div role="combobox" aria-expanded="false" aria-haspopup="listbox">
  <input
    type="text"
    autocomplete="off"
    aria-autocomplete="list"
    aria-controls="options-list"
    aria-activedescendant=""
  />
  <ul role="listbox" id="options-list">
    <li role="option" aria-selected="false">Option 1</li>
  </ul>
</div>

ARIA Anti-Patterns

These are some of the most common ARIA mistakes that make pages less accessible, not more:

Testing ARIA

ARIA implementation must be tested with real assistive technology — automated tools cannot verify whether ARIA communicates the right information in practice.