Accessibility
Standards-based semantics, native behaviors and explicit keyboard contracts—not decorative imitation.
Baseline principles
Prefer real button, input, dialog, details, tables and labels. Use WAI-ARIA for advanced patterns only where native HTML does not expose the required role. The supplied components are designed toward WCAG 2.2 AA patterns, but accessibility compliance depends on application content and requires independent assistive-technology review.
Keyboard interaction
| Component | Expected keyboard behavior |
|---|---|
| Dialogs & drawers | Tab / Shift+Tab stay within the native modal; Escape closes. |
| Dropdown menus | Arrow keys select items; Home/End jump; Escape closes. |
| Tabs | Arrow Left/Right and Home/End select tabs. |
| Comboboxes | Arrow keys navigate results, Enter accepts and Escape dismisses. |
| Accordion | Enter/Space toggle the native summary. |
| Switches | Space toggles checked state; Tab moves focus. |
Labels and validation
Each input needs a visible label or equivalent accessible name. Connect dynamic validation messages with aria-describedby; preserve native constraint validation. Dynamic status events must have appropriate status semantics.
Verification expectations
Run screen-reader checks using VoiceOver, NVDA or equivalent. Test keyboard-only navigation, high-contrast modes, zoom, mobile layouts, language changes and reduced motion on your final product. Passing automated checks alone does not certify WCAG conformance.