Adding designers who have previously discussed this component. Plan is to add this as a subtask to the inventory task T277047.

thanks for setting up this task @RHo

1. should we aim to be consistent regarding the direction of the arrow for expanded/collapsed? I think the pattern we use on mobile web, while non-standard, works quite well (especially in cases where there are multiple collapsed sections/elements stacked on top of each other). I would be happy if we aligned around that. I think the more standard pattern is that the arrow points towards the text/label when collapsed, and then points down when expanded (the evidence I have for that is mainly what I've seen on the web, and also what's natively part of the details tag which seems to be the most direct comparison). To compare:

Standard

collapsed	expanded

Approach currently used on mobile web

collapsed	expanded

2. (somewhat related to the question above) dropdown menus are a similar element: you click on a thing to toggle the visibility of something else. as such they also have similar arrow indicators. in as far as these elements are similar (or even maybe just variations on the same element), do we want to consider flipping the arrow in dropdown menu handles/triggers when the menu is open? example here

3. this is more of a note: as mentioned above I believe the closest native HTML element to our "expand and collapse (accordion) component" is the details tag. I mention this mainly because I think it's always important for us to be aware of the standard, native behavior when we're developing our own variations on things. also, on a more technical side, we should think about using this tag once the browser support increases.

Thanks @alexhollender_WMF for breathing life to this task! I've responded below for your specific points but wanted to add DS folks (@bmartinezcalvo @Volker_E @Sarai-WMDE ) for visibility and in case they have plans to integrate/prioritise with Codex work. Also adding @Prtksxna who mentioned another accordion use-case.

In T280785#8030345, @alexhollender_WMF wrote:

thanks for setting up this task @RHo

1. should we aim to be consistent regarding the direction of the arrow for expanded/collapsed? I think the pattern we use on mobile web, while non-standard, works quite well (especially in cases where there are multiple collapsed sections/elements stacked on top of each other). I would be happy if we aligned around that. I think the more standard pattern is that the arrow points towards the text/label when collapsed, and then points down when expanded (the evidence I have for that is mainly what I've seen on the web, and also what's natively part of the details tag which seems to be the most direct comparison). To compare:

Standard

collapsed	expanded

Approach currently used on mobile web

collapsed	expanded

Interesting point about use in web, as I've definitely seen the latter use-case (arrow pointing down when closed, and pointing up when expanded) more so on mobile apps, because the chevron/arrow pointing left or right has connotations with moving forward or backward in navigation, whereas the down/up is more clearly indicative of expanding downwards/contracting upwards. This would be the reason I prefer aligning on the latter. It also relates better to the dropdown element you mention next.

2. (somewhat related to the question above) dropdown menus are a similar element: you click on a thing to toggle the visibility of something else. as such they also have similar arrow indicators. in as far as these elements are similar (or even maybe just variations on the same element), do we want to consider flipping the arrow in dropdown menu handles/triggers when the menu is open? example here

Yes, that seems like a good addition to the quiet dropdown component, perhaps particularly if there's more than one of these dropdowns next to each other, flipping the arrow (and possible some other additional active affordance like adding a background colour) could potentially help identify which is the open menu.

3. this is more of a note: as mentioned above I believe the closest native HTML element to our "expand and collapse (accordion) component" is the details tag. I mention this mainly because I think it's always important for us to be aware of the standard, native behavior when we're developing our own variations on things. also, on a more technical side, we should think about using this tag once the browser support increases.

Agree - though to confirm, if we use <details> moving forward, the decision about what icon to use can still be styled to whatever we choose, right? I had a quick go with the up/down chevrons here: https://codepen.io/reets/pen/eYMOojN

Direction of the arrow

@alexhollender_WMF I agree with using the same approach we use in mobile for the direction of the arrow since, as @RHo comments, this solution indicates the expansion (arrow-down) and collapse (arrow-up) and helps the users to know what is going to happen when they click the arrow.

FYI in the select component we decided to add the arrow without rotation because in some cases the select needs to open from bottom and in this cases the rotation if the arrow was weird. So we decided to not adding rotation to any select component.

Although we decided not to add rotation for selections, I think the accordion component is different because we don't have cases where the accordion opens from below.

Position of the expand/collapse item

I think we should also unify where we want to add the expand/collapse items. In some cases it appears before the text and in other cases after the text.

I've added these 2 topics in the task description as open questions.

Another future use case is the "collapsible list" in WikiLambda:

This will likely use the accordion component, and may become either a project-specific component that wraps Accordion or a reusable Codex component.

The Design System team will start working on an initial standard version of the Accordion component for Abstract Wikipedia (See: T314569). Amin kindly started an exploration while working on their Default component:

We'll try to not only define its anatomy, style, and behavior, but also the specific characteristics that differentiate it from similar components such as tree view (Table of content).

In the Web/DST Offsite the tree view need was resurfaced, in one of the more recent DIP prototypes:

Tree view	Accordion