We're actively working on new components and features. Stay tuned! Head over to our GitHub to see what's coming next.
Accessibility is not an add on in Rad UI.
It is a core design constraint.
Rad UI components are built to be usable by everyone, including users who rely on keyboards, screen readers, or other assistive technologies. We handle the hard, easy-to-get-wrong parts of accessibility so you do not have to reimplement them for every component.
Keyboard interactions, focus management, and ARIA semantics are treated as first class behavior, not optional extras.
As standards evolve, Rad UI evolves with them.
If you find an accessibility issue or have suggestions for improvement, please report it on our GitHub issues tracker:
https://github.com/rad-ui/ui/issues
Rad UI follows WAI-ARIA authoring practices wherever applicable.
Components are implemented with appropriate roles, states, and properties to ensure they work correctly with screen readers and other assistive technologies. We regularly review and refine these implementations to stay aligned with current best practices.
ARIA is used deliberately and only when necessary. Native semantics are preferred whenever possible.
All Rad UI components are designed to be fully operable using a keyboard.
Supported interactions include:
Keyboard behavior follows platform conventions so interactions feel familiar and predictable.
Some components are still being enhanced as part of ongoing accessibility work. Keyboard support is continuously expanding and improving across the library.
If you encounter unexpected behavior, please report it.
Rad UI takes contrast and color accessibility seriously.
Default themes aim to meet WCAG minimum contrast requirements for text and interactive elements. This helps ensure content remains readable for users with low vision or color vision deficiencies.
Rad UI does not lock you into a color system. If you are using a custom theme or design tokens, it is your responsibility to ensure contrast requirements are met.
We recommend validating custom color combinations using tools such as:
https://webaim.org/resources/contrastchecker/
Accessibility is a shared responsibility between the component library and the design system built on top of it.
Correct focus behavior is essential for accessible interfaces.
Rad UI automatically manages focus for interactive components such as dialogs, menus, popovers, and dropdowns. When a component opens, focus moves into it. When it closes, focus returns to the element that triggered it.
Components that require it implement focus trapping to ensure keyboard users do not accidentally tab outside active UI.
These behaviors are handled by default so you do not need to reimplement them or remember edge cases.
Rad UI is accessible by default, but not rigid.
You can override or extend accessibility behavior when necessary. Components allow you to:
This flexibility makes Rad UI suitable for complex applications with specialized accessibility requirements.
Accessibility is ongoing work.
We actively rely on feedback from developers and users to identify gaps, edge cases, and real world issues. All accessibility related bug reports and improvements are treated as high priority.
If you have experience in accessibility or discover a better pattern, contributions are welcome.
Together, we can build UI primitives that raise the baseline for the web.