Accessible Accordions and Tabs: WAI-ARIA 1.2 Design Patterns & Keyboard Interaction

Accordions and tabbed interfaces are among the most common disclosure components used in modern web design for FAQs, pricing comparisons, and configuration dashboards. However, using unstyled <div> tags with custom click handlers creates major accessibility hurdles for screen reader and keyboard-only users. Adhering to the **WAI-ARIA 1.2 Authoring Practices** guarantees full compliance and intuitive navigation.

When to Use Accordions vs Tab Panels

Choose accordions when multiple sections may need to be expanded simultaneously or when designing for narrow mobile viewports. Choose tabs when content sections represent mutually exclusive views on wider screens.

The WAI-ARIA Accordion Pattern (aria-expanded, aria-controls)

An accessible accordion structure requires:

• Each accordion header must be wrapped in an appropriate heading tag (<h2>, <h3>).
• The header trigger must be a native <button> element.
• The button must carry aria-expanded="true|false" and aria-controls="panel-id".

The WAI-ARIA Tabs Pattern (tablist, tab, tabpanel)

Keyboard Interaction Models (Arrow Keys vs Tab)

For tabs, implement roving tabindex: only the currently selected tab has tabindex="0", while all unselected tabs have tabindex="-1". Pressing → or ← updates selection and shifts focus.

Production-Ready Code Implementation

<!-- Accessible Accordion Item -->
<div class="accordion-item">
  <h3 class="accordion-header">
    <button type="button" class="accordion-trigger" aria-expanded="false" aria-controls="faq-ans-1" id="faq-btn-1">
      How does continuous accessibility scanning work?
    </button>
  </h3>
  <div id="faq-ans-1" class="accordion-panel" role="region" aria-labelledby="faq-btn-1" hidden>
    <p>Rogabot continuously scans your web pages on autopilot...</p>
  </div>
</div>