Jump to content

Accordions

Accordions consist of a number of content panels, each of which can be expanded or collapsed vertically by the user.

Accordions help to save vertical space and reduce visual noise. Some accordions allow only a single panel to be expanded at a time, others allow multiple.

Accordion

Before you continue, please read Tablist widgets (or: tab panels, tabs) to understand why accordions simply are extended variants of tablists, providing a slightly different layout and (sometimes) expandability of multiple panels.

General requirements

The following requirements are based on well established best practices and the WAI-ARIA Authoring Practices Guide (APG): Accordion Pattern.

Accordions and Tablists share the same underlying logic: a trigger (header/tab) controls the visibility of a content panel. While they are structurally similar, accordions have specific requirements:

  • Multiple panels can be visible at the same time (optional).
  • Keyboard support: Users can navigate between accordion headers using Tab and toggle them with Enter or Space. (Optional but recommended: Arrow key navigation).

Proofs of concept

Update 2020: Due to the fact that Internet Explorer doesn’t need to be supported anymore (see Relevant combinations of screen readers and browsers), we now favor the Simple ARIA implementation.

Simple ARIA implementation

It is relatively simple to create a custom accordion implementation with ARIA:

Accordion with ARIA (APG pattern)Preview

Implementation details

This implementation follows the current APG approach and uses a real button in each header.

  • The button toggles aria-expanded (true/false).
  • The button uses aria-controls to reference the associated panel.
  • The panel uses role="region" and aria-labelledby to expose a clear relationship back to the controlling header button.
  • The panel visibility is synchronized with the semantic state using JavaScript.

Native HTML Disclosure Elements

For simple disclosure-like use cases, the native HTML <details> and <summary> elements are a solid, no-JavaScript option. You can find the technical specification and browser behavior in the MDN Web Docs for the Details element.

  • The summary element works as the interactive header.
  • The surrounding details element manages the expanded/collapsed state natively.
  • This removes the need for JavaScript compared to custom ARIA widgets.

Accordion with details and summaryPreview

Implementation details

This implementation follows the current APG approach and uses a real button in each header.

  • The button toggles aria-expanded (true/false).
  • The button uses aria-controls to reference the associated panel.
  • The panel uses role="region" and aria-labelledby to expose a clear relationship back to the controlling header button.
  • Keyboard Navigation: Implementation should ideally support Arrow keys (Up/Down) to move focus between headers, and Home/End to jump to the first/last header.

Comparison: ARIA vs. Native HTML

Comparison of Implementation Methods

Implementation Method Advantages Limitations
Custom ARIA Implementation
  • Full control over keyboard behavior (e.g. arrow keys).
  • Better for complex layouts/nested widgets.
  • Exact state control via JS.
  • Requires JavaScript for state and interaction.
  • Higher maintenance (must handle all ARIA states manually).
Native Disclosure Elements (<details>)
  • Works without JavaScript.
  • Native accessibility "out of the box".
  • Minimal code footprint.
  • Limited styling options.
  • No native support for "only one open" (requires JS).
  • Default keyboard support is limited to Tab/Space/Enter.

Legacy implementations (Historical)

Note: The following legacy variants are deprecated and provided for historical reference only.

For all new projects, use one of the recommended implementations above (ARIA or native <details>/<summary>, depending on your requirements).

Accordion with radio buttons (Legacy — for reference only)*
Multi accordion with checkboxes (Legacy — for reference only)