ARIA Patterns That Actually Help

By Michael Samuel Naeem · March 9, 2026 · 5 min read

A client ran an accessibility audit and got flagged for 47 ARIA violations — and 31 of them were on pages where developers had added ARIA thinking they were helping. role="button" on a <button>, aria-label duplicating visible text, role="navigation" on a <nav>. The pages were less accessible after the ARIA pass than before. ARIA is a power tool: used correctly it makes custom widgets usable by screen readers; used incorrectly it overrides the browser's built-in semantics and confuses assistive technology. Here's how to get it right.

Rule zero: native HTML first

Before reaching for ARIA, check if HTML already solves it:

Native elements come with keyboard handling, focus management, and screen reader support for free.

When ARIA is necessary

Custom widgets that have no HTML equivalent:

• Tab panels
• Comboboxes (autocomplete)
• Tree views
• Drag-and-drop lists
• Toast notifications
• Modal dialogs (partially — see <dialog>)

For these, follow the WAI-ARIA Authoring Practices Guide patterns exactly. They specify roles, keyboard interactions, and focus management for each widget.

Roles: what something is

<!-- Tab interface -->
<div role="tablist">
  <button role="tab" aria-selected="true" aria-controls="panel-1" id="tab-1">
    Account
  </button>
  <button role="tab" aria-selected="false" aria-controls="panel-2" id="tab-2">
    Settings
  </button>
</div>
<div role="tabpanel" id="panel-1" aria-labelledby="tab-1">
  Account content
</div>
<div role="tabpanel" id="panel-2" aria-labelledby="tab-2" hidden>
  Settings content
</div>

Each role carries expected keyboard behavior. Tabs require Arrow key navigation, Home/End, and automatic activation or manual activation depending on the pattern.

States: what changes

States update as the user interacts:

<!-- Disclosure widget -->
<button aria-expanded="false" aria-controls="details-section">
  Show details
</button>
<div id="details-section" hidden>
  Detail content here
</div>

<script>
  button.addEventListener('click', () => {
    const expanded = button.getAttribute('aria-expanded') === 'true';
    button.setAttribute('aria-expanded', String(!expanded));
    details.hidden = expanded;
  });
</script>

Critical states:

• aria-expanded — disclosure, menus, comboboxes
• aria-selected — tabs, listbox options
• aria-checked — checkboxes, radio buttons, switches
• aria-disabled — disabled interactive elements
• aria-hidden — hide decorative elements from screen readers

Properties: relationships

<!-- Form field with label and error -->
<label id="email-label" for="email">Email</label>
<input id="email" type="email"
       aria-labelledby="email-label"
       aria-describedby="email-error"
       aria-invalid="true">
<span id="email-error" role="alert">Enter a valid email address</span>

• aria-labelledby — points to the element(s) that label this one
• aria-describedby — points to descriptive text (errors, hints)
• aria-controls — points to the element this one controls
• aria-owns — parent-child relationship for complex widgets

Live regions: announce dynamic changes

<!-- Search results count -->
<div aria-live="polite" aria-atomic="true" class="sr-only">
  {{ resultCount }} results found
</div>

<!-- Error alert -->
<div role="alert" aria-live="assertive">
  Your session has expired. Please log in again.
</div>

<!-- Loading status -->
<div role="status" aria-live="polite">
  Loading results...
</div>

Use polite for most updates. Reserve assertive for errors and urgent warnings.

Common mistakes

Redundant ARIA. Don't add role="button" to <button> or aria-label="Close" when the button text already says "Close."

Missing keyboard support. role="button" on a <div> requires you to implement Enter/Space key handling and focus management. Use <button> instead.

aria-hidden on focusable elements. Never hide interactive elements with aria-hidden="true" — screen readers skip them but keyboard users can still tab to them.

Stale states. If aria-expanded doesn't update when the panel opens, screen readers report the wrong state. Keep ARIA states in sync with visual state.

Over-nesting roles. One role per element. Don't put role="tab" inside role="tablist" inside role="navigation" inside role="main" unless each is semantically correct.

Testing ARIA

1. Automated scan — axe-core or Lighthouse catch missing labels and invalid roles
2. Screen reader test — VoiceOver (macOS), NVDA (Windows), or TalkBack (Android)
3. Keyboard-only navigation — Tab through the page, verify focus is visible and actions work
4. Inspect accessibility tree — Chrome DevTools → Elements → Accessibility pane

Automated tools catch ~30% of accessibility issues. Screen reader testing catches the rest.

Common production mistakes

Teams get accessibility aria patterns wrong in predictable ways:

• Skipping failure-mode rehearsal — run a game day or fault injection exercise before peak traffic, not after the first outage.
• Missing correlation context — every error path should carry request, trace, or tenant identifiers so incidents are debuggable.
• Optimizing for demo, not steady state — load tests, cache warm-up, and cold-start paths matter more than local dev latency.
• Undocumented trade-offs — if you chose speed over strict correctness (or vice versa), write that down for the next engineer.

Production implementations of accessibility aria patterns fail when staging mirrors production topology poorly, rollback is untested, and on-call runbooks describe the happy path only.

Debugging and triage workflow

When accessibility aria patterns misbehaves in production, work top-down instead of guessing:

1. Confirm scope — one tenant, region, or deployment stage? Narrow blast radius before deep diving.
2. Check recent changes — deploys, flag flips, config pushes, and schema migrations in the last 24 hours.
3. Compare golden signals — latency, error rate, saturation, and traffic for the affected surface vs. baseline.
4. Reproduce minimally — smallest input or scenario that triggers the failure; capture traces/logs with correlation IDs.
5. Fix forward or rollback — if rollback is faster than root-cause during incident, rollback first, postmortem second.
6. Add a guard — alert, integration test, or circuit breaker so the same class of failure is caught earlier next time.

Document the timeline during triage. Future you (and on-call) will need timestamps, not just conclusions.

Resources

• WAI-ARIA Authoring Practices Guide
• ARIA first rule (W3C)
• MDN ARIA reference
• axe-core accessibility engine
• WebAIM ARIA techniques