New block: Accordion block

[mapk]

There's been a few requests for an Accordion block in core. Let's start exploring how this looks.

Requirements

• Pure CSS.
• Add accordion headers with arrow icons.
• Allow any block to be added within an accordion section.

Is the accordion section simply a Group block that is able to be collapsed? Basically it would work similarly to the Settings sidebar sections.

Kudos to @melchoyce for this idea. Some examples she shared recently:

https://codepen.io/raubaca/pen/PZzpVe https://codepen.io/vinsongrant/pen/qbGKed https://codepen.io/abergin/pen/ihlDf

[aristath]

I really don't see the big advantage of saving 1-2KB of JS.

With WP powering almost 40% of the web, it makes a huge difference for sustainability. 1-2kb on each page-load for 40% of all page-visits on a daily basis adds up to a lot of data... If possible we should strive to save as much as humanly possible.

We can also not add this block in core

+1

[mariohamann]

Added this fourth option in the list above and I think it is definetely an option to go.

@aristath I would expect JS being loaded only on pages with the block inside – not on every page. Personally I think that an accordion is one of the most basic elements in today's web and it can't be replaced with any pattern, block combination etc. It should be worth considering to add such an element to the core to prevent users from adding a complete block suite or maybe unaccessible/non-performant accordions only for this basic function.

Therefore: On the one hand I totally get your point, on the other hand I think it is worth the discussion.

[pandjarov]

Accordions are not some extravagant feature but a basic functionality that's part of most pages. If we ever want Gutenberg to be at least on par with the popular page builders out there having one as part of it is a must.

[alexstine]

I would also rather see our core implementation of clean JavaScript for accordion than some of the possible plugins that could spin up as a result of this block not being added to core.

[ZebulanStanphill]

@mtias

We can also not add this block in core

Why?

Also, would an accordion block actually require 1-2kB of JS? That seems like a rather large estimate to me.

[mariohamann]

Also, would an accordion block actually require 1-2kB of JS? That seems like a rather large estimate to me.

If we use a minified version of the (accessible) W3 accordion in fact it would be about 1.7kb. But maybe there are better/more performant ones.

[mtias]

@ZebulanStanphill it's also an option to consider like the others.

JS on the front is less about the weight but the ongoing support, maintenance, and ramifications it can carry. Core has rarely added front-end JS outside of themes. (Navigation menus in themes was one of the most prominent.) Particularly when there is a native and semantic tag to achieve some of the result with <details> and <summary> we should consider the implementation thoroughly.

[mtias]

Also it might have sounded contrarian, but I do support developing a great accordion block. We could include it in the block directory as a core-supported block if we arrive at a solid implementation instead of bundled, which can also help in the current setup to ensure scripts / styles are bundled separately.

[ZebulanStanphill]

@mtias Oh, I misunderstood your previous post.

Unfortunately, because <summary> eats semantics (and there appears to be no way around this, even with JS), I don't think we can use the <details> element at all in an Accordion block, if we want to support a11y-navigation-friendly headings.

And, yeah, an officially supported plugin could be a good solution to avoid having the bundle any more JS in core itself.

[doughamlin]

@mtias @ZebulanStanphill Are there any other "core-supported blocks" or would this be the first?

[mariohamann]

Particularly when there is a native and semantic tag to achieve some of the result with <details> and <summary> we should consider the implementation thoroughly.

Just in case someone has the same – maybe foolish – idea to add role and level attributes to the summary tag: lthoug it works (still expandable and being read as e. g. a <h2>), it's not HTML compliant and breaks accessibility even more, as far as I understand after some researching and testing.

<details open>
    <summary role="heading" aria-level="2">Item One</summary>
    <div>
         <p>Ut deserunt irure proident fugiat id eu id cupidatat dolore ex.</p>
    </div>
</details>

Personally I think if there will be anything in core or core-related/supported which describes itself as being an "Accordion" block, it should provide at least the following two adjustable features (see W3.org):

1. "Allow for multiple accordion sections to be expanded at the same time."
2. "Allow for each toggle to both open and close its section."

For the first point I don't see any possibility for <details>/<summary> without JS. If this won't be implemented, in my opinion the block should be named "Toggle" instead of "Accordion" because otherwise it might break WP users expectations.

[aristath]

Just in case someone has the same – maybe foolish – idea to add role and level attributes to the summary tag: lthoug it works (still expandable and being read as e. g. a <h2>), it's not HTML compliant and breaks accessibility even more, as far as I understand after some researching and testing.

Why not just use a proper <h2> in the summary? AFAIK it's perfectly valid. (apologies if this has already been covered above, but this is a looooong thread and things get lost)

[mariohamann]

As @enriquesanchez pointed out in this comment, it seems to be valid (tested it with W3 validator) but not working in terms of a11y: https://daverupert.com/2019/12/why-details-is-not-an-accordion/

W3 recommends <h3><button>Button text</button></h3>

[mtias]

@doughamlin we had discussed it before for things like a Slider block (with inner block container), but this would be the first indeed if we went that direction. As the block directory continues to mature, it could be worthwhile migrating some blocks from core bundling to the directory. We could keep the UX mostly transparent, even showing the blocks in the inserter but they only get installed when you insert and use them.

[yanceyk]

Hello. I found this thread about a month ago and forged ahead to find a means to make my own accordion for a client after seeing it in development.

I was able to do so successfully by using this tutorial on Medium.

I adapted it to pure CSS - no hidden inputs, it relies on the button element. It's accessible to screen readers and works great in the block editor. Here's a pen to the HTML/CSS version. https://codepen.io/kyancey/full/KKMQazw

Hope it helps.

[mariohamann]

Thank you very much @yanceyk for your input! It's very interesting to see those different approaches!

• In Safari your Codepen has some problems – the accordions stayed only open while clicking. After releasing the mouse they closed.
• Still I'm not sure if this accessible, as it uses "focus" in addition to "active" and that would open accordions while tabbing through the content.
• Furthermore I don't think that it's possible to wrap the buttons with a heading tag (e. g. <h3><button>Lorem Ipsum</button>/h3>) as the :active pseudo class couldn't be used anymore.

This leads me to the point: There are so many different approaches to create accordions and often they feel robust or accessible – but often they maybe aren't. → A Core supported, accessible accordion is urgently needed.

[yanceyk]

Thanks for your feedback @mariohamann, I hadn't tested in Safari. But it was the intent to have them remain open while clicked. Yeah, it isn't possible to wrap a button with <h3></h3>. Just thought I'd give you guys some other approaches to consider. I agree with you 100%. I hope you guys are able to come up with something satisfying.

[LukaszJaro]

Is there also consideration for the accordion block to allow transforms? i.e, groups/columns transform to accordion?

Now I realized I should of wrote "Accordion" as a essential plugin in the WordPress 2020 survey..

[paaljoachim]

How the heck do we move forward with this issue? As it would be very helpful to have an Accordion block in core Gutenberg. What is a method that we can actually agree on? That works with no js and is also accessible.

[LukaszJaro]

I was hoping gutenberg block editor to achieve minimal, basic, and useful features compared to other modern page builders.

The argument that it would add JS bloat doesn't hold well. User will just find another plugin or block which may contain 20 other unneeded blocks or bloated JS.

Even an officially supported block will not be found by many and will resort to other bloated plugins. But this seems to be the only middle-ground since no core blocks should have any JS to maintain, from my understanding that is. Also will reduce maintenance on the core team. Maybe through the block directory?

I think some facts have to be solidified here as well so we can move on:

• We can't use details/summary, or checkbox, none of that is accessible enough and eats semantics as mentioned previously.
• We can't use pure CSS solution, not accessible, needs the aria expanded value for example.
• Valid example with JS from W3 https://www.w3.org/TR/wai-aria-practices/examples/accordion/accordion.html

[mtias]

To clarify, it's alright to have blocks that require JS to run on the front-end in core, but it demands a more in depth consideration and more certainty that it's the right path (including longer term web semantics) since maintenance, back-compatibility, and plugin/theme compatibility costs are higher.

Even an officially supported block will not be found by many and will resort to other bloated plugins.

An officially supported block through the block directory would show up in the inserter when you search for it as the canonical result, I'd imagine somewhat similar to how the core importers work as separate plugins. There are other candidates in the current set of blocks that could be moved there once the directory is ready for it, for example.

[LukaszJaro]

Thanks @mtias for clarifying!

As for the web semantics W3(the people who set web standards) have already figured this out with examples https://www.w3.org/TR/wai-aria-practices-1.1/#accordion

An officially supported block is starting to sound better...

[paaljoachim]

@mkaz brought up this PR during the Core Editor Meeting: https://github.com/WordPress/gutenberg/pull/29537 From how I understood it the above PR will make the Accordion block with JS possible in Gutenberg.

Link to the discussion in Slack (You will need to have a WordPress Slack account to be able to view the contents on Slack.) https://wordpress.slack.com/archives/C02QB2JS7/p1615386204074800

[paaljoachim]

A nice resource to take a closer look at: https://semantic-ui.com/modules/accordion.html

[kraftner]

@paaljoachim Looked at it for 2 seconds and already did see:

• Breaks down without JS (no progressive enhancement)
• Can't be navigated with the keyboard
• Generally it's all <div>s and not even the hint of care for accessibility

[ciampo]

Should we consider adding an Accordion component to the @wordpress/components package, which then can be reused across the repository (i.e in the Accordion block, the Navigation block #29747...)?

[mtias]

@ciampo no, our UI components are React based intended for admin UI, an accordion block would be something implemented entirely differently and optimized for the front-end.

[ciampo]

an accordion block would be something implemented entirely differently and optimized for the front-end

Makes sense, thank you for clarifying.

[LukaszJaro]

I'm seeing alot of WordPress plugins bundle accordion blocks, and 90% of them are using the "Details" element unknowingly/knowingly creating accessibility issues so would definitely be nice if WP released a good example of an accessible accordion.

How important is progressive enhancement with accordions? Bootstrap CSS library, known for accessibility, has a collapse(accordion) component. In their implementation, if you disable JS in browser, the accordion functionality breaks, meaning you can't expand or collapse.

While WCAG 1.0 from 1999 required that pages be functional and accessible with scripting disabled, WCAG 2 and all other modern guidelines allow you to require JavaScript, but the scripted content or interactions must be compliant with the guidelines

Even the w3.org accessible accordion design does not work when JS is disabled: https://www.w3.org/TR/wai-aria-practices-1.1/examples/accordion/accordion.html

And then there's WordPress's accordion panels in the admin which also break with JS disabled.

Is this considered a blocker for WordPress's implementation of a accordion block? Meaning there should be some sort of fallback if JS is disabled.

Here's a good resource on this: https://meiert.com/en/blog/must-work-without-javascript/

If it is necessary for progressive enhancement, then one the strongest and most accessible accordions with progressive enhancement is detailed here https://inclusive-components.design/collapsible-sections/ and here's a codepen https://codepen.io/heydon/pen/ZXdbxj/

It basically uses web components to solve the issue.

[westonruter]

There is a standard HTML feature that can be used to implement accordions today: the details element (Can I use). Not only does it work with JavaScript disabled, but with https://github.com/whatwg/html/pull/6466 browsers will automatically expand details elements when doing find-in-page if there is text that matches inside, or if there the page is linking to an anchor inside the details. So details is both accessible to when JS is turned off and it's accessible for users to easily find text inside of them. The only progressive enhancement for a details-powered accordion would be whether the author wants only one accordion to be open at a time. That could be handled with a minimal amount of scripting.

[ZebulanStanphill]

@westonruter But there's a catch: you can't put a heading in the <summary>.

https://daverupert.com/2019/12/why-details-is-not-an-accordion/

EDIT: It's worth noting that there is an effort to design and propose a real accordion element for HTML, but don't expect it to be in browsers any time soon. https://daverupert.com/2021/10/native-html-tabs/

[alexstine]

Quick question. Is there a reason we're working this hard to avoid a few lines of JavaScript on the front-end? I am not at all advocating to make JS everywhere on the front-end but there are plenty of stylesheets at play. I am not seeing where the JavaScript is creating such a big implementation issue.

<button type="button" aria-expanded="false" id="accordion1" class="button"><span class="icon-class"></span><span class="screen-reader-text">Some Label</span></button>
<div style="display:none;" id="accordion1-content">
<p>Some content</p>
</div>

Could include a custom JS file that gets minified.

const accordion = document.getElementById( 'accordion1' );
accordion.addEventListener( 'click', function() {
if ( accordion.classList.contains( 'open' ) ) {
// Remove class and toggle aria-expanded to false.
} else {
// Add class and toggle aria-expanded to true.
}
});

This is just a basic example, but I can't imagine this code minified would even make a difference. Besides, it's about good accessibility and functionality. Win win to me.

Thanks.

[mtias]

Part of the problem has been that there's a lot being put into the "accordion" bucket and a single block trying to do it all will probably be ill-advised at the moment because people have different expectations on what it should be (a semantic element, a UI component, auto-collapse for siblings, etc).

@alexstine that's a good question! Your example is fairly innocuous on the surface, but it starts to be a bit harder to handle if you have 100 accordions on a page (if using an id as shown above). There are also issues with attaching the event listeners in cases like async loading posts (sites with infinite scroll, etc). This doesn't mean it's a huge blocker but for a block provided by core it would need to be handled somehow and maintained in a way that doesn't cause issues in the long term. People would want to extend it for auto-collapsing creating further couplings with markup and even handlers. The problem is not so much that it's hard to achieve, but that it's not clear — given this whole thread — what exactly everyone has in mind as being a sufficient experience.

In that sense, I still think an accordion, even if maintained by core, is probably best started as a single block in the block directory while these things get cleared. Bundling in core, if deemed necessary, would be easy to do at any point; unbundling wouldn't.

As an aside, I also think details with summary is something we should probably have in addition to any accordion as a standalone block without heading support under a different name. It seems valuable and useful on its own as a semantic set of elements, it's native html already, works with searches, etc, even if not used as a full fledged sectioning accordion.

[ZebulanStanphill]

There was already a PR for a <details> block (#23940), but it was closed due to the "overall excitement around the accordion block", heh. 🥴

There was also an issue with handling the spacebar key in the <summary> in the editor, but I think that's been resolved now.

If desired, I could open a new PR based on the prior one.

[mtias]

We might need a better name, but I think we can reopen :)

[jordesign]

@ZebulanStanphill Just coming across this - and wondering what would be involved in reponening that PR for discussion?

Would be great to get it going again.

[ZebulanStanphill]

@jordesign Recently, the special handling for pressing the space key in the <summary> element was removed.

In order to have a <details> block, you'd have to use different markup in the editor versus the front-end. The trouble is that you want the fake <details> to look like the real one... but how do you pull that off when a <details> looks different depending on your browser? And then there's the challenge of ensuring that any styles applied to a <details> on the front-end are also applied to the fake one.

For these reasons, I got stumped while trying to make a new PR to add a <details> block.

A proper accordion block (which due to previously stated reasons, wouldn't use a <details>), probably wouldn't have most of these markup/styling mismatch issues. However, it has its own challenges, namely how to handle the custom JS that would be loaded on the front-end. Ironically, though, it's starting to sound a lot easier than a <details> block.

[Jabe64]

@carolinan Any update on accordion block now that details/summary block seems to be done?

I don't know if this could help but there is a nice video about doing accordion with great accessibility with less JS and more CSS: https://www.youtube.com/watch?v=WJERnXiFFug

The final code is here : https://github.com/kevin-powell/accordion

There is also another shorter video about using CSS grid-template-rows property instead of JS for transitions: https://www.youtube.com/watch?v=B_n4YONte5A

Final code : https://codepen.io/kevinpowell/pen/NWOgVga

[westonruter]

Just wanted to note that Chromium just published an intent to prototype the accordion pattern using <details> elements. This could end up being a way that the accordion becomes part of the web platform, and as such, might be worth waiting to see what comes of it in regards to creating an Accordion block.

[Jabe64]

Thanks for the info @westonruter I have just realized that Details Block isn't finished. There are more refinements coming in #49808

[carolinan]

@Jabe64 thanks for asking. The details block proposal was not accepted, and where either block goes from here will be up to others.

[Jabe64]

@Jabe64 thanks for asking. The details block proposal was not accepted, and where either block goes from here will be up to others.

You're welcome! Thanks for the update and fast answer. Maybe what @westonruter said would be of interest of the details block conversation.

[mrwweb]

A la @westonruter's point about watching changes to Chrome's details/summary support, I also wonder about how the progress of the Interactivity API could impact this block. In many ways, an accordion is the best example of a similar, interactive block that is a perfect use case for the API. If it looks like the API is going to successfully make it into core, it could be really cool to pair it with the release of a core block that puts it to use.

Further, even with the potential changes to details/summary, I'm not sold that it's the right tool for this block given that you can't use headings to identify accordion sections with details/summary. Scott O'Hara has an excellent overview of details/summary and concludes with the following:

It really just all comes down to what sort of experience you want to provide to people, and how OK you might be knowing that the native elements are going to be exposed differently, have different gaps but also different features to them. Or, you can roll your own disclosure widgets and provide a consistent experience that you are fully in charge of… but it may not be as feature rich as what the browsers could provide, and your disclosure widgets need to degrade gracefully if viewed in a browser’s reading mode.

The decision of what you do is up to you.

Using those elements for the core block is probably defensible, but the rationale for doing that instead of a custom implementation with minimal JavaScript (as @alexstine mentioned earlier in this thread) should be clearly documented and justified.

[cbravobernal]

I will be happy to try an experiment of an Accordion approach with the Interactivity API. I will keep you posted in this issue.

[jordesign]

@mapk @paaljoachim Just checking in here to see if the new Details block - covers this issue sufficiently

[paaljoachim]

Hey @jordesign I have no idea....

[jordesign]

I'm inclined to say the the new Details Block handles this well enough to close this issue - any enhancements/suggestions to extend the functionality could be added as new Enhancement reauests

[joedolson]

The details block is really not a substitute for an accordion, and should not be used in that manner. It's expected to show and hide only one panel, and doesn't operate as a group. I think we should still add an accordion block.

[amberhinds]

I was just going to write the same thing RE the details block. Here's a good example of how the accordion block should be coded for accessibility.

[webd-uk]

The details block is really not a substitute for an accordion, and should not be used in that manner. It's expected to show and hide only one panel, and doesn't operate as a group. I think we should still add an accordion block.

I'd like to highlight that the new Twenty Twenty-Four theme uses multiple Details Blocks to provide the functionality of an accordion on the "FAQ" panel of the home page.

The only thing missing from the Details Blocks is a setting "Close other Details Blocks when opened" which would negate the requirement for an Accordion Block.

So ... if the Details Block shouldn't be used to create an accordion then really the new theme shouldn't be promoting it as such surely?