You might not have noticed it, mainly because it was so quick, but a new HTML functionality is due to arrive in Chromium and WebKit browsers: Exclusive Accordions.^{1 2}

What are exclusive accordions?

Accordions are a series of expand/collapse (aka disclosure) widgets. Usually they start collapsed, and you can open each section one by one. Exclusive accordions close any previously opened section automatically when a new one opens. It means only one section of the accordion can be open at once.

A new proposal now wants to make the existing <details> element into an accordion by grouping them when adding a name attribute to it. Such an element's open state would then automatically be false (hiding the content) when another element’s open state is set to true, if those two <details> have the same name attribute value.

What are the accessibility challenges with exclusive accordions?

There are some accessibility challenges with all types of accordions, but most of them are even worse when only one accordion section can be open at a time. Here are a few examples:

• Higher cognitive load as users are unable to compare information between two sections, the accordion resetting on page reload, added difficulty in scanning and getting a general overview of the information provided.
• More complicated interaction for keyboard users who need to navigate maybe multiple times through multiple expand/collapse button to extend one section, then navigate to the next section and open that, then to the next to open that. Comparing between two section of an exclusive accordion quickly takes dozens of keystrokes.
• Reduced usability for screen reader users who use heading level navigation to get an overview of all content on the page. That’s just not possible anymore as the accordion cannot be opened all at once. Heading levels can also get quite wonky in screen readers when headings are used in the expand/collapse button.
• Low-vision users and people on mobile viewports can easily lose orientation when one section opens and another section closes as the content shifts around. This is especially problematic with content of different lengths. This can also be problematic for people with vestibular disorders. (Gareth Joyce on LinkedIn, Olli Boermans on Mastodon, Christian Schaefer on Mastodon)
• Dragon users can have a hard time opening <details> elements, as the software deprioritizes them compared to buttons and links. (Victoria Clark on LinkedIn)

These are just the three high-level points I have observed from an accessibility standpoint and two other obvious points added after the publication of this post. Most times, users really did not like accordions. The only exception is incredibly long pages that are terribly organized. And even in those instances, the need to open at least two panels happened more often than not.

Support Eric’s independent work

I'm a web accessibility professional who cares deeply about inclusion and an open web for everyone. I work with Axess Lab as an accessibility specialist. Previously, I worked with Knowbility, the World Wide Web Consortium, and Aktion Mensch. In this blog I publish my own thoughts and research about the web industry.

Sign up for a €5/Month Membership Subscribe to the Infrequent Newsletter Follow me on Mastodon

But couldn’t native exclusive accordions address some of these issues?

Technically yes. I am a big fan of making it easier to do the right thing. That should be our goal. Implementing exclusive accordions, be it through JavaScript or as a native browser feature, however, makes it easier to implement a UI principle that makes websites objectively harder to use. It allows developers to deprive users of a choice.

One name attribute and your user cannot interact with the content of the page as they like. It’s disempowering the user.

If we want native accordions in browsers, we also must make sure to have guardrails for users. Browsers are user agents, so they should counteract the negative impact of making exclusive accordions easily possible.

What are the next steps?

It feels like the decision for this native exclusive accordion has already been made. There was no proper accessibility consultation, probably a direct result of HTML features being developed outside of W3C and with no accessibility review. It’s also a cheaply implemented feature; that is easy PR, too. (It’s indeed so simple, I did build it in 2016 with five lines of JavaScript.)

What I hope for now is that browsers quickly address the usability and accessibility issues around accordions, exclusive or not:

• Allow users to deactivate the exclusive accordion behavior globally and for individual websites. We have this for auto play audio and video, we need this here as well.
• The ability to expand all and collapse all accordion sections (essentially all <details> elements) on the page.
• Make sure content inside accordions is shown in reader mode.

It’s unacceptable that we introduce native barriers in HTML and the web platform in 2023. This is unbearable. When we did this last time we got broken date and time pickers, a situation that has not been addressed for more than a decade.

The web must be holistically accessible. Every feature that is introduced must be vetted for accessibility.

2023-11-17: Update to include more bad examples of what accordions do.
2025-08-05: Update to add the dates when the feature shipped and that there are no mitigations for the feature at all.