Accordion Accessibility: How to Fix Your FAQ Section

An accessible FAQ accordion needs four things: each question is a real <button> wrapped in a heading, that button carries an aria-expanded state that flips between false and true, collapsed answers are truly hidden from keyboards and screen readers, and both Enter and Space toggle the panel. Those requirements come straight from the W3C’s official accordion pattern — and the FAQ section your page builder generated probably fails at least one of them.

We checked the big builders’ accordions by hand for this article, and the results are below. First, here’s how to test yours in about five minutes, no coding required.

The four checks every FAQ accordion must pass

Run these in order on your own FAQ page. Each one maps to a specific requirement in the W3C ARIA Authoring Practices Guide (APG) accordion pattern, and each one shows up in real audit findings.

1. Button, not div. Right-click a question, choose Inspect, and look at the highlighted tag. It should be <button> or <summary> — not <div>, <span>, <p>, or a bare <a> with no destination.
2. aria-expanded flips. In that same inspector view, click the question on the page and watch the markup. An aria-expanded attribute should change from false to true and back. (Native <details> elements gain an open attribute instead — that also passes.)
3. Closed answers are truly hidden. Press Tab repeatedly through a closed FAQ item. If your focus disappears into links inside an answer you can’t see, the panel is only visually hidden — screen readers can wander into it too.
4. Enter and Space both toggle it. Tab to a question and press Enter, close it, then press Space. The APG spec is explicit that both keys must expand and collapse the panel when the header has focus.

Pass all four and your FAQ accordion is in good shape. Now let’s look at why each check matters and what failing it does to a real visitor.

Why does the question need to be a real button?

Because a <div onclick> tells assistive technology nothing. A native <button> announces itself as a button, joins the Tab order automatically, and fires on both Enter and Space for free. A styled div does none of that: a screen reader reads the question as plain text with no hint it can be activated, and a keyboard user can’t even reach it.

That’s a failure of WCAG 2.1.1 Keyboard and of 4.1.2 Name, Role, Value, which requires every interactive control to expose what it is and what state it’s in. The APG pattern adds one more layer: wrap the button in a heading, and — quoting the spec — “the button element is the only element inside the heading element.” The heading is what lets a screen-reader user jump from question to question instead of arrowing through your whole page.

If your inspector shows a div with role="button" bolted on, be skeptical: retrofitted roles are where most breakage starts, as we cover in why ARIA is the most misused tool in accessibility.

What does aria-expanded actually do?

It’s the accordion’s state announcement. Per MDN’s reference, “the aria-expanded attribute is set on an element to indicate if a control is expanded or collapsed, and whether or not the controlled elements are displayed or hidden.” When it’s present and correct, a screen reader announces something like “Do you ship internationally, button, collapsed” — and after activation, “expanded.”

Two details trip up page-builder markup. The attribute belongs on the button, not on the panel — MDN is explicit that the toggling control carries aria-expanded plus an aria-controls reference to the panel’s id. And it has to actually flip: an aria-expanded="false" that stays false after the panel opens is worse than nothing, because it tells the user the answer never appeared.

This is the same state-announcement problem we found in hamburger menus — the accordion is just the FAQ-shaped version of it.

Is the closed answer really hidden?

The test is simple: if Tab lands on links inside a collapsed answer, the panel isn’t hidden — it’s just invisible. Builders that animate panels with max-height: 0 and overflow: hidden leave the content fully present for keyboards and screen readers. A blind visitor hears answers to questions that appear closed; a sighted keyboard user watches their focus vanish into nowhere.

The fix is to hide collapsed panels for everyone: display: none, the hidden attribute, or a native <details> element, any of which removes the content from the accessibility tree and the Tab order until it’s opened. Credit where due — when we inspected Squarespace’s accordion block, its collapsed panels use display: none, which passes this check cleanly.

If focus disappearing sounds familiar, it’s the mirror image of the modal problem — popups that fail to trap focus, which we tear down in popup and modal accessibility.

How do the big page builders’ accordions score?

Mixed — and better than a few years ago, with one big legacy exception. Here’s what we found inspecting live markup and vendor bug trackers in July 2026:

The Elementor case deserves emphasis because so many WordPress sites still run the old widget. An Elementor maintainer announced in October 2023 that the Nested Accordion shipped in v3.17 is “fully accessible” and added: “We recommend that you replace all your accordions and toggles with the new Nested Accordion.” If your FAQ was built before late 2023 and never rebuilt, you are likely still serving the broken widget — one of several template-level issues we see on WordPress sites.

Shopify merchants on older or third-party themes shouldn’t assume Dawn’s good markup carries over; app-injected FAQ widgets are a recurring offender in our Shopify audits.

Should you skip the accordion and just show the answers?

Often, yes. If most visitors need most of your answers, hiding them behind clicks costs more than it saves. Nielsen Norman Group’s guidance is to avoid accordions when your audience needs most or all of the content on the page, because scrolling past an answer is cheaper than clicking to reveal it — and content hidden behind headers gets overlooked and prints poorly.

A plain list of question headings with visible answers has zero accordion accessibility problems, because there’s no widget to get wrong: no button semantics, no state to announce, no hidden panels. For a five-question FAQ, that’s usually the better page. Save the accordion for genuinely long FAQ libraries where scanning twenty expanded answers would be worse.

Does FAQ schema justify keeping the accordion?

Not anymore. The old pitch for FAQ accordion plugins was the rich result — your questions appearing as dropdowns inside Google. That feature is gone. Google limited FAQ rich results to “well-known, authoritative government and health websites” in September 2023, and its Search Central changelog then recorded the full retirement: FAQ rich results “no longer appear in Google Search starting May 7, 2026,” with the documentation removed that June.

So a widget that promises schema-powered rankings in exchange for inaccessible markup is offering you nothing for something. Well-written question-and-answer content still earns search traffic — questions matching real queries, answers that stand on their own — and accessible markup serves the same crawlers it serves users. But the markup trophy the accordion vendors sold is off the table.

What to hand your developer

Test first, then delegate. Run the four checks, note which ones each FAQ page fails, and send your developer or agency this spec:

1. Rebuild each question as a <button> inside a heading (h2/h3 to match the page outline), per the APG accordion pattern.
2. Put aria-expanded and aria-controls on the button, and toggle aria-expanded in the click handler.
3. Hide collapsed panels with display: none or the hidden attribute — no max-height tricks.
4. Or skip the custom widget entirely: native <details>/<summary> handles the button, the keys, the state, and the hiding in plain HTML.
5. On Elementor: swap legacy Accordion/Toggle widgets for the Nested Accordion, as Elementor itself recommends.

One honest caveat: a passing FAQ accordion doesn’t make the rest of the page compliant. The same template that generated the accordion generated your menus, forms, and product grids, and a ten-minute keyboard pass usually finds siblings of whatever the accordion got wrong. That’s why we fix components in the source markup as part of manual remediation rather than patching one widget at a time.

Want to know whether your FAQ section — and everything around it — flags before a demand letter finds out first? Start with a free scan.