Accessibility
We are committed to building a component library that adheres to accessibility best practices. Our components are developed and tested to align with WCAG (Web Content Accessibility Guidelines) and Section 508 standards.
Because many UI Kit components are custom-built, we pay particular attention to:
- Keyboard navigation support
- Screen reader compatibility
- Proper ARIA attributes and roles
Accessibility is an ongoing effort. If you encounter a component that could be improved, we encourage you to share your feedback — we’re always looking to improve.
While we strive to provide accessible components out of the box, developers are responsible for ensuring accessibility within their applications by using components correctly and in context.
Keyboard Navigation
Most UI Kit components support keyboard interaction to ensure usability without relying on a mouse or touch interface.
| Key | Action |
|---|---|
| Buttons | Enter or Space to activate |
| Modals | Esc to close |
| Tabs | Arrow keys to navigate between tabs, Tab to move focus |
| Dropdowns | Enter or Space to select, Arrow keys to navigate options, Esc to close |
| Checkboxes/Radios | Space to toggle selection |
| Groups | Arrow keys to move between items, Tab to move focus |
ARIA and Role Customization
Many components provide props for enhancing or overriding default accessibility behavior:
aria-label,aria-labelledby,aria-describedbyroleoverride (e.g.,role="dialog"for modals)- Dynamic ARIA attributes such as:
aria-expandedaria-checkedaria-selectedaria-hidden
These are passed directly to the relevant HTML elements when supported.
For advanced accessibility behavior, we recommend referencing the WAI-ARIA Authoring Practices Guide.
If you’d like to report an accessibility issue, please open an issue on our GitHub repo.