Accessibility

What every component ships with

• Keyboard operation — arrow-key navigation for composite widgets (Tabs, Nav, Calendar, SegmentedControl, the command palette), roving tabindex, Home/End, Escape to dismiss.
• Visible focus — a :focus-visible ring on every interactive element, never removed.
• Correct roles and state — aria-expanded, aria-current, aria-selected, aria-sort, role="dialog", and so on, 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 — the command palette, Toast, Board, and MessageList announce changes through aria-live.
• Reduced motion — every animation respects prefers-reduced-motion.
• Direction, not colour alone — Stat deltas, chart series, and status chips carry text or a glyph, not just a hue.

What stays your job

• Accessible names for your content. A Table needs an aria-label; an icon-only Button needs one; an image needs alt. The component can't know what its data means.
• Heading order. Components render the heading level you ask for (as="h2"); getting the document outline right is up to the page.
• Contrast on your theme. The defaults are checked, but once you override the palette, re-check your brand colours against their foregrounds — see Theme to your brand.
• Colour meaning. If you use color props to convey status, make sure the surrounding text says the same thing.

Testing

Run axe (or Lighthouse) on your composed screens, tab through every flow with the mouse unplugged, and check one pass with a screen reader. The components give you a clean baseline; these tests catch what you added on top.