ARIA (Accessible Rich Internet Applications)

WAI-ARIA (Web Accessibility Initiative — Accessible Rich Internet Applications) is a technical specification published by the World Wide Web Consortium (W3C) that defines a set of HTML attributes for making web content and applications more accessible to people with disabilities. ARIA provides a way to add semantic information to HTML elements that do not natively convey their role, state, or properties to assistive technologies like screen readers. Modern web applications frequently use custom components — tabs, dropdown menus, sliders, modal dialogs, tree views, drag-and-drop interfaces — that go far beyond what standard HTML elements provide. A `<div>` that functions as a tab panel has no built-in way to tell a screen reader that it is a tab panel, which tab is currently selected, or how to navigate between tabs. ARIA fills this gap by allowing developers to add attributes like `role="tabpanel"`, `aria-selected="true"`, and `aria-controls="panel-1"` that communicate the component's purpose and state to the accessibility tree. The ARIA specification defines three categories of attributes: **roles**, which define what an element is (such as `button`, `dialog`, `alert`, `menu`, or `navigation`); **properties**, which define characteristics unlikely to change frequently (such as `aria-label`, `aria-describedby`, `aria-required`, and `aria-haspopup`); and **states**, which define conditions that change during user interaction (such as `aria-expanded`, `aria-checked`, `aria-disabled`, and `aria-hidden`). The current version is WAI-ARIA 1.2, with ARIA 1.3 in development. The companion document, the ARIA Authoring Practices Guide (APG), provides detailed design patterns and code examples for building accessible custom components.

ARIA exists because the web evolved beyond what semantic HTML alone can describe. In the early days of the web, pages were mostly static documents with links and forms — elements that HTML handles well. But modern web applications behave more like desktop software, with complex interactive widgets, dynamic content updates, and single-page architectures that never reload. Without ARIA, these custom components are invisible or unintelligible to assistive technologies. A screen reader encountering a custom dropdown built from `<div>` elements sees only generic containers with text inside them. The user has no way to know that the element is a dropdown, that it is collapsed, or that pressing a key will open it. ARIA attributes solve this by providing the missing semantics. ARIA is also essential for accessibility compliance. WCAG 2.2 Success Criterion 4.1.2 requires that all user interface components have programmatically determinable names and roles, and that states, properties, and values can be set by assistive technologies. For custom components, ARIA is typically the only way to meet this requirement. The legal implications are significant. Section 508 of the Rehabilitation Act mandates WCAG conformance for federal government websites, and ADA lawsuits increasingly reference WCAG criteria. Proper ARIA implementation is not optional for organizations that need to meet accessibility standards.

ARIA works by modifying the accessibility tree — the browser's structured representation of the page that assistive technologies consume. When the browser encounters ARIA attributes, it updates the corresponding node in the accessibility tree with the role, name, state, or relationship information that ARIA provides. **The five rules of ARIA** (from the W3C's "Using ARIA" document) guide proper usage: 1. **Do not use ARIA if you can use native HTML.** A `<button>` is always better than `<div role="button">` because native elements have built-in keyboard support, focus management, and semantics. 2. **Do not change native semantics unless you really need to.** Do not add `role="heading"` to a `<button>` — it overrides the button's native semantics and confuses users. 3. **All interactive ARIA controls must be operable with the keyboard.** ARIA adds semantics but not behavior. A `<div role="button">` must also respond to Enter and Space key presses. 4. **Do not use `role="presentation"` or `aria-hidden="true"` on a visible focusable element.** This creates a confusing situation where an element that users can tab to is invisible to assistive technology. 5. **All interactive elements must have an accessible name.** Every button, link, input, and custom widget must be identifiable by name to screen reader users. **Common ARIA patterns** include: - **`aria-label` and `aria-labelledby`** provide accessible names when visible text is insufficient. `aria-label` sets the name directly; `aria-labelledby` points to another element whose text content serves as the label. - **`aria-live` regions** announce dynamic content changes. Setting `aria-live="polite"` on a region means the screen reader will announce changes after the user finishes their current action. `aria-live="assertive"` interrupts immediately and should be reserved for critical alerts. - **`aria-expanded`** communicates whether a collapsible section (accordion, dropdown, or disclosure widget) is open or closed. The value toggles between `"true"` and `"false"` via JavaScript. - **`aria-hidden="true"`** removes an element from the accessibility tree entirely. This is useful for decorative elements or duplicated content that would be redundant for screen reader users. - **Role-based patterns** like `role="dialog"`, `role="tablist"` / `role="tab"` / `role="tabpanel"`, and `role="menu"` / `role="menuitem"` define complex widget structures that screen readers can interpret and navigate.

**Good: Accessible modal dialog.** ```html <div role="dialog" aria-modal="true" aria-labelledby="dialog-title"> <h2 id="dialog-title">Confirm Deletion</h2> <p>Are you sure you want to delete this item?</p> <button>Cancel</button> <button>Delete</button> </div> ``` The screen reader announces "Confirm Deletion, dialog" and knows to treat the content as a modal. Focus should be trapped within the dialog until it is dismissed. **Good: Accessible accordion.** ```html <button aria-expanded="false" aria-controls="section1"> Shipping Information </button> <div id="section1" role="region" hidden> <p>We ship to all 50 states...</p> </div> ``` The screen reader announces "Shipping Information, collapsed button." When activated, JavaScript sets `aria-expanded="true"`, removes `hidden`, and the screen reader announces "Shipping Information, expanded button." **Bad: ARIA without keyboard support.** ```html <div role="button" aria-label="Submit form">Submit</div> ``` This element is announced as a button but cannot receive keyboard focus (no `tabindex`) and does not respond to Enter or Space. A sighted keyboard user or screen reader user cannot activate it. **Bad: Overusing ARIA on native elements.** ```html <button role="button" aria-label="Submit" tabindex="0">Submit</button> ``` This is redundant. The `<button>` element already has the button role, already receives focus, and already has "Submit" as its accessible name from its text content. The extra ARIA adds no value and clutters the code.

**Using ARIA instead of semantic HTML.** The most frequent mistake is reaching for ARIA when a native HTML element would do the job. Using `<div role="navigation">` instead of `<nav>`, or `<span role="link">` instead of `<a href>`, adds complexity and removes built-in browser behaviors. **Adding ARIA roles without corresponding keyboard behavior.** ARIA is purely semantic — it informs assistive technology but does not create behavior. Every interactive ARIA role requires JavaScript to handle focus management and keyboard events matching the expected interaction pattern. **Incorrect aria-hidden usage.** Setting `aria-hidden="true"` on a parent element hides all children from the accessibility tree, even if they contain focusable elements. This creates "ghost" elements that keyboard users can reach but screen readers cannot see. Never use `aria-hidden` on elements that contain focusable content. **Forgetting to update dynamic ARIA states.** Setting `aria-expanded="false"` on a button but never updating it to `"true"` when the content expands means the screen reader always reports the element as collapsed, even when it is visually open. **Misusing aria-live.** Applying `aria-live="assertive"` too broadly causes screen readers to interrupt the user constantly. Most dynamic updates should use `aria-live="polite"`. Reserve `assertive` for error messages, critical alerts, and time-sensitive information. **Creating redundant announcements.** Adding both `aria-label` and visible text content to the same element, or wrapping an image with alt text inside a link that has `aria-label`, can cause screen readers to announce the name twice or announce the wrong name.