Description and use cases of this component
Include background research done for this component
- Link to Open UI research
- Link to comparison of v7 and v0
- Link to GitHub epic issue for the converged component
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)