A List is a component that displays a set of vertically stacked components.
If you are displaying more than one dimension of the data, the List probably isn't the proper component to use, instead, consider using Table or DataGrid.
The List supports plain list items, interactive list items with one action or multiple actions. It also has support for single and multi selection built in. This can be utilized in either uncontrolled or controlled way.
All of the List scenarios are also accessible, as the whole component was built with accessibility in mind. It is easily navigable with a keyboard and supports different screen reader applications.
Provide some representative example code that uses the proposed API for the component
Describe visual or functional variants of this control, if applicable. For example, a slider could have a 2D variant.
List the Props and Slots proposed for the component. Ideally this would just be a link to the component's .types.ts
file
- Public
- Internal
- DOM - how the component will be rendered as HTML elements
Describe what will need to be done to upgrade from the existing implementations:
- Migration from v8
- Migration from v0
Explain how the component will behave in use, including:
- Component States
- Interaction
- Keyboard
- Cursor
- Touch
- Screen readers
Base accessibility information is included in the design document. After the spec is filled and review, outcomes from it need to be communicated to design and incorporated in the design document.
- Decide whether to use native element or folow ARIA and provide reasons
- Identify the ARIA pattern and, if the component is listed there, follow its specification as possible.
- Identify accessibility variants, the
role
(ARIA roles) of the component, itsslots
andaria-*
props. - Describe the keyboard navigation: Tab Oder and Arrow Key Navigation. Describe any other keyboard shortcuts used
- Specify texts for state change announcements - ARIA live regions (number of available items in dropdown, error messages, confirmations, ...)
- Identify UI parts that appear on hover or focus and specify keyboard and screen reader interaction with them
- List cases when focus needs to be trapped in sections of the UI (for dialogs and popups or for hierarchical navigation)
- List cases when focus needs to be moved programatically (if parts of the UI are appearing/disappearing or other cases)