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.

AreaStatus
Keyboard useSupported
Visible focus & focus managementSupported
Screen readers & ARIASupported
Arabic & RTLSupported
High-contrast modeSupported
Reduced motionSupported
Color contrastBy design, not measured
Target size, page structureShared 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 issue

The full statement

This page is a summary. The complete statement, with the full WCAG 2.2 AA table, is in the repository.

Read the full statement

Accessible building blocks, documented honestly.