Accessible Accordion and Tab Patterns: Progressive Disclosure Done Right

Accordions and tabs are workhorses of progressive disclosure — showing users manageable chunks of content without overwhelming them with everything at once. Both patterns have well-defined W3C WAI-ARIA specifications, but their keyboard models differ significantly. Choosing the right pattern and implementing it correctly determines whether your progressive disclosure helps or hinders users.

The Tab Pattern

Tabs present multiple content panels in a shared space, with one panel visible at a time. The W3C ARIA tablist pattern defines the structure and interaction model.

ARIA Structure

<div role="tablist" aria-label="Account settings">
  <button role="tab" id="tab-profile" aria-selected="true" aria-controls="panel-profile">
    Profile
  </button>
  <button role="tab" id="tab-security" aria-selected="false" aria-controls="panel-security" tabindex="-1">
    Security
  </button>
  <button role="tab" id="tab-billing" aria-selected="false" aria-controls="panel-billing" tabindex="-1">
    Billing
  </button>
</div>

<div role="tabpanel" id="panel-profile" aria-labelledby="tab-profile">
  <!-- Profile content -->
</div>
<div role="tabpanel" id="panel-security" aria-labelledby="tab-security" hidden>
  <!-- Security content -->
</div>
<div role="tabpanel" id="panel-billing" aria-labelledby="tab-billing" hidden>
  <!-- Billing content -->
</div>

Keyboard Interaction

The tab pattern uses roving tabindex — only the active tab is in the Tab order, and users navigate between tabs with arrow keys:

• Tab: Moves focus into the tablist (lands on the active tab), then Tab again moves to the tab panel content
• Left Arrow / Right Arrow: Moves between tabs (horizontal tablist)
• Up Arrow / Down Arrow: Moves between tabs (vertical tablist)
• Home: Moves to the first tab
• End: Moves to the last tab
• Enter / Space: Not strictly needed since arrow keys activate tabs, but many implementations activate on these keys for discoverability

Automatic vs. Manual Activation

• Automatic activation: The tab panel changes as soon as the user arrows to a new tab. This is recommended when panel content loads instantly.
• Manual activation: The user arrows to a tab, then presses Enter or Space to reveal the panel. Use this when tab panels require network requests or expensive rendering.

The W3C recommends automatic activation when feasible, as it provides immediate feedback.

The Accordion Pattern

Accordions stack content sections vertically, each with a header that toggles its panel open or closed. Unlike tabs, multiple accordion panels can be open simultaneously (though some implementations restrict to one at a time).

ARIA Structure

<div class="accordion">
  <h3>
    <button aria-expanded="true" aria-controls="section1-content" id="section1-header">
      Shipping Information
    </button>
  </h3>
  <div id="section1-content" role="region" aria-labelledby="section1-header">
    <!-- Content -->
  </div>

  <h3>
    <button aria-expanded="false" aria-controls="section2-content" id="section2-header">
      Return Policy
    </button>
  </h3>
  <div id="section2-content" role="region" aria-labelledby="section2-header" hidden>
    <!-- Content -->
  </div>
</div>

Key points:

• The toggle is a <button> inside a heading element, preserving the document outline while providing keyboard interactivity
• aria-expanded communicates the open/closed state
• aria-controls links the button to its associated content panel
• The role="region" with aria-labelledby on the content panel makes it a labeled landmark, useful for longer content sections

Keyboard Interaction

Accordions follow a simpler keyboard model than tabs:

• Tab: Moves between accordion headers (each button is in the natural Tab order)
• Enter / Space: Toggles the associated panel open or closed
• Down Arrow: Optionally moves focus to the next accordion header
• Up Arrow: Optionally moves focus to the previous accordion header
• Home: Optionally moves focus to the first accordion header
• End: Optionally moves focus to the last accordion header

Arrow key navigation is optional for accordions. Many accessible implementations use Tab-only navigation, which is simpler and still fully compliant.

Choosing Between Tabs and Accordions

Factor	Tabs	Accordion
Content relationship	Parallel content, same level of importance	Sequential or independent sections
Number of sections	2–7 (more requires scrolling the tab bar)	Any number
Multi-open	No (one panel visible at a time)	Yes (multiple panels can be open)
Responsive behavior	Often converts to accordion on mobile	Works at all viewport sizes
Keyboard model	Arrow keys (roving tabindex)	Tab key (natural tab order)
Content length	Short to moderate per panel	Any length per section

For mobile-first design, accordions are generally safer. Tabs require horizontal space for the tab bar and can overflow awkwardly on narrow screens. A common pattern is to render tabs on desktop and convert to an accordion on mobile — but this requires implementing both keyboard models correctly, so consider whether the complexity is warranted.

Common Implementation Mistakes

Tabs

• Using links instead of buttons: Tab controls should be <button> elements with role="tab". Links (<a>) imply navigation to a new page or location.
• Missing roving tabindex: If all tabs are in the Tab order, keyboard users must press Tab multiple times to reach the panel content. Only the active tab should have tabindex="0".
• Not hiding inactive panels from screen readers: Use hidden attribute or display: none on inactive panels. Setting only visibility: hidden or opacity: 0 leaves content accessible to screen readers.

Accordions

• Using <div> instead of <button> for headers: Divs and spans are not keyboard focusable or operable by default. Use a <button> inside a heading.
• Missing aria-expanded: Without this attribute, screen reader users cannot tell whether a section is open or closed.
• Preventing all panels from closing: Some implementations force at least one panel to remain open. This can frustrate users who want to close everything and scan the headers. Allow all panels to close unless there is a strong UX reason not to.

Nesting Tabs and Accordions

Avoid nesting tabs within tabs or accordions within accordions. Nested progressive disclosure creates deep information hierarchies that are difficult to navigate, especially for screen reader users who must track multiple levels of state. If content requires nesting, consider restructuring the information architecture with proper navigation patterns instead.

Testing

1. Keyboard: Navigate tabs with arrow keys, accordions with Tab. Verify Enter/Space toggles correctly.
2. Screen reader: Confirm that tabs announce their role (“tab, 1 of 3”), selection state, and associated panel. Confirm accordions announce expanded/collapsed state.
3. Zoom: At 400% zoom, verify tab bars do not overflow and accordion content remains readable.
4. Automated: axe DevTools checks for proper ARIA roles and relationships. See web accessibility testing methodology for a comprehensive testing approach.

Key Takeaways

Tabs and accordions serve similar goals but have fundamentally different keyboard models and structural assumptions. Tabs use arrow keys and show one panel at a time; accordions use Tab navigation and support multiple open panels. Choose based on content relationship and viewport constraints. Implement the correct ARIA roles and keyboard interactions for whichever pattern you choose — hybrid approaches that mix the two models create confusion for assistive technology users.

Sources

• W3C WAI-ARIA APG: Tabs Pattern — The authoritative ARIA tab interface pattern.
• W3C WAI-ARIA APG: Accordion Pattern — The authoritative ARIA accordion pattern.
• Deque University: Tabs and Accordions — Implementation examples with accessibility testing.
• WebAIM: ARIA Tab Panels — Practical ARIA implementation guidance.