ARIA Errors Outnumber Non-ARIA Pages: Fix Guide

Scope

This guide addresses why pages with ARIA attributes often have more detected errors than those without. It offers decision-making frameworks for using ARIA, identifies common misuse patterns, and explains the role of automated detection tools in your testing workflow.

Use this guide when reviewing component libraries, evaluating third-party widgets, or setting standards for teams building interactive interfaces.

Key Concepts and Definitions

ARIA (Accessible Rich Internet Applications): A W3C specification that extends HTML semantics to communicate dynamic interface states and custom widget roles to assistive technology. ARIA doesn't change visual presentation or keyboard behavior.

The First Rule of ARIA: Use a native HTML element or attribute with the required semantics and behavior instead of re-purposing an element and adding an ARIA role, state, or property.

ARIA State vs. Property: States change frequently during interaction (aria-expanded, aria-checked). Properties define relationships or describe widgets (aria-label, aria-describedby). Both must reflect actual interface behavior.

Keyboard Trap: A navigation failure where keyboard focus enters a component but can't exit using standard keys. Adding role="dialog" or role="menu" without proper keyboard patterns creates traps that violate WCAG 2.1 Success Criterion 2.1.2.

Requirements Breakdown

When ARIA Is Required

ARIA is necessary when building interfaces that HTML can't describe natively:

• Custom widgets with no HTML equivalent (tree grids, sliders with multiple thumbs)
• Dynamic content regions that update without page reload (live regions for status messages)
• Complex relationships between elements (aria-controls, aria-owns)
• Landmark roles for sections in legacy markup that predates HTML5 semantic elements

When ARIA Creates Violations

Data from WebAIM shows pages with ARIA often have more errors. This happens when teams add ARIA without understanding three requirements:

Requirement 1: Role Implies Behavior
Adding role="button" to a <div> doesn't make it keyboard-operable. You must implement Space and Enter key handlers. Adding role="menu" requires arrow key navigation, Escape to close, and focus management. The role is a promise to assistive technology about how the component works.

Requirement 2: States Must Toggle
Setting aria-expanded="false" on a disclosure button means you must change it to "true" when the panel opens. Static ARIA states that never update create false information for screen reader users. This violates WCAG 2.1 Success Criterion 4.1.2.

Requirement 3: ARIA Overrides Native Semantics
Adding role="presentation" to a <button> removes its button semantics. Adding aria-label to an element with visible text creates a mismatch between what sighted users see and what assistive technology announces. This breaks WCAG 2.1 Success Criterion 2.5.3.

Implementation Guidance

Decision Tree for ARIA Use

Before adding any ARIA attribute, consider these steps:

1. Can native HTML do this? Use <button>, <nav>, <main>, <dialog> instead of divs with roles.

2. Does the dynamic behavior require announcement? Use aria-live for status messages, aria-expanded for disclosures, aria-current for navigation state.

3. Can you implement the full keyboard pattern? Don't add role="menu" unless you're building actual application menus with arrow navigation. Use <nav> with a list of links for site navigation.

4. Will this create a label mismatch? If visible text says "Submit" but aria-label says "Submit form to database," you've created a speech input failure. The accessible name must include the visible text.

ARIA Patterns That Reduce Risk

Pattern 1: Enhance Native Elements

<button aria-expanded="false" aria-controls="panel-id">

The button is already keyboard-operable. ARIA adds state information.

Pattern 2: Live Regions for Updates

<div role="status" aria-live="polite">

Use for form validation messages, search result counts, or loading states. Don't use for content that requires interaction.

Pattern 3: Landmark Roles for Legacy Markup
If you can't change <div class="header"> to <header>, add role="banner". But prioritize updating the markup.

Testing Requirements Beyond Automation

Automated tools like WAVE detect missing labels and invalid ARIA syntax. They can't detect:

• Whether your aria-expanded value toggles correctly
• Whether role="dialog" includes focus trapping
• Whether custom widgets respond to expected keyboard commands
• Whether aria-label text matches visible labels

Your conformance testing program must include manual keyboard testing and screen reader verification. Use NVDA with Firefox or JAWS with Chrome to verify that announced information matches visual state.

Common Pitfalls

Pitfall 1: Adding Roles Without Keyboard Support
You add role="button" to make a <div> clickable. Screen readers announce it as a button, but keyboard users can't activate it with Space or Enter. Use <button> instead.

Pitfall 2: Static aria-expanded Values
Your disclosure widget sets aria-expanded="false" in the initial markup but never updates it when users click. Screen readers always announce "collapsed" even when the panel is visible.

Pitfall 3: role="menu" for Navigation
You add role="menu" to your site navigation because it's a menu. But ARIA menus are application menus (like Edit > Copy) that require arrow key navigation and don't allow Tab key movement. Site navigation should use <nav> with a list of links.

Pitfall 4: Redundant ARIA on Native Elements
You add aria-label="Submit" to a button that already contains the text "Submit." This creates maintenance burden and risks mismatches. The button already has an accessible name from its content.

Pitfall 5: aria-hidden on Focusable Elements
You hide a modal backdrop with aria-hidden="true" but leave interactive elements inside it focusable. Keyboard users reach controls that screen readers can't perceive. Elements with aria-hidden="true" must not contain focusable descendants.

Quick Reference Table

Scenario	Wrong Approach	Correct Approach
Clickable div	<div role="button">	<button>
Site navigation	<div role="menu">	<nav><ul><li><a>
Collapsible panel	Static aria-expanded	Toggle aria-expanded on click
Form field label	aria-label duplicating <label>	Use <label> only
Live status message	Change text content without ARIA	<div role="status" aria-live="polite">
Modal dialog	aria-hidden without focus trap	Implement focus trap per ARIA Authoring Practices
Custom slider	Add role="slider" only	Add role + keyboard handlers + aria-valuemin/max/now
Landmark in legacy markup	Leave as <div>	Add role="main" or role="navigation"
Button with icon and text	aria-label overriding visible text	Let visible text provide name
Tab panel	No ARIA	aria-controls linking tab to panel

Your automated testing will flag missing labels and invalid syntax. It won't flag incomplete keyboard implementations or static state values. Schedule manual testing with keyboard navigation and screen reader verification for any component using ARIA roles or states.