Accessibility

WCAG 2.2 level AA, for every documented example and in the environments the library is tested in (see Browser support). Each component follows the matching pattern of the WAI-ARIA Authoring Practices Guide, linked from its page, and is built on a Radix primitive, so roles, focus management and keyboard behaviour come from a widely used base.

• Keyboard: every row of every component's keyboard table has a test that presses the keys and checks the result.
• Automated checks: axe runs on every state of every component in the unit tests, and again in a real browser on every page and example of this site, in the light and the dark theme, colour contrast included.
• Contrast: bui-contrast checks every text colour the components draw against each surface at 4.5:1, and every form control's edge at 3:1, in both themes, for the default palette and for the products' palettes.
• Screen readers: a manual pass with VoiceOver and Safari, recorded below with the versions used.

Component	What was checked	VoiceOver and Safari
Checkbox	Its name and state are read; Space toggles it and the new state is read	Recorded at the launch review
Select	The field's name and value; the open list's options and the chosen one	Recorded at the launch review
Tabs	The tab list, each tab's name, position and selection	Recorded at the launch review
Dialog	Its title and role on opening; focus back on the opener after Escape	Recorded at the launch review

The components cannot know your content. Each page's Accessibility section says what you must provide; most often:

• Names. Every control needs a name: a Label tied to it, visible text, or aria-label for an icon-only button.
• Errors. Mark an invalid field with aria-invalid and tie its message to it with aria-describedby.
• Titles. Every dialog and sheet needs a title, visible or kept for screen readers with className="sr-only".
• Translations. Pass your translated strings to the provider (Strings and translation).
• Contrast. Run bui-contrast on your palette.

If a component is hard to use with a keyboard, a screen reader, zoom or another assistive technology, open an issue on GitHub with the component, the browser and assistive technology with their versions, and what happened. Accessibility problems are fixed before new features.