Features

Accessible React components

An accessible baseline you don't have to build first.

The short answer

Every oks-ui component ships with keyboard support, a visible focus indicator, correct ARIA roles and state, and reduced-motion handling, so an accessible baseline needs no extra code. Accessible names for your own content, heading order and contrast on your own theme remain your responsibility.

What every component ships with

Keyboard operation. Arrow-key navigation for composite widgets (Tabs, Calendar, SegmentedControl, Dropdown, the command palette), roving tabindex, Home and End in the lists that need them, and Escape to dismiss overlays. Nav is a real <nav> of links, so you move through it with Tab.
Visible focus. Most interactive components draw a :focus-visible ring that shows for keyboard users, and Tabs keep the browser’s own focus outline. The command palette’s search field has no ring of its own; the highlighted result shows where you are.
Correct roles and state. aria-expanded, aria-current, aria-selected, aria-sort and role="dialog", wired to the component’s actual state.
Focus management in overlays. Modal and Drawer trap focus, restore it to the trigger on close, and lock body scroll.
Live regions. Toast, Board and Message (as a live log) announce changes through aria-live. The command palette uses the combobox pattern instead, with aria-activedescendant pointing at the highlighted result.
Reduced motion. Every animation respects prefers-reduced-motion.
More than colour. Stat deltas, chart series and status chips carry text or a glyph, not just a hue.

Try it

Try it with the keyboard only

Your public profile.

Press Tab to reach the tabs, then use the arrow keys, Home and End to move between them. Press Tab to the button, open the dialog with Enter, notice focus stays inside it, and close it with Esc.

What stays your job

Accessible names for your content. A Table needs an aria-label, an icon-only Button needs one, and an image needs alt. A component cannot know what your data means.
Heading order. Components render the heading level you ask for; the page’s outline is yours to get right.
Contrast on your theme. The defaults are checked. After overriding the palette, re-check your brand colours against their foregrounds.
Colour meaning. If a color prop conveys status, make sure the surrounding text says the same thing.

Test what you build

Run axe or Lighthouse on your composed screens, tab through every flow without a mouse, and do one pass with a screen reader. The full guidance is in the accessibility docs.

Questions

Are oks-ui components accessible?

Accessibility is a core design goal. Components ship with keyboard operation, a focus indicator for keyboard users, ARIA roles and attributes tied to their real state, and prefers-reduced-motion support. Modal and Drawer trap focus and restore it to the trigger on close. This site is built with oks-ui and scored 100 for Accessibility in Lighthouse on mobile on 24 September 2026.

Does oks-ui guarantee WCAG compliance?

No library can, because compliance depends on your content and theme as well as the components. oks-ui gives you an accessible baseline. You still need to name icon-only buttons and tables, keep heading order correct, and check contrast after changing the palette. Test finished screens with axe and a screen reader.

Do the components work with a keyboard only?

Yes. Composite widgets such as Tabs, Calendar, SegmentedControl, Dropdown and the command palette use arrow-key navigation, overlays close with Escape, and Nav is a plain list of links you move through with Tab. Interactive components show a focus indicator for keyboard users.

Keep exploring

Figures and claims on this page were last checked on 2026-09-24.