Building accessible, well-behaved UI components from scratch takes considerably longer than most teams expect. Dropdown menus, modal dialogs, date pickers, and tooltips all carry significant accessibility requirements - keyboard navigation, focus management, ARIA attributes, screen reader announcements - that are easy to get wrong and time-consuming to implement correctly.
WAI-ARIA patterns for something as common as a listbox or combobox are non-trivial. Getting focus trapping right in a modal dialog across browsers and assistive technologies is a specific engineering problem with multiple edge cases. Teams routinely ship components that work visually but fail keyboard-only users or screen reader users entirely.
A better approach for most projects is to start with an existing open source component library as the behavioral foundation and layer your design tokens on top. Here are the five options worth evaluating, with notes on when each makes the most sense.
Photo by AS Photography on Pexels
1. Radix UI Primitives
Repository: github.com/radix-ui/primitives
Radix provides unstyled, accessible React components that handle all the interaction behavior you would otherwise spend weeks implementing correctly. Dialog, Dropdown Menu, Select, Tooltip, Popover, Tabs, Accordion, Checkbox, Radio Group, Slider, Switch, and more - each component ships with full ARIA support, keyboard navigation, and focus management baked in.
The "unstyled" part is the critical design decision. Radix components render with minimal default styles, leaving your token layer in complete control of the visual output. You own the design. Radix owns the behavior and accessibility.
This makes Radix the strongest foundation for a custom design system among React teams. The Radix UI documentation is thorough, includes anatomy diagrams showing exactly which parts of each component are customizable, and covers accessibility notes for each pattern.
"A lot of teams spend months building what Radix or Headless UI already solved. Evaluate what exists first. The real design system work is in the tokens and usage rules, not the unstyled primitives." - Dennis Traina, 137Foundry
2. Headless UI
Repository: github.com/tailwindlabs/headlessui
Headless UI from the Tailwind CSS team covers the core interactive components that most applications need: Combobox, Dialog, Disclosure, Listbox, Menu, Popover, Radio Group, Switch, Tab, and Transition. Like Radix, all components are completely unstyled.
Where Headless UI has an advantage over Radix is simplicity. The API surface is smaller, the setup is minimal, and for teams already using Tailwind it integrates naturally with utility classes. The Headless UI documentation includes both React and Vue versions with identical feature parity.
For teams that do not need the full Radix primitive set - or for those working in Vue - Headless UI provides the core interactive patterns with less surface area to learn and a very active maintenance track record from the Tailwind Labs team.
3. shadcn/ui
Repository: github.com/shadcn-ui/ui
shadcn/ui takes a fundamentally different approach from traditional component libraries. Instead of installing a package you import from, you copy individual component source files directly into your project using a CLI. Each component becomes a file you own and can modify freely without forking a dependency.
The components are built on Radix UI primitives and styled with Tailwind CSS. Running the CLI adds components to a components/ui/ directory in your project:
npx shadcn-ui@latest add button
npx shadcn-ui@latest add dialog
npx shadcn-ui@latest add select
npx shadcn-ui@latest add form
Because the source lives in your project, you can adjust behavior, styling, and even the underlying HTML structure without fighting against a package dependency. The tradeoff is that you are responsible for pulling upstream updates manually rather than through version bumps.
This model works particularly well as a design system starting point. You get professionally designed, accessible components with a well-established token convention, and you own every line of the implementation. The shadcn/ui documentation covers the CLI, theming with CSS variables, and component customization in detail.
4. React Aria
Repository: github.com/adobe/react-spectrum
React Aria from Adobe is the most accessibility-focused option on this list. It provides React hooks and components that implement WAI-ARIA patterns with deep consideration for internationalization, right-to-left text layout, and platform-specific interaction expectations (mobile touch behaviors, screen reader behavior on iOS versus desktop).
Where Radix and Headless UI provide rendered components you style, React Aria provides hooks that give you complete control over the HTML structure. A button implementation with React Aria looks like:
import { useButton } from 'react-aria';
import { useRef } from 'react';
function Button(props) {
const ref = useRef(null);
const { buttonProps } = useButton(props, ref);
return (
<button {...buttonProps} ref={ref} className="btn-primary">
{props.children}
</button>
);
}
This is more verbose than using a pre-built primitive, but it gives complete structural control - useful when you need to render to a <div> or <a> with full ARIA semantics, or when your HTML requirements do not match what a standard component renders.
For applications with strict accessibility requirements, internationalization needs, or complex platform-specific interaction expectations, React Aria is the strongest option. The React Aria documentation includes an extensive hook and component catalog with accessibility notes for each.
5. Ark UI
Repository: github.com/chakra-ui/ark
Ark UI is from the Chakra UI team and supports React, Vue, and Solid with the same component API across all three - making it valuable for teams that need consistent behavioral primitives across multiple frameworks. Components are unstyled and built on the Zag.js state machine library, which provides predictable, testable interaction logic based on statecharts.
The component set is notably comprehensive: Accordion, Carousel, Color Picker, Combobox, Date Picker, Dialog, Menu, Pagination, Pin Input, Popover, Progress, Rating Group, Select, Slider, Splitter, Switch, Tabs, Toast, Toggle Group, Tooltip, Tree View, and more.
The state machine foundation means that component interactions are explicitly modeled and easier to reason about, debug, and test. For teams that value predictability in component behavior over flexibility in implementation approach, Ark UI's architecture is a meaningful differentiator.
The Ark UI documentation covers all three frameworks with equivalent examples, which makes it easy to compare implementations.
Photo by Antonio Batinić on Pexels
Choosing the Right Foundation
None of these libraries are wrong choices for the right context. The decision comes down to your actual constraints:
- React + maximum accessibility and internationalization control: React Aria
- React + full visual control, proven ecosystem: Radix UI
- React + Tailwind, simple API: Headless UI
- React + want pre-styled components you can own and modify: shadcn/ui
- Multi-framework (React, Vue, Solid), state machine behavior: Ark UI
The web development team at 137Foundry evaluates these trade-offs when building custom web applications, usually considering the team's existing stack, the accessibility requirements of the product, and whether multi-framework support matters. Their guide on building a design system for websites and apps covers how these component foundations fit into a broader design system strategy alongside design tokens and documentation.
Whichever library you choose, the real design system work begins after that decision: defining your token layer, documenting every component variant, and writing the usage rules that prevent one-off implementations from accumulating over time.
A practical note on evaluation: before committing to any library, install it, build one component from your actual application using it, and measure how the development experience compares to your current approach. The libraries above are all well-maintained and actively used in production at scale, but team experience with the ecosystem, the level of TypeScript support you need, and the specific interaction patterns your product requires all affect which one fits best. A short proof-of-concept is a more reliable evaluation tool than documentation reading alone.
The most important thing is that you start. A design system built on any of these foundations is substantially better than a codebase where every interactive component is built from scratch - both for the consistency of the result and for the long-term maintainability of the code.
Top comments (0)