Accessibility
Interfaces that more people can use in more ways.
The idea is still yours.
Start with clear names
Every control needs an accessible name. Associate Label and Input using htmlFor/id and add aria-label to icon-only buttons. Do not rely on placeholders to name fields.
1<Label htmlFor="email">Work email</Label>
2<Input id="email" type="email" aria-describedby="email-help" />
3<p id="email-help">We will use it to invite you to the team.</p>Navigate with the keyboard
Primitives provide keyboard behavior, but the final composition still needs testing. Custom styles must not hide focus or block controls.
- Tab and Shift+Tab should traverse controls in a logical order.
- Visible focus must retain sufficient contrast.
- Escape should close panels and return focus to their trigger.
- Tabs, menus and option groups should respond to the appropriate arrow keys.
Structure before appearance
Respect heading hierarchy, use links for navigation and buttons for actions. Include DialogTitle and DialogDescription in panels and captions when a table needs context.
Color must not be the only signal for error, success or selection. Add text and relationships such as aria-describedby; announce relevant changes in status regions.
Adaptation and motion
Test 200% zoom, mobile sizes and reduced-motion preferences. An attractive example does not replace reviewing the entire flow with a keyboard and screen reader.
Test theme variants separately: customizing tokens changes contrast and can affect text, borders and interactive states.
Continue with Button or explore the web component catalog.