Use a website accordion when readers benefit from revealing selected sections while retaining clear labels for the rest. Evaluate it through 5 checks: content suitability, header wording, keyboard behaviour, expanded state and discovery. Hiding text is not automatically a better design than showing a well-structured page.
When does an accordion help rather than hide useful content?
Begin with the reading task. An accordion can suit distinct optional details that readers select according to their needs. It may be a poor fit when people must compare every section or understand a continuous argument. Write what the reader should find before choosing the pattern. A shorter-looking page is not evidence that the information has become easier to use.
Compare open sections, an accordion and a linked summary. Open sections make information immediately available; an accordion requires a reveal action; a summary can move the reader to the relevant heading. Test the same content in these arrangements where the decision is uncertain. Choose according to the observed task rather than a general preference for a tidy interface.
W3C’s accordion pattern defines a stack of interactive headers and associated panels. Use that relationship to organise the content. Each header should make the hidden material predictable. A label such as more information gives little help when several panels contain different subjects. Prefer specific wording that lets a reader choose a section without opening every one in turn.
Decide the expansion model deliberately. Some accordions permit several panels to remain open, while others allow only one. W3C describes these variations rather than prescribing one universal model. A reader comparing two related sections may need them visible together. A constrained step-by-step interface may have a different requirement. Record the reason for the chosen behaviour in the component brief.
Keep essential warnings or task instructions visible where their timing matters. A person should not need to discover a hidden panel to understand a condition necessary for the action they are taking. If content is frequently missed, reconsider whether it belongs inside the accordion. Do not solve poor prioritisation by opening every panel by default while retaining all the complexity of the pattern.
How should keyboard use and expanded state be tested?
Use a real control for the header. The W3C pattern places the title inside a button within an appropriate heading. This gives the implementation a semantic basis for interaction and structure. A clickable-looking text row does not establish equivalent keyboard or assistive-technology behaviour. Ask the developer to show the actual control and associated panel relationship, not only the visual icon.
Test Enter and Space on the focused header. W3C specifies opening a collapsed panel and, where supported, closing an expanded panel. The implementation should follow the selected model consistently. Check what happens when another panel is already open. A component can appear functional with a mouse while failing the keyboard interaction that the intended pattern requires.
Inspect the expanded state programmatically as well as visually. W3C describes aria-expanded on the controlling button and aria-controls linking to the panel. The visible icon, announced state and actual panel visibility should agree. If the state says expanded while the content is hidden, the interface communicates conflicting information. Keep that mismatch as a functional defect rather than a minor styling issue.
Test focus through the panel content. Tab and Shift+Tab should move through focusable elements according to the page sequence. Links and controls inside a revealed panel remain part of the task. Check that collapsing a section does not leave the user confused about where focus went. Test the exact implementation because the pattern description is guidance, not evidence that a particular component follows it.
Review discoverability outside the normal click path. Ask how readers find a specific section from a shared link, browser search or a printed copy if those uses matter. These behaviours need an explicit requirement and demonstration; they are not guaranteed merely by adding ARIA attributes. Preserve the useful underlying headings and content structure so the component remains understandable beyond its decorative presentation.
Add a permission-neutral error case to the accordion test. Put a required form field inside a panel, submit an invalid fictional entry and inspect how the error leads the user back to it. The design should not require guessing which closed section contains the problem. Define whether the relevant panel opens, how its error is announced and where focus belongs, then test the chosen behaviour. These are implementation requirements to demonstrate, not automatic features of every accordion. Retain the ordinary reading comparison as well: if every visitor must open the same section to complete the task, an open section may be the clearer design. The component should serve the content rather than dictate how important information is hidden.
The USWDS accordion guidance makes the content decision concrete: use selective disclosure when readers need particular pieces; prefer formatted text when they need most information. Its tested component still requires testing in your own project.
Decision worksheet
Original contribution: an accordion reveal-and-discovery worksheet. Put a fictional service page’s optional details into named sections. Ask a reader to choose the relevant section from the closed headers, then complete a keyboard-only task inside it. Record the expected panel, observed state, focus route and final action. Repeat with an open-section version of the same content. Add a comparison task requiring information from different panels. The worksheet tests whether the pattern helps the reader select information or merely hides material that everyone needs.
| Checkpoint | Evidence to retain | Decision or corrective action |
|---|---|---|
| Content suitability | Reader task and open-section alternative | Avoid hiding required information |
| Header wording | Predicted content and actual panel | Use specific section labels |
| Keyboard | Enter, Space, Tab and Shift+Tab results | Match the selected expansion model |
| Expanded state | Visual, announced and actual state | Repair contradictory state |
| Discovery | Shared link, search or print task | Define behaviour beyond clicking |
For a worked exception, place a fictional eligibility condition in a panel and ask someone to begin the related enquiry task. If they miss the condition because the header does not signal its importance, revise the placement or label. Then test a longer section containing a link and a form control. The component must support the content it actually contains, rather than only a short demonstration sentence. Keep these observations with the implementation evidence.
A successful pattern review requires the real component and relevant assistive-technology evaluation; this written guide does not certify an unseen interface. See web development for implementation scope and WordPress for platform context. To discuss an accordion, get started with the content and worksheet.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.