WAI-ARIA

WAI-ARIA, which stands for Web Accessibility Initiative - Accessible Rich Internet Applications, is a technical specification published by the W3C that provides a framework for making dynamic web content and complex user interface components accessible to people who use assistive technologies. It defines a set of HTML attributes that communicate roles, states, and properties of UI elements to screen readers and other tools. When the web was primarily static documents, HTML's built-in semantics were sufficient for accessibility. Links, headings, lists, tables, and form elements provided clear meaning that assistive technologies could interpret. But as web applications grew to include complex interactive patterns like drag-and-drop interfaces, tabbed panels, autocomplete fields, tree views, and live updating regions, native HTML semantics fell short. ARIA fills this gap. It does not change the visual appearance or behavior of elements. Instead, it adds a semantic layer that assistive technologies can read, enabling screen reader users to understand and interact with sophisticated web applications.

Modern web applications routinely use interactive patterns that have no native HTML equivalent. A tab interface, for example, requires specific roles (`tablist`, `tab`, `tabpanel`), states (`aria-selected`), and relationships (`aria-controls`) that HTML alone cannot express. Without ARIA, a screen reader user encounters these components as a collection of meaningless divs and spans. WCAG Success Criterion 4.1.2 (Name, Role, Value) requires that all user interface components have their name, role, and value programmatically determinable. For custom components, ARIA is often the only way to meet this requirement. ARIA also enables accessibility patterns that go beyond basic navigation. Live regions announce dynamic content changes. Landmark roles enable efficient page navigation. State attributes like `aria-expanded`, `aria-checked`, and `aria-disabled` keep users informed of component states that would otherwise be communicated only visually. However, ARIA carries responsibility. Incorrect ARIA is worse than no ARIA, because it actively misleads assistive technology users. The five rules of ARIA, established by the W3C, emphasize using native HTML first and using ARIA only when necessary and correctly.

ARIA attributes fall into three categories: **Roles** define what an element is. They are set using the `role` attribute and include landmark roles (`banner`, `navigation`, `main`), widget roles (`button`, `dialog`, `slider`, `tablist`), document structure roles (`heading`, `list`, `table`), and live region roles (`alert`, `status`, `log`). ```html <div role="tablist"> <button role="tab" aria-selected="true">Tab 1</button> <button role="tab" aria-selected="false">Tab 2</button> </div> <div role="tabpanel">Content for Tab 1</div> ``` **States** describe the current condition of an element and change during user interaction. Examples include `aria-expanded` (whether a section is open), `aria-checked` (whether a checkbox is selected), `aria-disabled` (whether a control is disabled), and `aria-selected` (whether an item is selected). **Properties** provide additional information about an element that is generally more static than states. Examples include `aria-label` (accessible name), `aria-describedby` (supplementary description), `aria-controls` (element being controlled), `aria-required` (whether input is mandatory), and `aria-haspopup` (whether a button triggers a popup). **The Five Rules of ARIA:** 1. Use native HTML elements whenever possible instead of ARIA. 2. Do not change native semantics unless absolutely necessary. 3. All interactive ARIA controls must be usable with the keyboard. 4. Do not use `role="presentation"` or `aria-hidden="true"` on visible focusable elements. 5. All interactive elements must have an accessible name. The WAI-ARIA Authoring Practices Guide (APG) provides detailed patterns for implementing common widgets. Each pattern specifies the required roles, states, properties, and keyboard interactions. Following these patterns ensures consistency across implementations and meets user expectations about how components should behave. ARIA is supported by all modern browsers and screen readers, though the level of support varies by combination. Testing with multiple screen readers (NVDA, JAWS, VoiceOver, TalkBack) helps ensure broad compatibility.