ARIA Guidance: A Beginner’s Guide to WAI-ARIA and Best Practices

Author: Level Access

WAI-ARIA is a technical specification from the World Wide Web Consortium (W3C) that adds semantic roles, states, and properties to HTML elements, enabling assistive technologies to interpret dynamic web content and custom user interface controls. It does not add behavior to elements; it changes only how assistive technologies perceive them.

WAI-ARIA gets used every day on websites—and is misused nearly as often. Getting it right takes more than knowing what it is. It requires knowing when to use it, how to apply it correctly, and what common errors to avoid.

This guide covers the current WAI-ARIA specification, the five rules that govern correct ARIA implementation, and best practices to ensure ARIA helps, not harms, people who use assistive technologies to access the web.

Key insights

• WAI-ARIA defines three types of declarations: roles (what an element is), states (its dynamic condition), and properties (supplemental descriptive information).
• The first rule of ARIA use is to prefer native HTML elements and attributes whenever they provide necessary semantics and keyboard behavior.
• Using ARIA incorrectly produces more accessibility errors than not using it: pages with ARIA averaged 59.1 detectable errors versus 42 on pages without ARIA, per the 2026 WebAIM Million report.
• All interactive ARIA controls must be keyboard accessible; ARIA declares semantics but doesn’t add keyboard functionality automatically.
• Testing with real assistive technologies (JAWS, NVDA, VoiceOver) is essential; browser simulators do not reliably reflect actual screen reader behavior.

What is WAI-ARIA?

WAI-ARIA is a technical specification published by the W3C as part of the Web Accessibility Initiative (WAI). The acronym “ARIA” stands for Accessible Rich Internet Applications. WAI-ARIA defines a framework of HTML attributes that tell assistive technologies, including screen readers and braille displays, about the roles, states, and properties of user interface elements.

It addresses three areas that native HTML and earlier markup specifications did not fully cover: indicating the main structural areas of a page, defining the roles and properties of user interface elements, and providing a method for communicating alerts, page changes, and dynamically updated information.

ARIA only changes how assistive technologies perceive an element. It doesn’t add functionality or keyboard behavior. For example, a <div role=”button”> tells a screen reader the element is a button, but without JavaScript, it won’t respond to keyboard events the way a native <button> element does. This distinction is the source of many common accessibility errors.

Importantly, ARIA complements semantic HTML rather than replacing it. When native HTML elements carry the correct semantics, as <button>, <nav>, <header>, and <input> do, those elements provide the most reliably accessible experience. ARIA is for situations where native elements cannot express the required widget behavior, or where dynamic content changes need to be communicated to assistive technology.

For a full overview of the specification and its history, reference our blog, “What is WAI-ARIA?”.

Who benefits from proper ARIA use?

Correct ARIA implementation directly benefits several groups of assistive technology users:

• Screen reader users gain meaningful information about element roles, accessible names, and dynamic state changes that would otherwise be unavailable to them. Without ARIA, a custom dropdown built from <div> elements is indistinguishable from static text to a screen reader. With correct ARIA roles and states, it communicates its type, current selection, and whether it is open or closed.
• Keyboard-only users and other people who cannot use a mouse or pointer depend on ARIA-enhanced widgets that implement standard keyboard behaviors. When interactive elements do not receive keyboard focus or do not respond to expected key inputs, those users cannot access functionality available to mouse users.
• Users with low vision and cognitive disabilities may benefit from clearer labels, consistent element relationships, and predictable dynamic announcements. Well-implemented live regions and form field relationships reduce the effort required to understand and complete tasks on complex pages.

WAI-ARIA versions

The W3C ARIA Working Group maintains the specification with continuously updated drafts and incremental Recommendations. The current stable specification is WAI-ARIA 1.2, published as a W3C Recommendation in June 2023.

However, a newer version is in the works: WAI-ARIA 1.3 is currently a Working Draft. The latest editor’s draft is dated February 2026, and it has not yet reached Candidate Recommendation status.

Key additions in ARIA 1.3 include:

• New proposed roles: suggestion for collaborative editing contexts, comment for user annotations, and mark for highlighted text.
• Expanded support and usage guidance for existing braille-specific attributes such as aria-braille label and aria-braille role description, which let developers specify labels optimized for refreshable braille displays.
• An expanded aria-description attribute for providing programmatic descriptions that do not need to appear on screen.

When to use ARIA

Use WAI‑ARIA only when necessary and apply it with intention and discipline to avoid introducing accessibility issues. Using ARIA is appropriate when native HTML cannot be used to provide sufficient access. For example, you can rely on ARIA if:

• Custom widgets or dynamic behaviors lack native HTML semantics.
• Accessible change notifications cannot be delivered through native elements.
• Changing HTML is not feasible, but ARIA and JavaScript can be applied to improve accessibility.

When it comes to page structure, prioritize HTML sectioning elements such as <main>, <header>, and <nav>. If those are not available, you can apply equivalent ARIA landmarks in their place, but only as a fallback.

It can be helpful to think of ARIA as a tool for progressive enhancement: start with standard semantic HTML markup, then add ARIA enhancements on top of that structure. This ensures the largest number of users can access content regardless of the assistive technologies or browsers they use.

ARIA can also be implemented in situations where it’s not practical or possible to change HTML code.

Five tips for effective ARIA use

The following best practices emphasize using native HTML whenever possible, preserving existing semantics, and adding ARIA only when it meaningfully improves keyboard and screen reader interactions—rather than compensating for avoidable design decisions.

1. Prefer semantic HTML elements over ARIA when native elements provide the required semantics.
2. Do not override native element semantics unless absolutely necessary.
3. If ARIA must be used to provide an accessible name (e.g., text content or native semantics are not sufficient), use aria-labelledby first, then aria-label.
4. Use progressive enhancement as the baseline approach to implementation. That means building components with native HTML so they work accessibly by default, then implementing additional behavior as needed.
5. Test with real assistive technologies before deployment.

The ARIA Authoring Practices Guide

The W3C ARIA Authoring Practices Guide is the definitive resource for implementing accessible widget patterns. It provides reference implementations for dozens of common components (dialogs, tabs, accordions, carousels, combo boxes, menus, tree views, and more) with keyboard interaction models, required ARIA markup, and working code examples. This guide reflects the most current guidance from the ARIA Working Group and should be the first reference for any developer building a custom interactive component.

Web standards for accessibility continue to evolve. Tracking updates to the W3C’s ARIA specification and the ARIA Authoring Practices Guide ensures that your references stay current as browser support and assistive technology capabilities develop.

ARIA roles, states, and properties

WAI-ARIA provides web authors with semantics in three main forms: roles, states, and properties.

ARIA roles

ARIA roles define what an element is and how assistive technologies should interpret it. When native HTML elements do not carry enough semantic meaning for a given widget, or when custom controls must be used, roles communicate the element’s purpose to the accessibility tree. Common examples include role=”button”, role=”tab”, role=”dialog”, role=”tablist”, and role=”alert”. Roles can also describe elements that do not natively exist in HTML, allowing assistive technologies to treat custom widgets as recognized interface components.

Redundant ARIA roles shouldn’t be added to HTML5 elements that already carry built-in semantics. Applying role=”button” to a native <button> element is unnecessary and can cause unpredictable behavior in certain assistive technologies.

States and properties

States describe the current dynamic condition of an element. They change at runtime in response to user interaction or application logic. Common states include aria-expanded (indicating whether a collapsible region is open or closed), aria-checked (for checkbox-style controls), aria-selected, and aria-disabled.

Properties provide supplemental descriptive information that changes less frequently, such as aria-label for a short accessible name, or aria-labelledby to reference a visible label element. Developers typically use JavaScript to update these values dynamically in response to user interaction.

Key ARIA attributes

aria-label and aria-labelledby

aria-label provides a short accessible name that assistive technologies announce in place of visible text. aria-labelledby references one or more visible elements by their id values and uses their text content as the accessible name.

While both attributes should not be used for the same element, aria-labelledby takes precedence over aria-label, which in turn takes precedence over a native <label> element. Understanding this precedence chain prevents invisible or conflicting labels.

Because some assistive technology does not fully support ARIA, always use native HTML instead of aria-labelledby when possible.

aria-describedby

aria-describedby links an element to one or more descriptive elements, providing supplemental context beyond the accessible name. It is commonly used to associate error messages or help text with form fields. Unlike aria-labelledby, aria-describedby is announced after the primary name and role, giving users additional detail without replacing the element’s accessible name.

aria-hidden

aria-hidden=”true” removes an element from the accessibility tree, preventing assistive technologies from announcing it. It does not remove the element from the document object model (DOM) or the keyboard focus order. Setting aria-hidden on a focusable element, such as a link, button, or input, means screen reader users can tab to something they cannot access. That creates a disorienting experience.

Where content should be removed from both assistive technology and keyboard users, CSS display:none, the HTML <hidden> attribute, or the inert attribute is more appropriate.

aria-controls

aria-controls indicates a relationship between a controlling element and the element it affects, referenced by id. You can pair it with state attributes such as aria-expanded or aria-selected to signal UI toggles consistently.

ARIA live regions

Live regions are areas of a webpage whose content updates dynamically without a full page reload. WAI-ARIA provides live regions to notify assistive technology of those changes without requiring users to move keyboard focus to the updated area. This is particularly useful in single-page applications, status messages, search result updates, and inline form validation.

role=”alert” creates an assertive live region. Content added to an alert container is announced immediately by screen readers, interrupting the current reading flow. For less urgent updates, aria-live=”polite” defers the announcement until the user pauses, reducing interruption. aria-live=”off” prevents a region from being announced automatically.

Overuse of live regions creates excessive noise for screen reader users. Limit announcements to information the user needs without navigating to it. Only inject content into a live region container after that container has been rendered in the DOM. Content injected before the browser has parsed the live region will not trigger an announcement.

Keyboard accessibility and ARIA

ARIA declares what an element is, but it doesn’t make that element operable from a keyboard. For example, a <div> with role=”button” requires a tabindex=”0″ attribute to receive keyboard focus, and JavaScript event listeners for both mouse click and keyboard events (Enter and Space) to behave like a native button.

tabindex=”0″ adds an element to the natural tab order of the document. Positive tabindex values disrupt document order and should be avoided. tabindex=”-1″ removes an element from the tab sequence while keeping it programmatically focusable. This is useful for managing focus within dialogs and composite widgets where keyboard navigation follows a defined pattern rather than the default tab order. You may also use aria-activedescendant to keep focus on an input while visually highlighting options.

Focus management is a key responsibility in dynamic content. When a dialog opens, keyboard focus should move into it. When it closes, focus should return to the element that triggered it. In single-page applications, navigation changes require explicit focus handling so that screen reader users and keyboard-only users receive the same awareness of new content that mouse users get automatically.

Keyboard navigation patterns for common ARIA widgets (tabs, menus, trees, grids, and dialogs) are documented in the W3C ARIA Authoring Practices Guide.

Browser and assistive technology support

For ARIA to function as designed, both the browser and the assistive technology in use must support it. ARIA support varies across browser and assistive technology combinations, and behavior is not uniform.

Most modern browsers, including Chrome, Firefox, Safari, and Edge, provide robust ARIA support, though specific roles and properties may behave differently across browser engines.

Assistive technology support for ARIA has grown significantly. Most modern assistive technologies support ARIA, though to different degrees. JAWS, NVDA, and VoiceOver are the primary screen readers to test against. Some assistive technologies support certain ARIA roles or properties but not others. Additionally, some older software versions may not support certain roles at all, or may report them incorrectly.

Because of this variation in support, ARIA techniques require careful testing before deployment. role=”dialog” and role=”application”, for example, can change how screen readers handle virtual cursor navigation, which allows users to control a mouse pointer using gestures or specialized software. Browser emulators and simulators are not effective for testing full ARIA support—testing with actual assistive technology is necessary to confirm functionality.

ARIA and accessibility for JavaScript web applications

Web applications built with JavaScript frameworks present specific accessibility challenges that ARIA is designed to address. Single-page applications change content dynamically without full page loads, and assistive technologies that rely on page-load events will not receive automatic updates about new content.

WAI-ARIA includes technologies to map controls, live regions, and events to accessibility APIs, allowing dynamic web applications to communicate state changes in a structured way. Progressive enhancement is still the recommended baseline: semantic HTML first, with ARIA added to support richer interactions. Where functionality depends entirely on JavaScript and ARIA-dependent scripts, developers should document known limitations for the supported assistive technology stacks and test regularly to catch regressions.

Common ARIA mistakes

Using ARIA incorrectly can produce more accessibility errors than not using ARIA at all. The 2026 WebAIM Million report found that home pages with ARIA averaged 59.1 detectable errors, compared to 42 errors on pages without ARIA.

Some of the most common mistakes developers make with ARIA include:

• Setting aria-hidden=”true” on focusable elements: Screen reader users can tab to elements that are hidden from the accessibility tree but remain in the focus order, creating a confusing and broken experience. A closely related error is hiding error message containers with aria-hidden=”true” on page load and then failing to toggle the attribute off when errors appear. The error messages render visually, but screen readers never announce them.
• Replacing native HTML elements with custom ARIA widgets: Using <div role=”button”> instead of <button> requires developers to manually implement focus behavior, keyboard handling, and state management that native elements handle automatically, and those manual implementations are frequently incomplete.
• Broken ARIA hierarchies: Using role=”list” without immediate children with role=”listitem”, or role=”tablist” without role=”tab” children, violates ARIA’s parent-child ownership requirements. Spelling errors also cause problems. For example, aria-labeledby (missing the second “l”) or aria-lable will be ignored by screen readers with no runtime warning and no indication that the label is missing.
• Redundant ARIA roles on HTML elements that already carry built-in semantics: Assigning redundant roles, such as placing role=”button” on a native <button>, is unnecessary and can produce inconsistent behavior across certain assistive technologies.
• “Double-speaking” when combining ARIA with older techniques: “Double-speaking” refers to a scenario where both ARIA-supported assistive technologies and non-ARIA fallbacks announce the same information. In those cases, the non-ARIA content should use aria-hidden to prevent duplication, though this technique may not be supported by all versions of screen readers.

Evaluation and testing

Testing for proper ARIA implementation needs to work at two levels. At the syntax level, automated tools can flag invalid roles, duplicate role assignments, invalid attribute values, and missing required child roles. These issues are detectable by static analysis, and many linters and continuous integration (CI)-integrated tools surface them reliably.

At the semantic level, automated testing falls short. Whether ARIA attributes carry accurate values, whether states update in sync with visual changes, and whether the screen reader experience is coherent: all of these require manual evaluation. Testing with real assistive technologies such as JAWS, NVDA, and VoiceOver as well as accessibility API inspection tools across relevant browser combinations is necessary to confirm functionality.

ARIA can be used incorrectly just like any specification, and improper implementations need to be identified and corrected. Issues range from syntax problems, such as multiple role types on a single element or an invalid role, to semantic problems such as stale or incorrect attribute values, or a user interface role that does not match the actual control. Testing should confirm that non-ARIA fallbacks exist for contexts where ARIA support cannot be guaranteed, unless the target assistive technology stack has been confirmed.

Use ARIA with intent, not by default

WAI-ARIA is a powerful tool, but it’s not a shortcut to accessibility. Its value lies in precise, intentional use: applying native HTML whenever possible, reinforcing rather than overriding built‑in semantics, and ensuring that every ARIA-enhanced interaction remains fully operable by keyboard and intelligible to assistive technologies.

When ARIA is used correctly, it fills critical gaps in dynamic and custom interfaces. When it’s misused, it introduces barriers that are often harder to detect than the problems it was meant to solve.

Accessibility outcomes depend not just on knowing ARIA attributes, but on understanding how real users experience them through keyboard navigation, screen readers, or braille displays (which are also powered by screen readers). That’s why progressive enhancement, adherence to the ARIA Authoring Practices Guide, and testing with actual assistive technologies are essential, not optional.

Whether you’re building complex interfaces or maintaining legacy components that rely on ARIA, expert review can prevent costly accessibility failures. Level Access helps teams implement and test ARIA correctly—so it improves access instead of creating risk. Contact us to strengthen your accessibility strategy and ensure your ARIA implementations work for the people who depend on them most.