Chapter 3: Accessibility

Core Idea

Radix Primitives implement WAI-ARIA authoring-practices semantics and behavior (roles, aria attributes, keyboard navigation, focus management) internally, so most components work correctly for assistive technology as-is.

Key Concepts

• WAI-ARIA: the W3C spec Radix follows for semantics of custom (non-native-HTML) controls — needed because a div-based button has no built-in accessible semantics.
• Accessible labels: for non-form or custom controls, Radix follows WAI-ARIA's name/description computation spec; the Label primitive is the built-in tool for this.
• Keyboard navigation: complex components (Tabs, Dialog, etc.) ship with WAI-ARIA-conformant keyboard support by default.
• Focus management: Radix programmatically moves focus on relevant interactions (e.g. AlertDialog moves focus to its Cancel button on open) so screen reader users get a correct context announcement.

Key Takeaways

1. You still must provide labels yourself (via the Label primitive or aria-label/aria-labelledby) — Radix gives you the mechanism, not the content.
2. Swapping a primitive's rendered element via asChild (see Composition) puts accessibility responsibility back on you — the new element must remain focusable/interactive as expected.
3. Focus-management behavior (e.g. AlertDialog's auto-focus-to-Cancel) is opinionated and generally shouldn't be fought — it mirrors WAI-ARIA authoring practices.

Connects To

• Label: the primitive built specifically to solve accessible labelling for custom controls.
• AlertDialog: cited example of built-in focus management.
• Composition guide: asChild shifts accessibility responsibility to your own element.