Add accordion and toggle keywords to details block

[richtabor]

What?

Following up on the discussion around details block discovery #45055 (comment) and this Twitter/X thread, adding the accordion and toggle keywords.

Why?

As-is, you have to understand what a <details> element is, to find it. Adding common terms of accordion and toggle do not indicate this is a proper accordion, but do help with discoverability.

Testing Instructions

1. Open list view.
2. Search for accordion and toggle.
3. See the details block as a search result.

[Mamaduka]

Let's give this a try. I hope people will use the block responsibly :)

P.S. Rebasing will resolve failing CI check issue.

[joedolson]

How much precedent is there in blocks for using keywords that are expressly not what this block does? Details/summary is explicitly not an accordion. I'm happy with toggle, as that is a generally descriptive term, but accordion refers to one very specific mode of interaction, which this is not.

I think that using the word 'accordion' to find this block will lead to frustration and misuse. Frustration by people who find this block and are dissatisfied because it doesn't offer accordion-like functionality and misuse by people who decide to use it as an accordion anyway.

Additionally, I think keeping disclosure would be helpful, as it also generally describes what this block does.

[richtabor]

I think that using the word 'accordion' to find this block will lead to frustration and misuse. Frustration by people who find this block and are dissatisfied because it doesn't offer accordion-like functionality and misuse by people who decide to use it as an accordion anyway.

You do still need to select the "Details" block; it's not 1:1 — just makes the block more discoverable.

How much precedent is there in blocks for using keywords that are expressly not what this block does?

But close conceptually, like:

Audio block with "podcast" and "recording".
Group with "wrapper" and "section".
Table of contents with "document outline" and "summary".
Heading with "title" and "subtitle".
Verse with "poetry" and "poem".

[joedolson]

All of those examples are conceptual, rather than referring to a specific user experience.

Audio block with "podcast" and "recording". - "Podcast" and "recording" are types of audio.

Group with "wrapper" and "section". - "Wrapper" and "section" are ways of describing groups.

Table of contents with "document outline" and "summary". - A table of contents can contain a document outline, which can be described as a summary of the content on that page.

Heading with "title" and "subtitle". - A title or subtitle are common terms for larger, emphasized text within a body of content.

Verse with "poetry" and "poem". - Poetry and poem are essentially synonyms with verse.

But "accordion" is a specific user interface, and is not the details/summary interaction. To me, this is more like using the term 'video' as a keyword for the 'audio' block. It is a thing that is related, but is expressly not the thing searched.

[richtabor]

But "accordion" is a specific user interface, and is not the details/summary interaction. To me, this is more like using the term 'video' as a keyword for the 'audio' block. It is a thing that is related, but is expressly not the thing searched.

I disagree. It's like searching for image and seeing a suggestion site logo, featured image, cover, etc. They're related, but not expressly the thing searched. Just because it is presented in the results does not make it an exact representation of the search term.

If you want to show and hide content, and you're somewhat familiar with standard web terminology, you'll search for "accordion" and you won't find anything.

[joedolson]

But in your example, if you search for image and find site logo, you've found a specific case usage of an image. That seems reasonable. If you search for accordion and find details/summary, that is not equivalent - it's not a usage of an accordion, it's just a different interface entirely.

I'm totally fine with a wide variety of terms that would be specific cases where details/summary would be used, e.g. spoiler, disclosure, expand, collapse, etc., but I don't think we should use just generally similar interfaces.

[richtabor]

I'm totally fine with a wide variety of terms that would be specific cases where details/summary would be used, e.g. spoiler, disclosure, expand, collapse, etc., but I don't think we should use just generally similar interfaces.

But 'accordion' is what people will search for, and come up empty with.

It's not about technicalities, it's about discoverability.

[joedolson]

I agree. And this block should not be discovered for the term 'accordion', and I think that's where we're butting heads. If think that if people search for something very specific, like an accordion, then they should find an accordion. We do not have an accordion block, so they should not find a block when they search that term.

They should come up empty for an accordion, because we don't have one in core.

[paaljoachim]

An accordion block is something I have heard of through various web sites etc. It is a familier term because it has shown up a few places here and there. Details block is something I would have no idea what is if I had not known about the
details block in WordPress. The details block based on what I see and how it works through the UI seems identical to an accordion block to me.

An accordion as I see it is just clicking an arrow to open up to see more content.

For the general user one would not know the difference between details or accordion block.
It would be helpful if accordion could show up as a keyword associated with the details block. It seems like the same thing. Going into technical side of things then yeah there are probably differences but most would have no idea about them.

So if we go into the technical then the details block I assume is not an accordion. Even though to me using the UI it is.