ARIA in React: When Native HTML Is Not Enough

ARIA in React is a set of attributes that describe custom widgets to assistive technology when plain HTML cannot. React writes these as normal JSX props, and the browser turns them into the accessibility tree a screen reader consumes.

Native HTML first

Most accessibility is already built into the platform. A button announces its role and handles Enter and Space.

A label associates text with an input. A link announces navigation.

Using native elements is the first and usually only step. Before adding ARIA, check whether an existing HTML element already expresses the same meaning.

Starting from a div and bolting on a role also loses the built in keyboard behavior. The native element is both simpler and more correct.

When ARIA is needed

ARIA earns its place when you build a widget with no native equivalent. A tabbed interface, a dropdown menu, a modal dialog, or a live alert are all made from divs and buttons, so they need explicit roles and states. These widgets cannot be described by a single HTML element, so ARIA supplies the vocabulary the accessibility tree is missing.

App.jsx

<div role="tablist" aria-label="Account settings">
  <button role="tab" aria-selected="true">Profile</button>
</div>

The role attributes name the parts, and aria-selected reports which tab is active. A screen reader can now describe the widget, even though the browser has no idea what a tablist is.

Roles, states, and properties

ARIA splits into three categories. A role says what a widget is, a state says what is currently true about it, and a property describes its relationships to other elements.

In JSX these are ordinary props written as role and aria-*, with the same camelCase rules as any React attribute. aria-selected, aria-expanded, and aria-labelledby all work directly on the element.

No ARIA is better than bad ARIA

Wrong ARIA is worse than no ARIA. A button given role="tab" but no tablist parent, or an aria-controls that points at nothing, actively misleads assistive technology.

The safest habit is to only add ARIA when you understand the pattern you are implementing, and to test it with a screen reader afterward. Guessing at a role produces a widget that announces nonsense.

ARIA does not do your keyboard work

ARIA describes a widget, it never implements one. Marking something role="tab" does not make the arrow keys work, and marking a dialog modal does not trap focus.

The keyboard side is still your JavaScript. The accessible tabs and accessible modal walkthroughs show both halves wired together.