Command Palette

Search for a command to run...

Hectal
Phase 18Intermediate19 of 28 in React

Accessibility in React

Build React apps everyone can use: semantic HTML, focus after re-renders and route changes, ARIA with useId, live regions, keyboard widgets and a11y testing.

Accessibility (often shortened to a11y: an a, 11 letters, a y) means people can use your app however they use a computer: with a mouse, a keyboard only, a screen reader that reads the page aloud, a switch, voice control or a zoomed-in screen. The HTML course (/html, Phase 7) teaches the foundations: semantic elements, alt text, labels, keyboard focus and ARIA basics. This phase is about what React changes: components that render div soup, focus that gets lost when React replaces a part of the page or when a route changes, modals rendered through portals, async updates nobody hears about, ids that must be unique when a component is used many times, and interactive widgets you build yourself.

You'll start from the rule that solves most problems, use the right HTML element, then learn to manage focus with refs, connect labels, hints and errors with useId, announce changes with live regions, and build the WAI-ARIA Authoring Practices patterns (dialog, disclosure, tabs, menu button, combobox) with exact keyboard behaviour. The last topic shows how to test all of it: role queries, axe, keyboard-only and screen reader checks, reduced motion and contrast.

Every example runs real React 19 in your browser. Many of them log document.activeElement (the element that has keyboard focus) so you can see focus move, and the exercises check roles, aria-* attributes, focus and arrow-key handling just like an accessibility test would.

0/5 · 0%
5 topics ~2 h 18 code blocks & diagrams
Start with the first topic
1
18.1

Accessible React Starts with HTML

React renders plain HTML, so most accessibility comes free when your components output the right elements: real buttons, labelled inputs, headings and landmarks, with Fragments instead of wrapper divs that break the structure.

32 min 4 code practice

2
18.2

Managing Focus

Keyboard and screen reader users follow focus, so when React swaps content, changes the route or opens a modal, you must decide where focus goes: to the new page's heading, into the dialog, and back to the button that opened it.

28 min 3 code practice

3
18.3

ARIA in React

ARIA attributes add roles, names, relationships and states that HTML can't express; in React you write them as hyphenated aria-* props, connect elements with ids from useId, and announce async changes with live regions.

24 min 3 code practice

4
18.4

Accessible Interactive Components

Dialogs, disclosures, tabs, menu buttons and comboboxes each have a standard keyboard pattern in the WAI-ARIA Authoring Practices; build them with the right roles, states and keys, prefer native elements where they exist, and reach for a tested headless library for the hard ones.

32 min 4 code practice

5
18.5

Testing Accessibility

Test accessibility in layers: role-based Testing Library queries that fail when names and roles are missing, automated axe scans, keyboard-only walkthroughs, real screen reader checks, and checks for reduced motion and colour contrast.

28 min 4 code practice

Practise this phase

Hands-on exercises: write the code, see your page live, and press Check to have it tested automatically.

1

Turn clickable divs into buttons

This notes list uses <div onClick> for its Delete controls, so keyboard and screen reader users can't delete anything.

Beginner
2

Link labels, hints and errors with useId

The Field component is used twice, but it hard-codes id="field", so both labels point at the first input, and the hint and error aren't connected to the input at all.

Beginner
3

An accessible FAQ disclosure

Each FAQ question is a clickable <h3>: it toggles with the mouse but isn't reachable by keyboard and doesn't say whether it is open.

Intermediate
4

Announce search results with a live region

This search shows Searching… and then N results, but the message only appears when there is one, so screen readers miss it.

Intermediate
5

A confirm dialog that manages focus

The Delete photo button (id="open") shows a confirm box, but it's rendered with the open attribute, so it isn't modal: focus stays behind it and keyboard users can't tell it appeared.

Intermediate
6

Mini build: keyboard-accessible tabs

Turn the three plain buttons into an accessible tabs widget following the WAI-ARIA tabs pattern (automatic activation):

Advanced