React Aria Components: Headless UI Done Right by Adobe

What React Aria Actually Is (and Isn't)

React Aria is Adobe's open-source library of headless, accessible UI primitives for React. It's been in active development since around 2020, and by version 1.0 it had already shipped WAI-ARIA patterns that most UI kits quietly ignore — date pickers that work with screen readers, comboboxes that handle keyboard navigation correctly, drag-and-drop with full keyboard fallback. None of that is easy to build from scratch.

The key distinction you need to understand: there are two layers. The lower-level @react-aria/* hooks give you pure behavior — no markup, no styles, just the event handlers and ARIA attributes you'd wire up yourself. Then there's react-aria-components, which ships as a single package and gives you lightly opinionated, unstyled component wrappers around those same hooks. Most people should reach for react-aria-components first and only drop down to the hooks when they genuinely need to.

Honestly, it's one of the most thoughtful accessibility libraries in the ecosystem. The Adobe team includes people who literally co-authored ARIA specs, and it shows. You can feel the difference the moment you try the DatePicker against screen readers vs rolling your own.

Worth noting: this is NOT a component library in the sense that it ships no visual styles at all. It's closer to Radix or Headless UI from Tailwind Labs — give it markup structure and ARIA semantics, you bring the CSS. That means it pairs well with anything: Tailwind, CSS Modules, styled-components, or even the kind of hand-crafted design tokens you'd use when building with styles from Empire UI.

Installation and Your First Component

Getting started is one npm install away. No peer dependency maze, no separate icon packages you didn't want.

npm install react-aria-components

Then you import directly from that single package. Here's a button that actually manages focus correctly, supports keyboard activation, handles disabled states properly, and communicates its pressed state to assistive tech — all without you writing a single ARIA attribute:

import { Button } from 'react-aria-components';

function SaveButton() {
  return (
    <Button
      className="px-4 py-2 bg-blue-600 text-white rounded-lg"
      onPress={() => console.log('saved')}
    >
      Save Changes
    </Button>
  );
}

Notice onPress instead of onClick. That's intentional — React Aria normalizes pointer, mouse, touch, and keyboard events into a unified onPress event that fires correctly across all input methods. This matters more than you'd think: on mobile, onClick has a 300ms delay on older WebViews, and it doesn't fire on keyboard activation at all without extra boilerplate.

Quick aside: the className prop works exactly like normal React — you can pass a string, or a render prop that receives { isHovered, isPressed, isFocused } state. That second form is where things get interesting for interactive styling.

Styling Patterns That Actually Work

The library exports zero CSS. That's a feature, not an oversight. You own the styles completely. That said, it does ship a handful of data attributes on rendered elements — data-pressed, data-hovered, data-focused, data-disabled, data-selected — which you can target directly in CSS or Tailwind.

import { Button } from 'react-aria-components';

function StyledButton({ children }: { children: React.ReactNode }) {
  return (
    <Button className={({ isPressed, isFocusVisible }) =>
      [
        'px-5 py-2.5 rounded-xl font-medium transition-all duration-150',
        'bg-violet-600 text-white',
        isPressed ? 'scale-95 brightness-90' : 'hover:brightness-110',
        isFocusVisible ? 'outline outline-2 outline-offset-2 outline-violet-400' : 'outline-none',
      ].join(' ')
    }>
      {children}
    </Button>
  );
}

That isFocusVisible flag is important. It's true only when the element was focused via keyboard navigation, not a mouse click. This is the right behavior — sighted mouse users don't need visible focus rings, keyboard users absolutely do. Getting this right yourself requires the :focus-visible pseudo-class plus careful polyfill work. React Aria handles it for you, and it even normalizes the behavior across browsers where :focus-visible support was inconsistent before 2023.

In practice, the data-attribute approach works well with plain Tailwind too. data-[pressed]:scale-95 and data-[focus-visible]:ring-2 are valid Tailwind arbitrary selectors that target those attributes directly. Either approach is fine — use whichever fits your project's CSS architecture.

If you're building a design system with visual flair on top of these primitives — say, glassmorphism components or heavily-styled neobrutalist cards — React Aria is an excellent foundation. The semantics and behavior are handled; you can focus entirely on the surface.

The Components Worth Knowing

Most headless libraries cover the basics: Button, Dialog, Select. React Aria goes further. The components you'll likely reach for most often, and the ones where it really earns its keep over rolling your own:

Select and ComboBox — These are notoriously hard to implement accessibly. A <select> element is accessible by default but impossible to style. A custom dropdown built with divs usually breaks keyboard navigation and screen readers. React Aria's Select and ComboBox give you full keyboard navigation (arrow keys, type-ahead, Home/End), ARIA roles (listbox, option), and correct focus management — wrapped in composable parts you can style however you want.

DatePicker and DateRangePicker — This is where React Aria genuinely has no real competition. The date picker handles international date formats (using the @internationalized/date package), supports calendar systems beyond Gregorian, works with screen readers announcing date field segments individually, and handles complex interactions like month navigation via keyboard. Building this yourself from scratch in 2025 would take weeks.

Table — Accessible data tables with sortable columns, row selection (single and multi), and keyboard navigation across cells. The ARIA grid pattern it implements is one of the harder specs to get right.

DragAndDrop — Full keyboard-accessible drag-and-drop. You can reorder list items using arrow keys, not just mouse drag. How many drag-and-drop libraries can say that?

import {
  Select,
  SelectValue,
  Button,
  Popover,
  ListBox,
  ListBoxItem,
} from 'react-aria-components';

function FrameworkPicker() {
  return (
    <Select defaultSelectedKey="next">
      <Button>
        <SelectValue />
        <span aria-hidden>▼</span>
      </Button>
      <Popover>
        <ListBox>
          <ListBoxItem id="next">Next.js</ListBoxItem>
          <ListBoxItem id="remix">Remix</ListBoxItem>
          <ListBoxItem id="astro">Astro</ListBoxItem>
        </ListBox>
      </Popover>
    </Select>
  );
}

React Aria vs Radix vs Headless UI

You're probably going to ask this. Here's the honest comparison.

Radix UI has a larger component surface and arguably better DX for common dialog/dropdown/menu patterns. Its API is slightly more terse. But Radix's accessibility coverage is thinner — the Date components don't exist, the drag-and-drop story is absent, and internationalization isn't baked in. If you're building a standard SaaS app with typical UI patterns and English-only, Radix is a solid pick. If you need complex date inputs or genuinely international support, React Aria wins.

Headless UI (Tailwind Labs) is the smallest of the three. As of 2026 it covers around 8 components, all of them well-built and very Tailwind-friendly, but the scope stops there. It's not trying to be comprehensive. If you're already deep in the Tailwind ecosystem and just need a Modal and a Combobox, it's fine. For anything beyond that, you're on your own.

Look, React Aria is the most complete accessibility story of the three. The tradeoff is API verbosity — the composable slot pattern means more JSX to write for simple cases. A <Select> needs five different imports where Radix might need two. Whether that's worth it depends on your accessibility requirements and whether you have international users.

One more thing — React Aria integrates with React Spectrum, Adobe's full design system built on top of these primitives, if you ever want styled defaults to start from and customise. That's a useful escape hatch if a client needs something shipped fast.

Real-World Integration Tips

A few things you'll hit in practice that the docs undersell.

Form integration: React Aria's form components work with native HTML form submission — they render actual <input> elements under the hood with the name prop you provide. That means FormData, React Hook Form, and plain action attributes all work without adapter code. This is the right call and it's something Radix gets wrong for its Select.

<Select name="role" defaultSelectedKey="editor">
  {/* ... */}
</Select>
// ^ renders a hidden <input name="role" value="editor"> automatically

Server Components: The components themselves are client components (they need event handlers), but they're lightweight enough that you won't notice. Don't try to render them on the server — wrap them in a 'use client' boundary like any interactive React component.

Theming and CSS variables: The pattern that works best at scale is defining a set of CSS custom properties on your root element — --color-primary, --radius-md, things like that — and referencing them in your React Aria component classes. This way your entire component library stays consistent with whatever brand tokens you're using, and swapping themes is a one-line change on :root. It's also how you'd wire up Empire UI's gradient generator color output into a design system.

Testing: React Aria ships with full test utilities. Components render semantic HTML that @testing-library/react queries handle naturally — getByRole('combobox'), getByRole('option', { name: 'Next.js' }). No special test IDs needed. That's exactly how accessible HTML should work.

When to Reach for React Aria

The short version: if accessibility is a genuine requirement (WCAG 2.1 AA, government contracts, enterprise buyers with legal obligations), React Aria is where you start. It handles the hard parts correctly by default, which means you're not auditing and patching ARIA attributes later when an accessibility review finds gaps.

If you're building design-forward apps where the visual layer is complex — layered glassmorphism cards, animated interfaces, custom cursors from Empire UI's cursor library — the headless approach fits perfectly. You're not fighting an opinionated component library's styles; you're wiring behavior and ARIA semantics onto your own markup.

That said, it's not the right call for quick prototypes. The API surface is real. If you need to ship a landing page fast with a basic dropdown, just use a <select> element or Headless UI. React Aria earns its verbosity in production apps that will be maintained and audited.

The 2026 web has no excuse for inaccessible custom components. The tooling exists, it's free, and libraries like React Aria mean you don't have to become an ARIA expert to ship something that works for everyone. Use it.

FAQ

Read next