Accordion

Accordion Specification

Contents

1. Overview
2. User Stories
3. Functionality
4. Test Scenarios
5. Accessibility
6. Assumptions and Limitations
7. References

Owned by

Astrea

Developer Name

Designer Name

Requires approval from

• Peer Developer Name | Date:
• Design Manager: Svilen Dimchevski | Date:

Signed off by

• Product Owner: Radoslav Mirchev | Date:
• Platform Architect Name | Date:

Revision History

Version	Users	Date	Notes
1	Names of Developers and Designers	Date 25-Nay-2022

1. Overview

Objectives

Accordion web component combining a collection of IgcExpansionPanelComponents in a vertical layout. It allows the end-user to see an overview of data and dig into the details that come with it in an interactive fashion. The Accordion does not overload the user with information, making it compact in size and using progressive disclosure to unveil more of it. Its items are templatable out of the box since each of them is an IgcExpansionPanelComponent that comes with built-in templating. The Accordion has two interactive modes:

• only one igx-expansion-panel can be expanded at a time (selecting a collapsed panel would collapse the currently expanded one, while the selected one is expanding at the same time) prototype
• multiple IgcExpansionPanelComponents can be expanded together, which means that only explicit user interaction or use of the API affects the state of the Accordion prototype

End-to-end user experience prototype

Acceptance criteria

Must-have before we can consider the feature a sprint candidate

...

2. User Stories

Elaborate more on the multi-facetted use cases

Developer stories:

• Story 1: As a developer, I want to…, so that I can… prototype
• Story 2: As a developer, I want to…, so that I can… prototype
• Story 3: As a developer, I want to…, so that I can… prototype

End-user stories:

• Story 1: As an end-user, I want to…, so that I can… prototype
• Story 2: As an end-user, I want to…, so that I can… prototype
• Story 3: As an end-user, I want to…, so that I can… prototype

3. Functionality

Describe behavior, design, look and feel of the implemented feature. Always include visual mock-up

3.1. End-User Experience

** Integration scenarios or functionality with other features/components prototype ** End-to-end user experienceprototype ** Prepared design files for styling e.g. interplay with features and light/dark variants design hand-off

3.2. Developer Experience

3.3. Globalization/Localization

Describe any special localization requirements such as the number of localizable strings, regional formats

3.4. Keyboard Navigation

Keys	Description

3.5. API

Options

Name	Description	Type	Default value	Valid values

Methods

Name	Description	Return type	Parameters

Events

Name	Description	Cancelable	Parameters

4. Test Scenarios

Automation

• Scenario 1:
• scenario 2:

5. Accessibility

ARIA Support

RTL Support

6. Assumptions and Limitations

Assumptions	Limitation Notes

7. References

Specify all referenced external sources