Accessible Accordions and FAQs: The Collapse-and-Expand Pattern Everyone Gets Wrong

If you run a website that has ever answered a customer question, you almost certainly have an accordion somewhere. It might be a FAQ section on your pricing page. It might be product specifications that collapse until clicked. It might be a “What’s included?” box on a course landing page, or shipping information on a product detail page. The pattern is everywhere: a short heading, a small triangle or plus sign, and content that appears when you click.

Accordions feel like a solved problem. They are not. When we audit websites, the accordion is the single most common place we find critical WCAG violations outside of cookie banners. The pattern looks simple, so designers assume it is safe. Developers reach for a quick jQuery plugin or a Webflow interaction. Nobody tests it with a keyboard. And the result is a widget that visually does what it is supposed to but silently excludes a meaningful percentage of your visitors.

This guide is for non-developers: site owners, marketers, content strategists, and product managers who need to identify and fix accordion accessibility without writing code. We will cover how to spot the failures in thirty seconds, the five issues that break almost every accordion we test, and what to tell your designer or developer to change.

Why accordions fail more than most interactive elements

Buttons, links, and form fields have been around since 1994. Browsers handle them. Screen readers handle them. You have to work hard to make a plain button inaccessible. Accordions, on the other hand, are a custom widget. There is no <accordion> HTML element. Every accordion on the web is a developer’s interpretation of how to make a block of content collapse and expand, and most implementations skip the parts that are invisible to sighted users but essential to everyone else.

The pattern also invites shortcuts. A designer draws a row with a triangle icon, a developer wires up a click handler, and the thing expands and collapses. Visually it works. Meanwhile, the HTML underneath is often a <div> with no role, no aria-expanded state, no keyboard focus, and no programmatic connection between the header and the content it controls. A screen reader user who lands on the FAQ section hears a flat wall of unlabeled headings with content that either appears when it should not, or never appears at all.

The European Accessibility Act, which took effect in June 2025, treats accordions as interactive components that must meet WCAG 2.1 Level AA. ADA Title III lawsuits in the United States have cited FAQ and collapsible sections specifically. In other words, the accordion is not a niche accessibility concern. It is a legal risk surface, and one that your content team is probably creating more of every month.

The thirty-second test: can you operate your accordion without a mouse?

Put your mouse down. Click into your browser’s address bar and press Tab. Keep pressing Tab until your keyboard focus reaches the first accordion header on your page. Now answer these three questions.

One. Can you see where the focus is? There should be a visible ring, outline, or highlight around the accordion header. If you cannot tell which header is focused, you have a focus visibility failure that affects every keyboard user on your site, not just people with disabilities. Users who navigate with a trackpad, external keyboard, or switch device are affected too.

Two. Does pressing Enter or Space expand the section? Try both. A properly built accordion responds to Enter and to Space when the header is focused. If nothing happens, the header is not actually a button. It is probably a styled <div> or <span>, which means a screen reader will announce it as plain text and a keyboard user cannot operate it at all.

Three. After the section expands, can you Tab into the content? You should be able to Tab forward and reach any links or buttons inside the expanded content. You should also be able to Shift-Tab backward out of the content and continue navigating the page. If you cannot, the accordion has a focus management problem and keyboard users will skip your content entirely.

If your accordion fails any of these three checks, you have at minimum a Level A WCAG violation. Most accordions we audit fail all three.

The five failures we find on almost every site

After auditing hundreds of accordion implementations, the same five issues show up over and over. Share this list with your developer or agency and ask them to confirm each one is handled.

One: the header is not a real button

The single most common accordion failure is building the header as a clickable <div> instead of a <button>. A <div> is not focusable by default, does not respond to keyboard input, and announces as plain text in a screen reader. A <button> is focusable, responds to Enter and Space automatically, and announces as “button” with the state “expanded” or “collapsed” when paired with the right ARIA attribute.

The fix is to wrap the header text in a <button type="button"> element. That is it. No custom JavaScript, no ARIA gymnastics. If your accordion headers are not buttons, almost everything else you do will be built on broken foundations.

Two: the expanded state is not announced

When a sighted user clicks an accordion header, the triangle rotates and the content slides into view. A screen reader user gets none of those visual cues. They need the header to announce its current state: “expanded” or “collapsed”. This is done with the aria-expanded attribute, which you toggle between "true" and "false" whenever the section opens or closes.

Without aria-expanded, the screen reader says “FAQ: What is your refund policy” and nothing more. The user has no way to know whether pressing the button will reveal new content or collapse content that is already visible. On a page with ten FAQ items, this gap compounds into complete unusability.

Three: the content is not programmatically connected to the header

The header and the content it controls should be linked with aria-controls, which tells assistive technology “this button controls the region with this ID”. Paired with a matching ID on the content container, screen readers can announce the relationship and some screen readers let users jump directly from the header to the content.

This is less critical than aria-expanded but it is still a WCAG 1.3.1 Info and Relationships issue. If your developer is adding ARIA attributes, aria-controls is three extra characters of code and removes a significant point of confusion.

Four: the collapsed content is still focusable

This is the failure that catches almost everybody. When an accordion is collapsed, the content is visually hidden but, in most implementations, the underlying HTML is still present in the DOM. If you hid the content with CSS opacity: 0 or visibility: hidden, any links, buttons, or form fields inside the collapsed panel are still focusable with the Tab key. A keyboard user will land on invisible content and have no idea where their focus went.

The fix is to hide collapsed content in a way that removes it from the tab order: display: none, the hidden attribute, or visibility: hidden applied with display: none as a backup. When the content expands, these are removed. This is a trivial change, but it only happens if you test with a keyboard and notice the invisible focus.

Five: the first expansion loses heading hierarchy

Many FAQ sections use styled <div> elements for the question text rather than real headings like <h3> or <h4>. A screen reader user who navigates the page by heading (a common shortcut, activated with the H key in most screen readers) will skip your entire FAQ section because there are no headings for them to jump to. Your twenty-five most important customer questions become invisible.

Wrap each question in a heading that fits your page hierarchy. If the page title is <h1> and the FAQ section starts at <h2>, each question should be <h3>. The button sits inside the heading, not around it. This pattern, heading-plus-button, is the WAI-ARIA Authoring Practices recommendation for accordions and is supported by every major screen reader.

What to tell your developer or agency

If you run this test and find problems, the fix is well-defined and standard. Send your developer the following, copied verbatim:

Please audit our accordion component against the WAI-ARIA Authoring Practices “Accordion Pattern” at w3.org/WAI/ARIA/apg/patterns/accordion/. Specifically confirm each header is a button inside a heading, aria-expanded toggles on every open and close, aria-controls references the content ID, collapsed content uses display:none so it is not focusable, and keyboard focus is visible on every accordion header with at least a 3:1 contrast ratio against the background.

That paragraph describes a fully compliant accordion and gives the developer a concrete checklist. If you are on a platform like WordPress, Webflow, or Shopify, ask whether the theme or plugin you use meets this standard. Many do not, and some page builders ship accordion widgets with all five of the failures above. Popular WordPress plugins like Accordion FAQ, Easy Accordion, and the Elementor accordion widget have each shipped accessible versions in recent releases; older installations may still have the broken defaults.

A cleaner alternative: the native HTML option

For many FAQ-style accordions, you do not need a custom widget at all. HTML has a built-in <details> and <summary> element that creates an accessible disclosure widget automatically. The browser handles keyboard focus, the expanded state, and the accessible name without any JavaScript. It is the simplest accessible accordion on the web.

<details>
  <summary>What is your refund policy?</summary>
  <p>We offer a 30-day full refund, no questions asked. Email
     [email protected] to start the process.</p>
</details>

There are visual styling limitations (the default marker triangle is browser-specific and harder to restyle than a custom icon), but for simple FAQ sections, <details> and <summary> are dramatically easier and more accessible than rolling a custom widget. If your designer is open to a slightly different visual treatment, ask whether the native element can replace the custom component.

If you need a harder justification than “it is the right thing to do”, the FAQ section is often the highest-traffic element on a site after the homepage and pricing page. Customers who reach your FAQ are close to a decision. A FAQ that screen reader users cannot operate is not just an accessibility failure; it is a directly measurable conversion loss.

The European Accessibility Act treats interactive widgets like accordions as in-scope components for compliance. Noncompliance fines under the EAA vary by member state but reach into the hundreds of thousands of euros for ongoing violations, and the act gives individual consumers the right to file complaints with national enforcement bodies. In the United States, ADA lawsuits that specifically cite inaccessible FAQs and disclosure widgets have been filed against retailers, healthcare providers, and universities.

Fixing an accordion is usually a few hours of developer time. Not fixing it accumulates legal risk and loses customers. The ROI is rarely in dispute once the cost is quantified.

Start here

Open your most trafficked page that contains an accordion or FAQ. Run the three-part keyboard test above. Note which of the five failures apply. Send the developer paragraph. That is the entire remediation workflow for most small and medium sites, and it closes one of the most common accessibility gaps on the web.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.