## Background
- **Description:** Accordions present one or more content areas that can be expanded and collapsed.
- **History:** There's a main task with an inventory of potential accordion instances that should be taken into consideration when tackling the definition of this pattern: {https://phabricator.wikimedia.org/T280785}.
- **Known use case(s):** The first potential consumer of the Accordion component would be Abstract Wikipedia, in the context of their "Default component".
There are several variations of expand/collapse elements in the Wikimedia interfaces, from article sections in Minerva, to tree-like menus in Vector's table of content. We need to decide, as part of the definition of the Accordion, whether these other collapse/expand elements will need any adjustments.
- **Considerations:** This pattern should be approved by the design team before being introduced in our design system.
### User stories
- As a designer and developer, I want to be able to reuse an accordion component to group relevant content and present a clean structure to users.
### Previous implementations
These artifacts are listed for historical context. The figma spec, linked below, is the source of truth for the new component.
- **Design style guide:** Pending. See T280785
- **OOUI:** -
- **Vue:** -
---
## Codex implementation
### Component task owners
- Designer: //add the main deigner's name//
- Developer: //add the main developer's name//
### Design spec
WIP. A component spec sheet has not been created yet.
| Component spec sheet |
---
## Stage 1: Minimum viable product (MVP)
MVP includes basic layout, default states, and most important functionality.
### Acceptance criteria
- [] Determine what MVP includes for this component and document this in a subtask. Assign task to designer.
- [] Design MVP. Once complete, assign task to developer.
- [] Implement MVP
---
## Stage 2: Additional states, features, and variants
### Acceptance criteria
- [] Document design and implementation of additional states and features in individual subtasks
- [] Complete each additional state/feature subtask
---
## Stage 3: Refinement
### Acceptance criteria
- [] Finalize docs: open and complete a subtask for any additional demos that need to be added or documentation that needs work
- [] Meet accessibility standards: open and complete a subtask for any necessary accessibility improvements
- [] Meet internationalization standards: open and complete a subtask to fix any i18n bugs
- [] Complete testing: open and complete a subtask for any additional unit or functional tests that are needed