Free community resource
WCAG 4.1.2

Accordion

WCAG criteria

An accordion is a vertically stacked set of interactive headings that each
reveal or hide associated content panels. They are commonly used to organise
large amounts of content into collapsible sections, reducing visual complexity
while keeping content accessible on demand.
[1]


Recommended implementation

The most accessible accordion uses the native HTML details and summary elements,
which provide built-in toggle behaviour, keyboard support, and screen reader
announcements with no JavaScript required.
[2]

For custom implementations using buttons and divs, the following pattern is required:

The trigger must be a button inside or as a heading. Never use a div or span.

Required attributes on the button:

  • aria-expanded="false" when the panel is collapsed
  • aria-expanded="true" when the panel is expanded
  • aria-controls referencing the id of the associated panel

Required attributes on the panel:

  • A unique id referenced by the button's aria-controls
  • hidden attribute when collapsed (or display: none via CSS)

[1]


Keyboard interactions

Key Action
Tab Move focus to next accordion header
Shift + Tab Move focus to previous accordion header
Enter / Space Toggle the focused panel open or closed
(Optional) Down arrow Move focus to next header
(Optional) Up arrow Move focus to previous header
(Optional) Home Move focus to first header
(Optional) End Move focus to last header

Arrow key navigation is optional for accordions — unlike tabs, it is not
required by the ARIA pattern.
[3]


Heading structure

Accordion triggers should be wrapped in heading elements at the appropriate
level for the page structure. This allows screen reader users navigating by
headings to find accordion sections:

  • h3 containing button — Accordion section title — /button — /h3

The heading level should fit the document outline — do not use h2 for all
accordions regardless of context.


Allow multiple panels open

Decide whether only one panel can be open at a time (exclusive) or whether
multiple can be open simultaneously. From an accessibility perspective,
allowing multiple panels open is generally preferable — closing a panel the
user opened is unexpected and disorienting.


Common mistakes

Using a div as the trigger. A div is not keyboard focusable or operable
by default and is not announced as a button by screen readers.

Missing aria-expanded. Without it, screen reader users cannot tell whether
a panel is open or closed.

Animating height instead of using hidden. Animating max-height for the
reveal effect is fine, but the panel must have display: none or hidden when
collapsed — otherwise its content remains in the accessibility tree and
screen readers can read it even when visually hidden.
[2]


References

  1. W3C Web Accessibility Initiative. ARIA Authoring Practices Guide — Accordion Pattern. https://www.w3.org/WAI/ARIA/apg/patterns/accordion/
  2. MDN Web Docs. The details and summary elements. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details
  3. W3C Web Accessibility Initiative. Understanding Success Criterion 4.1.2: Name, Role, Value. https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html

Last edited Apr 5, 2026, 7:20 PM · P**** J****