Make Accordion component more flexible

[div-Leo]

What

The accordion component implementation forces you to pass just a few strings to fill some placeholders (title, description, button label...) inside the header. The intention is to make the component more flexible to accept more complex elements.

How

Using component composition we could provide a more flexible API and pass entire components inside the header and the content.

Example

<Accordion>
   <Accordion.Header>{... }</Accordion. Header>
   <Accordion. Content>{...}</Accordion. Content>
</Accordion>

Here an article with some examples

Why

There are cases when we need more complex headers, like in this example:

[JanHamara]

I will refer to your screenshot of a more complex use-case to explain my opinion.

To be honest, I feel like this implementation is way too complex to be called accordion anymore, and should require a new component, something like ExpansionPanel or DropdownPanel..

Within most of design systems and foundations to design traditional accessible 'building blocks style' design components (and also by its name, inspired by the real-world accordion), there is a common pattern as to what accordion is.

---

The pattern described by W3C ARIA Authoring Practices Guide: An accordion is a vertically stacked set of interactive headings that each contain a title, content snippet, or thumbnail representing a section of content. The headings function as controls that enable users to reveal or hide their associated sections of content.

Where Accordion Header is a label for or thumbnail representing a section of content that also serves as a control for showing, and in some implementations, hiding the section of content.

And Accordion Panel is the section of content associated with an accordion header.

---

MUI describes accordion as a lightweight container that allows the user to show and hide sections of related content on a page.

---

Reach UI (an accessible foundation for React-based design systems) An accordion is a vertically stacked group of collapsible sections. An accordion is composed of grouped buttons and panels. When a user selects an accordion button, its corresponding panel should switch between 'open' and 'collapsed' states.

---

We see the repetition of pattern, where we have a set of collapsible sections, which are each triggered by the accordion ''header'' which is the label -> for the -> content that is initially collapsed. Also there is almost always the common default pattern of ''only one item may be expanded and it gets collapsed again by expanding another.''

Finally, the most important pattern that is embraced by accordion component is the progressive disclosure — the goal of emphasizing crucial details of a section (in the heading / label) and revealing more relevant content with a click or keyboard stroke, if required by user. This keeps the design focused on critical information at first, while the rest of the information is quickly and easily accessible on user interaction if needed.

Having a table in the header (or whatever else more than a heading and maybe short subheading in special cases), in my opinion, goes directly against that accordion pattern and does not feel like an accordion anymore :)

In addition, if we went to expand on that common pattern, it may introduce all sort of accessibility issues, especially considering the fact that there is an action button in that table.

So I would suggest to rather introduce a new component like the aforementioned ExpansionPanel that would allow for such implementations, not having to worry about how many and what kind of components we want to have in the non-collapsible part :)

[nlopin]

Jan, that's a great investigation!

I agree that the screenshot looks complex to be a pattern. However, it highlights that our current implementation of the Accordion is strict and allows only a specific format in the collapsed state.

As you noted, an accordion is usually a set of collapsible panels, and often only one can be expanded at a time. This logic is missing at the moment. But as you pointed out, it is how most of the accordions are done in different design systems. For more examples, IBM Carbon's Accordion, Gov.uk.

So, in my mind, this should not be called an accordion but rather a collapsible panel. It reflects a lot an HTML native <details> tag. In spec, it is defined as:

The details element represents a disclosure widget from which the user can obtain additional information or controls.

This definition reflects what we see now way better. We can see examples of such components in other design systems, such as in Shopify.

My proposal:

• deprecate the Accordion and rename it to something better reflecting the name. For example, CollapsiblePanel or Collapsible?
• Make this new component flexible enough to set any type of content in the header and the body
• Make a component that mimics the current accordion implementation (e.g. Details ?)
• Create an issue for the true Accordion implementation and discuss it separately?

I think that we should use a bottom-up approach, moving from basic HTML-alike components to something more complex

[nlopin]

@martimalek uses the component to show Reminders. There is usually more than one reminder. The application manages the open and shown state.