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

[LukaszJaro]

@webd-uk I would a ticket for that.

@alexstine would this be considered accessibility issue with the way the 2024 theme is using the details block as accordion in FAQ section? Also what uses cases should the details element be used?

[webd-uk]

@LukaszJaro I did with #55483 ... shall I re-open it? Or do you mean raise a ticket about the Twenty Twenty-Four theme use of the Details Block? Because if you do I'd rather not as having played with the Details Block I think it's perfect for an accordion if it can just have the option added to auto-close other Detail Blocks.

[joedolson]

The 2024 theme is using a series of details blocks in a group, but I don't see any way that they're describing it as an accordion. The fact that a group of details are used in sequence does not make it an accordion, and I don't see anything that promotes it as an accordion. If you can point to some specific text in which the FAQ pattern is described as or promoted as an accordion, I'm happy to push back on that, but while I wouldn't use this pattern, because it has woefully insufficient semantics for what it represents, it's not described as an accordion, as far as I can tell.

[joedolson]

@webd-uk Re: "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."

This is not true. The thing that's missing from the details block is heading semantics. An accordion should have headings that indicate each item within the accordion. Inside those headings, there should be buttons that trigger the accordion behavior.

The details block has a summary element, which has the role of button natively. The button role overrides all internal semantics, so no matter what content is inside the summary element, there are no headings present. That is the crucial reason that details is not a substitute for an accordion. As soon as you have enough content that headings are an important element for navigating content, details ceases to be sufficient.

[webd-uk]

@joedolson Ah, OK. So adding a "Close other Details Blocks when opened" setting to the Details block would not make it behave like an accordion because without the heading semantics it cannot be an accordion. As such, do you think that #55483 is valid and should I should re-open it?

[joedolson]

No, I think that #55483 is not a valid request. There shouldn't be any relationship between different details elements on a given page; they should each be treated as an independent element. A change like that would just increase the impression that the details block is equivalent to an accordion.

[webd-uk]

OK ... in that case I'll be looking forward to the forthcoming Accordion Block!

Thank you.

[ocean90]

The details element can now have a name attribute to make it an "exclusive accordion".

[joedolson]

That makes the behavior more like an accordion, but it's still significantly lacking in semantics. It would function in an accordion style, but it would be a very poor accordion. In principle, I'd support adding the attribute on the grounds that WordPress should support all standardized HTML. However, I would still stand on the opinion that it is not an accordion, and we should provide an accordion that does meet accessibility standards.

[westonruter]

@joedolson What are the lacking semantics? Are they lacking in the spec or not implemented in browsers or what?

[amberhinds]

@westonruter take a look at this example of how the accordion block should be coded for accessibility that I shared in September.

[joedolson]

The most specific gap is that an accordion should be a list of heading elements that contains buttons to expand and collapse the content.

The semantics of the details/summary elements, however, are designed so that you can only place a heading inside the summary element; you can't wrap the summary in a heading without breaking the control. This reverses the semantic relationship, and removes the heading semantics.

A heading with a contained button is a heading that has text equivalent to the button text plus a button that has the interactivity.

A summary elements with a contained heading, however, is an interactive element that does not contain any heading semantics.

As an isolated element, a single summary/details combination is a great, easy to implement disclosure widget. But as a group of related elements, it's lacking key navigation and structure elements.

I don't off-hand know whether this should be primarily blamed on browser vendors or on AT vendors. The spec doesn't provide clear guidance about how headings should be handled within a summary element, and as of the last testing publically available, JAWS offered no support for headings within summary on any browser, which eliminates a very large percentage of users.

That test dates to May 2022, though, so it may be due a revisit.

[LukaszJaro]

@c4rl0sbr4v0 how did the experiment go with the interactivity api?

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

[cbravobernal]

I am now working on making the Interactivity API public in WordPress 6.5.

Until then, I won't have enough time 😅 . But after that, it would be a great example for this new feature!

[Nyiriland]

🖐️ Gey gang! I work in an agency and we use accordions quite a bit on our projects. It would be amazing if we could use something from core instead of resorting to a plugin, or building out custom blocks (pretty sure we've done both in the past). Accordions are a very common layout feature on modern sites, for things like feature lists, or FAQs.

The reason Details doesn't fulfill the same purpose for me is two-fold:

• It looks like a bullet point (and I thought it was until someone pointed out it wasn't)
• A user would need CSS knowledge to be able to update it to a more "modern" styled accordion; right now it feels pretty dated as-is (and I'm pretty sure it's just using the default html styles).

[jarekmorawski]

Love the discussion so far! While working on some patterns for WooCommerce, I found the Details block limiting and would love to update it with more features or build a dedicated accordion block. I put together a design proposal that solves most of the issues I ran into and most of what @Nyiriland described earlier).

Firstly, the block would consist of two parts: a trigger and a hidden content area. Both could be anything: from buttons to images to text to tables. Clicking on the trigger block would open the accordion.

For instance, we'd let users add a button that will open the accordion.

Going further, if we update the button to support icons and offer some extra layout flexibility (like "Stretch" as a justification setting that will spread the button's inner blocks even across its width), we'd make it easy to build modern-looking accordions with chevrons, -/+ buttons, text labels, etc.

As for the content area, it could contain any number of blocks. Here's how the block structure would look if we were to build an accordion for a price filter block in a product catalog page template in Woo.

We'd use block states (related to #57719, #38277) to let users customize the appearance of a collapsed and expanded accordion. This would enable designers and builders to use different text labels or icons for each block state, e.g., - when the accordion is open, and + when it's closed.

We'd also let users decide if the accordion is open by default and whether other accordion blocks on the page should collapse automatically when this one's open (this is a pretty common behavior on the web).

I'm a bit torn about this part because it can cause issues when enabled on multiple blocks, but then building an accordion group parent block just for this setting would add unnecessary complexity.

We would let users specify the block's width, justification, and orientation to enable more creative, non-standard layouts. For instance, they'd design an accordion where the trigger is on the left or right, which is a common sight in e-commerce.