What Is ARIA? A Guide to Accessible Web Components

Most websites look accessible. Most are not.

If you build interfaces with custom dropdowns, modals, or tab panels, there is a real chance your JavaScript-driven components are completely invisible to screen readers. That is exactly the problem ARIA was built to fix.

ARIA, short for Accessible Rich Internet Applications, is a W3C specification that adds semantic meaning to HTML elements so assistive technologies can understand them. It covers roles, states, and properties that native HTML simply cannot express on its own.

This guide covers what ARIA is, how it works, when to use it, and the mistakes that make it do more harm than good.

What is ARIA?

ARIA stands for Accessible Rich Internet Applications. It is a W3C technical specification that defines a set of HTML attributes that expose semantic meaning to assistive technologies, like screen readers, without changing the visual appearance or behavior of an element.

Formally known as WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications), the current stable version is WAI-ARIA 1.2, published as a W3C Recommendation by the ARIA Working Group. A WAI-ARIA 1.3 editor’s draft is currently under development.

ARIA works by adding roles, states, and properties to HTML elements. These attributes modify the accessibility tree, which is the structure browsers expose to assistive technologies. They do not touch the DOM or the visual rendering pipeline.

According to the WebAIM Million 2026 report, 82.7% of the top one million home pages now use ARIA attributes, up from 74.6% in 2024. ARIA code usage has grown over 6 times since 2019.

Why Does ARIA Exist?

Native HTML elements cover basic semantics well. Buttons, links, headings, and form inputs all carry implicit roles that screen readers understand. The problem is that modern user interface patterns go far beyond what native HTML was designed to handle.

Tab panels, sliders, modal dialogs, tree views, and autocomplete widgets have no native HTML equivalents with built-in accessibility semantics. Before ARIA, building these with JavaScript meant creating elements that looked functional visually but were completely invisible to screen readers.

The Gap That HTML Left Open

HTML4 and early HTML5 covered roughly 30 interactive patterns. Modern web applications use hundreds more. That gap created an accessibility dead zone for keyboard-only users and screen reader users.

• JavaScript-heavy interfaces broke the accessibility tree entirely
• Dynamic content changes were invisible to assistive technologies
• Complex widgets had no way to communicate role, state, or properties
• Focus management across multi-step interactions was undefined

WAI-ARIA 1.0 became a completed W3C Recommendation on March 20, 2014. It was the formal answer to a problem that had been growing for years as web applications became more complex and Ajax-driven interfaces became standard.

Who ARIA Was Built For

ARIA was built for 2 specific groups: people with visual disabilities who use screen readers to access web content, and people who cannot operate a mouse and rely on keyboard navigation or speech input.

91.3% of screen reader users report using a screen reader on a mobile device (WebAIM Survey 10, 2024). JAWS and NVDA are the 2 dominant desktop screen readers, sitting at roughly 41% and 38% of primary usage respectively.

Around 1.3 billion people globally live with a disability that affects how they use the internet (WebAIM, 2024). ARIA is one of the primary tools that lets developers build accessible experiences for that population.

How Does ARIA Work?

ARIA attributes sit inside HTML markup. Browsers read those attributes and use them to build the accessibility tree, a parallel structure to the DOM that assistive technologies consume directly.

The key thing to understand: ARIA never changes what a user sees or what JavaScript executes. It only changes what assistive technologies report about an element.

How ARIA Interacts with the Accessibility Tree

Every browser maintains an accessibility tree alongside the DOM. When ARIA attributes are present, they override or supplement the element’s native implicit role and properties in that tree.

A <div> has no implicit role. Add role="button" and the accessibility tree now reports it as a button. Remove the attribute and it goes back to being invisible as an interactive element. The DOM doesn’t change at all.

ARIA attributes modify 3 things in the accessibility tree: the role (what the element is), the name (what it’s called), and the state (what condition it’s currently in).

How Browsers Expose ARIA to Assistive Technologies

Browsers don’t communicate with screen readers directly. They expose the accessibility tree through platform-specific accessibility APIs.

Screen readers like NVDA, JAWS, and VoiceOver never read raw HTML. They query the platform accessibility API, which in turn reflects the accessibility tree. ARIA attributes feed into that chain at the browser level.

What Are ARIA Roles?

ARIA roles define what an element is. They override the native implicit role of an HTML element and tell assistive technologies how to treat it. WAI-ARIA 1.2 organizes roles into 4 main categories: widget roles, landmark roles, document structure roles, and live region roles.

Widget Roles

Widget roles describe interactive UI controls. These are the roles most commonly needed when native HTML elements don’t exist for a given pattern.

• role="button" – an interactive element that triggers an action
• role="tab" – a selectable tab in a tab interface
• role="slider" – a range input with a draggable handle
• role="combobox" – a combined input and listbox for autocomplete
• role="dialog" – a modal or non-modal dialog window

28% of ARIA menus on the top one million home pages introduced accessibility barriers because the required markup and interactions were missing (WebAIM Million 2024). Widget roles require more than just the role attribute. They need associated keyboard behavior added via JavaScript and correct child roles.

Landmark Roles

Landmark roles define regions of a page. They let screen reader users jump directly to major sections without reading through everything in sequence.

WebAIM Survey 10 (2024) found that 71.6% of screen reader users navigate pages by headings and landmarks. Landmark implementation directly affects how efficiently those users can find content.

The 6 most-used landmark roles: banner, navigation, main, complementary, contentinfo, and search. HTML5 elements like <nav>, <main>, and <footer> carry these landmark roles implicitly, which is exactly why native HTML should always come first.

Live Region Roles

Live region roles tell screen readers to watch an area of the DOM and announce changes automatically. role="alert" and role="status" are the 2 shorthand live region roles in WAI-ARIA 1.2.

The difference matters in practice: role="alert" interrupts whatever the screen reader is doing and announces immediately. role="status" waits for the user to finish their current activity. Using the wrong one creates either missed announcements or constant interruptions.

What Are ARIA States and Properties?

States and properties are 2 distinct attribute categories. Both are added to HTML elements as attributes, but they serve different purposes and behave differently during a session.

WAI-ARIA 1.2 defines 48 states and properties in total. Most developers work with a small subset regularly, but knowing the distinction between the 2 categories prevents common implementation errors.

ARIA States

States describe the current condition of an element. They change dynamically as the user interacts with the interface.

States require JavaScript to update. Setting aria-expanded="false" in HTML and never changing it is one of the most common ARIA mistakes. The attribute must reflect the actual current state of the element at all times.

ARIA Properties

Properties describe characteristics that define an element’s relationships, labels, or descriptions. They typically get set at render time and don’t change unless the UI structure changes.

• aria-label – provides a direct accessible name string
• aria-labelledby – references another element’s ID as the accessible name
• aria-describedby – references supplementary descriptive text
• aria-controls – identifies the element a control manages
• aria-owns – defines parent-child relationships not present in the DOM

The WebAIM Million 2026 report found home pages averaged 31.4 instances of aria-label, aria-labelledby, or aria-describedby per page, a 28% increase in just one year. Usage is growing fast. Correct usage is not keeping pace.

What is the First Rule of ARIA Use?

The W3C states it directly: use native HTML elements before using ARIA. This is the first and most important rule from the W3C’s “Using ARIA” working group note, and it shapes every correct ARIA implementation decision.

Native HTML elements carry implicit ARIA roles, states, and properties automatically. A <button> already has role="button", keyboard focus, and click handling built in. A <nav> already has role="navigation". Adding ARIA to these elements is redundant at best, harmful at worst.

Why ARIA Is Not a Shortcut

This is where a lot of developers get it wrong. ARIA adds semantic meaning. It does not add behavior.

Adding role="button" to a <div> tells screen readers it’s a button. It does not make that <div> focusable, it does not add keyboard event handlers, and it does not make it respond to Enter or Space key presses. All of that still requires JavaScript.

A native <button> does all of that out of the box. For web accessibility, a native button is always the better choice unless there is a specific, documented reason it cannot be used.

When ARIA Is Actually Needed

3 situations genuinely require ARIA:

• The HTML element has no native semantic equivalent (e.g., a custom tab panel)
• The UI pattern requires a role or state that HTML cannot express natively
• Dynamic content needs to be communicated to assistive technologies as it changes

Outside these situations, native HTML handles usability and accessibility better, with less code and fewer failure points. The WebAIM Million 2025 report notes that pages using ARIA averaged twice as many errors as pages without ARIA (57 vs. 27 on average). Complexity, not ARIA itself, drives that number, but the pattern shows that more ARIA is not automatically better accessibility.

What Are the Five Rules of ARIA Use?

The W3C ARIA Working Group published 5 rules for correct ARIA implementation in their “Using ARIA” specification note. These rules apply to every element and every pattern where ARIA is considered.

The 5 rules, as defined by W3C:

• Rule 1: Use a native HTML element or attribute with the required semantics and behavior instead of repurposing an element and adding an ARIA role, state, or property
• Rule 2: Do not change native semantics unless strictly necessary
• Rule 3: All interactive ARIA controls must be operable by keyboard
• Rule 4: Do not use role="presentation" or aria-hidden="true" on a focusable element
• Rule 5: All interactive elements must have an accessible name

Why Rule 3 and Rule 4 Break the Most Sites

Rule 3 fails regularly because developers add ARIA roles to non-interactive elements without adding keyboard support. A <div role="button"> that only responds to mouse clicks excludes keyboard-only users completely. The ARIA role promises keyboard accessibility. JavaScript must deliver it.

Rule 4 fails when aria-hidden="true" gets applied to elements that are still reachable by Tab key. The element disappears from the accessibility tree but remains in the focus order. Screen reader users land on an element their software cannot describe. That is worse than no ARIA at all.

Rule 5 in Practice

33.1% of form inputs on the top one million home pages lacked proper labels as of the WebAIM Million 2026 report. Missing accessible names on interactive elements is the most direct violation of Rule 5.

An accessible name comes from 3 sources, in priority order: aria-labelledby referencing visible text, aria-label providing a direct string, or a native <label> element. Any one of the 3 satisfies Rule 5. None of them means the interactive element is effectively invisible to web accessibility tools and screen reader users alike.

Microsoft’s Fluent Design System documents all 5 rules in their component accessibility guidelines, using them as the baseline for every interactive component in the system.

How is ARIA Used in Common UI Patterns?

The WAI-ARIA Authoring Practices Guide (APG) documents the correct role, state, property, and keyboard behavior for every common UI pattern. It covers over 30 widget types, from modal dialogs and tabs to date pickers and tree views.

Real-world interactive elements built with custom HTML almost always need ARIA. The native HTML spec simply does not cover these patterns.

ARIA for Modal Dialogs

Required attributes for an accessible modal:

• role="dialog" on the container element
• aria-modal="true" to signal the background is inert
• aria-labelledby pointing to the dialog’s visible heading
• Focus must move inside the dialog on open, and return to the trigger on close

aria-modal="true" tells assistive technologies that content outside the dialog is inactive. It does not actually make the background inert. JavaScript must implement focus trapping and background interactivity removal (MDN Web Docs, 2025).

ARIA for Tab Interfaces

Tab ownership structure: role="tablist" wraps the tab row. Each tab gets role="tab". Each panel gets role="tabpanel". The active tab carries aria-selected="true", inactive tabs carry aria-selected="false".

Each tabpanel uses aria-labelledby referencing the ID of its controlling tab. This creates the programmatic relationship between tab and panel that screen readers need to navigate the interface.

Arrow key navigation between tabs is required by the APG pattern. Tab key should move focus into and out of the tablist, not between tabs. This keyboard interaction must be implemented in JavaScript. Without it, ARIA roles alone do nothing.

ARIA for Form Validation

WebAIM Million 2026 found 33.1% of form inputs still lacked proper accessible labels across the top one million home pages. That number makes form validation one of the highest-impact places to apply ARIA correctly.

aria-invalid: set to "true" when a field fails validation, announced by screen readers as an error state.

aria-describedby: points to the error message element, so the full error text is read after the field’s accessible name.

Setting aria-invalid="true" without updating it back to "false" after correction is a common mistake. States must reflect actual current conditions at all times.

What is aria-label, aria-labelledby, and aria-describedby?

These 3 attributes handle naming and description in the accessibility tree. They are among the most-used ARIA attributes and among the most commonly misused.

WebAIM Million 2026 data shows home pages averaged 31.4 instances of aria-label, aria-labelledby, or aria-describedby per page, up 28% in a single year. More usage does not mean more correct usage.

aria-labelledby overrides aria-label when both are present on the same element (MDN Web Docs). Using both simultaneously is redundant and should be avoided.

When to Use aria-label

aria-label provides a direct string as the accessible name when no visible text exists in the DOM. The classic example: an icon-only button containing an SVG graphic with no text content.

One practical problem: aria-label text does not automatically translate in multilingual applications. Sites serving multiple languages should prefer aria-labelledby referencing on-screen text, which translates with the page content (The A11Y Collective, 2024).

Do not use aria-label to override visible text with different wording. That creates a mismatch between what sighted users read and what screen reader users hear. It also breaks voice control software, since users cannot activate elements by saying the visible text label.

When to Use aria-describedby

aria-describedby attaches supplementary information, not the primary name. Screen readers announce the description after the accessible name, often with a pause between them.

3 real-world uses where aria-describedby adds clear value:

• Password fields pointing to format requirement text
• Form inputs pointing to inline error messages after validation fails
• Sort buttons on table columns pointing to a description of the sort behavior

The description is optional. Some screen reader modes skip it entirely to reduce verbosity. The accessible name is required and always announced.

What is aria-hidden?

aria-hidden="true" removes an element and all its children from the accessibility tree. The element remains visible on screen and fully interactive. The removal is invisible to sighted users and irreversible until the attribute is changed or removed.

Use it for 3 things: decorative icons paired with visible text labels, duplicate content that would create redundant announcements, and visual-only elements that carry no meaning for screen reader users.

ARIA-related errors appeared on 65.4% of tested home pages in the WebAIM Million 2024 analysis, with improper aria-hidden implementation being one of the most common patterns (TestParty, 2024).

The Focusable Element Problem

Never apply aria-hidden="true" to a focusable element or to any ancestor that contains focusable children.

aria-hidden removes the element from the accessibility tree. It does not remove it from the keyboard tab order. A screen reader user pressing Tab will land on the element, but their screen reader will announce nothing, or say “empty.” That is worse than no ARIA at all.

The fix: if an element needs to be hidden from both the accessibility tree and keyboard navigation, use aria-hidden="true" combined with tabindex="-1", or use the HTML hidden attribute or display: none to remove it from rendering entirely (MDN Web Docs, 2025).

aria-hidden During Modal Open

A common pattern: when a modal dialog opens, wrap the main page content in a container and apply aria-hidden="true" to that container. This prevents screen readers from reading background content while the modal is active.

The failure mode: developers apply aria-hidden to the background but do not remove it when the modal closes. Background content stays invisible to assistive technologies after the dialog closes. Always toggle aria-hidden off when returning focus to the page.

What Are ARIA Live Regions?

Live regions announce DOM changes to screen reader users automatically, without the user needing to move focus to the updated element. They are the primary mechanism for making dynamic content updates accessible.

Without live regions, an Ajax-loaded search result count, cart update, or form success message is completely silent to screen reader users. The DOM updated. Their software has no way of knowing.

aria-live=”polite” vs aria-live=”assertive”

polite: waits for the user to stop interacting before announcing. Right for most updates: search results loaded, items added to cart, non-critical status messages.

assertive: interrupts whatever the screen reader is reading and announces immediately. Reserved for 2 types of updates: critical errors and time-sensitive information. Overusing assertive creates a constantly interrupting experience that frustrates screen reader users.

A common mistake documented in accessibility audits: applying aria-live to elements that never actually update. If the content never changes dynamically, the attribute has no effect and creates unnecessary DOM noise (Designing for Accessibility, 2026).

role=”status” and role=”alert”

role="alert" and role="status" are shorthand live region roles built into WAI-ARIA 1.2. They remove the need to manually set aria-live and aria-atomic.

Live regions must be present in the DOM before content is injected into them. Injecting a live region and its content simultaneously often fails to trigger an announcement in JAWS and NVDA. The region needs to exist first, then content gets added.

How Does ARIA Affect SEO?

ARIA attributes are not ranking signals. Google’s John Mueller has stated directly that accessibility improvements do not give websites a direct advantage in search rankings, and that ARIA should be used for accessibility reasons, not SEO (Search Engine Roundtable, 2024).

Martin Splitt of Google has also addressed it: “Why slap ARIA on something that has a better, semantic alternative… And citing SEO myths as justification… No.”

What ARIA Does Not Change for Search

3 things ARIA does not affect in Google Search:

• Crawlable content (ARIA only modifies the accessibility tree, not HTML structure)
• Indexing (Googlebot indexes rendered HTML, not accessibility tree output)
• Direct ranking signals (confirmed by both Mueller and Splitt)

Googlebot renders JavaScript after an initial crawl pass, so JavaScript-updated ARIA attributes are visible to Googlebot post-render. But that visibility has no bearing on ranking.

Where Accessibility and SEO Do Overlap

Accessible sites tend to perform better in search indirectly. Not because of ARIA specifically, but because accessibility requirements overlap with factors Google does measure.

A study of 847 domains tracked by AccessibilityChecker.org found 73.4% experienced organic traffic increases after implementing accessibility fixes, with an average improvement of 12% across all domains. The cause is UX signal improvement, not ARIA recognition by Google’s ranking algorithms.

Proper heading structure, which benefits screen reader navigation, also helps Googlebot understand page hierarchy. Descriptive link text, required for web accessibility, directly improves anchor text quality for SEO. These are HTML-level improvements, not ARIA-level ones.

What Are the Most Common ARIA Mistakes?

ARIA implementation errors are widespread. Pages using ARIA averaged 34.2% more detected accessibility errors than pages without ARIA in the WebAIM Million 2025 analysis. More ARIA, badly applied, creates more problems than no ARIA at all.

These are the 6 patterns that show up most consistently across accessibility audits.

Applying ARIA Roles to Native Elements That Already Have Them

Adding role="button" to a <button>, or role="link" to an <a href> element, is redundant at best. At worst, some screen readers behave unexpectedly when they encounter a native element with an explicit role that duplicates its implicit one.

The rule: if the HTML element already has the role you need, do not add it manually. Use the semantic element and let the browser communicate the role natively.

Using aria-hidden on Focusable Elements

This one causes real harm. Setting aria-hidden="true" on a link, button, or input removes it from the accessibility tree but not from the tab order. Keyboard users land on it, screen readers say nothing. Confusing and disorienting.

35% of ARIA menus on the top one million home pages introduced accessibility barriers in the WebAIM Million 2025 report, with missing required markup and interactions being the core issue. Improper aria-hidden usage contributes directly to that number.

Not Updating Dynamic States

Setting aria-expanded="false" in HTML and never updating it with JavaScript is extremely common. The visual UI shows the panel open, but the ARIA state still says collapsed. Screen readers announce the wrong state to users.

Every dynamic ARIA state (aria-expanded, aria-checked, aria-selected, aria-pressed) must be updated programmatically on every user interaction that changes the UI.

Four More Patterns Worth Knowing

aria-label vs visible text mismatch: using aria-label to override visible button text with different wording breaks voice control software. Users cannot activate elements by saying text that differs from the accessible name.

role=”presentation” on structural elements: strips semantics from elements that carry meaningful information, breaking navigation for screen reader users relying on landmarks and headings.

Missing required owned elements: role="list" requires role="listitem" children. role="tablist" requires role="tab" children. Omitting the required child roles produces incomplete widget semantics that fail WCAG 4.1.2.

Injecting live region content simultaneously with the region: creates a timing issue where JAWS and NVDA miss the announcement entirely. The region must be in the DOM first.

How is ARIA Browser and Assistive Technology Support Measured?

ARIA support varies across screen reader and browser combinations. Writing correct spec-compliant ARIA does not guarantee identical behavior across all user environments. Support depends on 4 variables: the operating system, the browser, the assistive technology, and the version of each.

The A11Y Project notes that assistive technology users often run older versions of their software deliberately, to maintain stability. Newer ARIA features may not be supported in those environments at all.

Tools for Testing ARIA Support

a11ysupport.io tracks ARIA attribute and role support across screen reader and browser combinations. It is community-maintained and shows test results with dates so you can see how current the data is.

The recommended testing stack for ARIA patterns:

• axe DevTools for automated violation detection
• NVDA with Chrome on Windows (most common combination per WebAIM Survey 10, 2024)
• JAWS with Chrome or Edge on Windows
• VoiceOver with Safari on macOS and iOS
• TalkBack with Chrome on Android
• Accessibility Insights for Web for guided manual testing

Browser emulators and accessibility simulators are not adequate substitutes for real screen reader testing (MDN Web Docs). They miss interaction-level behaviors that only appear when actual assistive technology consumes the accessibility tree.

Where Real Support Gaps Exist

Some widely-used attributes have inconsistent real-world support. aria-controls shows a screen reader support level of partial (9/41 test scenarios passing) on a11ysupport.io. Spec-compliant code. Poor real-world announcement.

WAI-ARIA 1.2 additions with partial support as of 2024-2025: role="suggestion", role="comment", and aria-description have limited implementation across major screen reader and browser combinations.

The gap between what the spec defines and what assistive technologies actually do is why testing with real tools is non-negotiable. The WAI-ARIA APG patterns are tested combinations. Building from those patterns is safer than composing custom role sets from the spec alone.

For teams building accessible UI components at scale, Deque Systems’ axe DevTools and TPGi’s accessibility testing services provide systematic coverage beyond what individual developer testing can catch. Both organizations contribute directly to WAI-ARIA specification development and have public testing libraries used by major browser vendors.

FAQ on What Is ARIA

What does ARIA stand for?

ARIA stands for Accessible Rich Internet Applications. The full name is WAI-ARIA, where WAI refers to the Web Accessibility Initiative, the W3C subgroup that developed and maintains the specification.

What is the purpose of ARIA?

ARIA adds semantic meaning to HTML elements so assistive technologies like screen readers can understand them. It fills the gap left by native HTML, covering interactive widget roles, states, and properties that HTML alone cannot express.

Does ARIA change how a page looks or behaves?

No. ARIA only modifies the accessibility tree, the structure browsers expose to assistive technologies. It has no effect on visual appearance, CSS rendering, or JavaScript execution.

When should you use ARIA?

Use ARIA when native HTML cannot provide the required semantics. Custom tab panels, modal dialogs, sliders, and live regions are common cases. Always prefer a native HTML element first, per the first rule of ARIA use defined by W3C.

What are the three types of ARIA attributes?

ARIA attributes fall into three categories: roles (what an element is), states (its current condition, like aria-expanded), and properties (its relationships and labels, like aria-labelledby). WAI-ARIA 1.2 defines 48 states and properties in total.

Can ARIA make a non-interactive element keyboard accessible?

No. Adding role="button" to a <div> tells screen readers it is a button. It does not add keyboard focus or event handling. JavaScript must implement all interactive behavior separately.

Does ARIA help with SEO?

No. Google’s John Mueller has confirmed that ARIA attributes are not ranking signals. Google does not use ARIA for indexing or ranking. Use ARIA for accessibility, not to influence search engine results.

What is aria-hidden?

aria-hidden="true" removes an element from the accessibility tree without hiding it visually. Use it on decorative icons and duplicate content. Never apply it to focusable elements, as they remain in the keyboard tab order.

What is an ARIA live region?

A live region is an area of the DOM that announces changes to screen reader users automatically, without requiring focus to move. aria-live="polite" waits for a pause before announcing. role="alert" interrupts immediately for urgent updates.

What is the most common ARIA mistake?

Not updating dynamic states with JavaScript. Setting aria-expanded="false" in HTML and never toggling it means screen readers announce the wrong state. Every dynamic ARIA state must reflect the actual current condition of the UI at all times.

Conclusion

This conclusion is for an article presenting what is ARIA, and the core takeaway is straightforward: WAI-ARIA 1.2 exists to fill semantic gaps that native HTML cannot cover.

Used correctly, ARIA roles, states, and properties give screen reader users like NVDA and VoiceOver users the context they need to interact with complex widgets.

Used carelessly, it creates more barriers than it removes. The WebAIM Million data makes that clear.

Follow the five rules of ARIA use, test with real assistive technologies, and treat the WAI-ARIA Authoring Practices Guide as your reference for every custom component you build.

Accessible name computation, live region behavior, and keyboard-accessible controls are not optional extras. They are the baseline for any interface that claims to work for everyone.