Accessibility
Accessibility, stated honestly.
The official reference system ships no accessibility statement. This one says exactly what we support, how we test it, and what stays your job.
Read this first.
This is our own honest assessment, not an outside audit, and there is no certified VPAT. Automated tools catch only about a third of issues. Color contrast is designed to meet the thresholds but is not measured in our tests, and changing the theme can change it. Passing automated checks is a starting point, not a guarantee.
Summary
Support at the component level. Page and content criteria are shared with you, see below.
| Area | Status |
|---|---|
| Keyboard use | Supported |
| Visible focus & focus management | Supported |
| Screen readers & ARIA | Supported |
| Arabic & RTL | Supported |
| High-contrast mode | Supported |
| Reduced motion | Supported |
| Color contrast | By design, not measured |
| Target size, page structure | Shared with you |
How it is built
Complex behavior stands on proven accessible foundations, instead of being rebuilt.
- Proven primitivesMenus, dialogs, tabs, sliders, and date pickers use Radix and React Aria for keyboard and ARIA behavior.
- Visible keyboard focusFocus rings show for keyboard users, not on mouse clicks, and are checked in tests.
- High-contrast modeFocus, borders, and states hold up under Windows High Contrast Mode across 63 of 66 stylesheets.
- Reduced motionEvery animation respects the reduced-motion setting.
- RTL by default, enforcedAll layout uses logical properties, and a test fails the build if any left/right CSS slips in.
- Warnings while you buildIn development, controls warn when a required accessible name is missing.
How we test it
We assess conformance ourselves, with automated and manual tests.
- axe-core
- Automated checks on all 64 components, in both English and Arabic.
- Playwright
- 47 end-to-end tests for keyboard, focus, arrow keys, Escape, and RTL.
- RTL gate
- A test fails the build on any left/right CSS.
- Unit tests
- 1,700+ tests across the components.
Known limits
- No outside audit or certified VPAT, this is a self-assessment.
- Color contrast is not measured in our tests. Default colors target the thresholds, but changing the theme or using custom backgrounds can fall short, so check it yourself.
- Minimum target size is met for form controls, but not audited across every component and size.
- Automated checks are a starting point. Test with a real screen reader and real content.
What is on you
The library gives you accessible building blocks. Your app still needs to:
- Give controls, icon-only buttons, and regions a clear label.
- Add alt text for images, icons, and media you pass in.
- Keep a sensible heading order, landmarks, a page title, and page language and direction.
- Re-check contrast if you change the theme.
- Write clear error and helper text, we wire it up, you write the words.
- Test with a screen reader (NVDA, VoiceOver, JAWS) and the keyboard, on your real content.
Report an issue
We treat accessibility bugs as high priority. Include the component, your assistive tech, browser, and OS, what you expected, and what happened.
Open an issueThe full statement
This page is a summary. The complete statement, with the full WCAG 2.2 AA table, is in the repository.
Accessible building blocks, documented honestly.