Loading…
Loading…
A W3C specification adding roles and properties to HTML for better assistive technology support.
stellae.design
WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) is a W3C specification that defines attributes to make dynamic web content and custom widgets accessible to assistive technologies. ARIA provides roles (what an element is), states (its current condition), and properties (its characteristics) that bridge the gap between what screen readers expect and what custom JavaScript widgets deliver. WCAG 2.1 SC 4.1.2 (Name, Role, Value, Level A) requires that custom components expose their role, name, and state programmatically — ARIA is the primary tool for this. However, ARIA doesn't add behavior — it only communicates to assistive technology. Adding role='button' to a div doesn't make it keyboard-operable; you must also add keyboard handlers and focus management.
WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) is a W3C specification that provides a supplementary layer of semantic information for web content, bridging the gap between the limited native semantics of HTML and the complex interactive patterns that modern web applications demand. Without ARIA, custom components like tab panels, tree views, comboboxes, drag-and-drop interfaces, and single-page application navigation changes are invisible or incomprehensible to screen readers because native HTML has no elements that describe these patterns — a `<div>` with click handlers looks identical to decorative content in the accessibility tree. ARIA is not a replacement for semantic HTML but an extension that handles the cases where HTML's built-in elements cannot adequately describe the role, state, and relationship of custom interactive components.
The W3C's APG tab interface example demonstrates the complete ARIA contract for a tabbed component: the container uses role="tablist", each tab uses role="tab" with aria-selected indicating the active tab and aria-controls linking to its panel, and each panel uses role="tabpanel" with aria-labelledby pointing back to its tab. Keyboard interaction is fully implemented with arrow keys moving between tabs, Home and End jumping to first and last tabs, and Tab moving focus into the active panel's content. This reference implementation demonstrates that ARIA is not just about adding attributes — it requires coordinated roles, states, properties, and keyboard behavior to create a complete accessible widget.
GitHub uses ARIA landmarks to define the major regions of their application — navigation, main content, search, and complementary sidebars — allowing screen reader users to jump between sections using landmark navigation shortcuts rather than tabbing through hundreds of elements. Dynamic content changes like code review comment additions, pull request status updates, and notification counts are managed through ARIA live regions that announce changes without disrupting the user's focus. This practical application shows ARIA being used selectively and purposefully to enhance an already semantically structured interface rather than as a substitute for proper HTML.
A component library ships a custom dropdown that applies role="listbox" to the options container and role="option" to each item, correctly communicating the component's purpose to screen readers — but implements no keyboard interaction whatsoever, so keyboard users cannot open the dropdown, navigate options with arrow keys, or select an option with Enter. Screen reader users are told they are interacting with a listbox, setting the expectation that standard listbox keyboard shortcuts will work, but every keyboard interaction fails because the ARIA roles were added without the corresponding behavior. This half-implementation is worse than no ARIA at all because it actively misleads users about the component's capabilities.
• The most damaging ARIA mistake is applying roles and attributes without implementing the corresponding keyboard interaction and state management — adding `role="button"` to a `<div>` without adding keyboard focus, Enter and Space key handling, and proper disabled state communication creates a component that lies to assistive technology users about what it is. Another critical error is using ARIA as a first resort instead of a last resort, reaching for `role="navigation"` when `<nav>` exists, `aria-required` when `required` exists, or `role="heading"` with `aria-level` when `<h1>` through `<h6>` are available — native HTML elements are more robust, more widely supported, and include built-in behaviors that ARIA cannot replicate. Teams also frequently scatter ARIA attributes without understanding the specification's rules about permitted attributes per role, allowed parent-child role relationships, and required owned elements, creating invalid ARIA that different screen readers interpret inconsistently or ignore entirely.
Was this article helpful?