Accessible React components

A button only a mouse can press

Many people use the web without a mouse. Some can't hold one steady, so they use the keyboard. Blind people use a screen reader, a program that reads the page aloud and is driven from the keyboard. Others speak commands, like "click Add cake". A component is accessible when all of them can use it. Here is a cart with two ways to add an item. Click both with your mouse: both add to the count.

1import { useState } from "react";2 3export default function App() {4  const [count, setCount] = useState(0);5 6  return (7    <>8      <p>Items in cart: {count}</p>9      <div className="fake-button" onClick={() => setCount(count + 1)}>10        Add tea11      </div>12      <button onClick={() => setCount(count + 1)}>Add cake</button>13    </>14  );15}

Line 8 shows the count. Lines 9 to 11 are a <div> with an onClick; the styles.css tab gives it the class fake-button, so it looks like a button. Line 12 is a real <button> with the same click handler.

Now use only the keyboard. Click the words Items in cart in the result, so the keys go to it, and press Tab. The focus ring, the outline that shows which element the keys go to, lands on Add cake. Tab skipped Add tea. Press Enter or Space: the count goes up. There is no way to press Add tea from the keyboard, and a screen reader reads it as plain text, not as something you can press. The Keyboard & focus lesson covers how the browser moves the focus.

Nothing in React is broken here. React puts the elements you write on the page, and the browser decides what each one can do. A <div> is a box for layout; a <button> is a control. Most of accessibility in React is choosing the right elements and attributes in JSX. The rest is what JSX can't describe: where the focus goes when the page changes, and telling screen reader users about changes they can't see.

Use the element that already does the job

Each HTML element comes with behavior the browser builds in. A <button> is a stop for Tab, Enter and Space press it, and it has a role, the kind of thing a screen reader says it is: "button". Using elements for what they mean is called semantic HTML. Here is what it takes to give a <div> the same behavior, beside the button that has it already:

1import { useState } from "react";2 3export default function App() {4  const [count, setCount] = useState(0);5  const addTea = () => setCount(count + 1);6 7  return (8    <>9      <p>Items in cart: {count}</p>10      <div11        className="fake-button"12        role="button"13        tabIndex={0}14        onClick={addTea}15        onKeyDown={(event) => {16          if (event.key === "Enter" || event.key === " ") {17            event.preventDefault();18            addTea();19          }20        }}21      >22        Add tea23      </div>24      <button onClick={addTea}>Add tea</button>25    </>26  );27}

Line 5 is the handler both controls share. The div needs lines 10 to 23. Line 12, role="button", tells screen readers to call it a button. Line 13, tabIndex={0}, puts it in the Tab order. Lines 15 to 20 press it when the key is Enter or Space, and line 17 stops Space from scrolling the page, as it does by default. Line 24 is the button: one line. Click in the result and press Tab: both are stops now, and Enter and Space press both.

Even after fourteen lines the div isn't a button. disabled does nothing to it, it can't submit a form, and every copy needs all of this again. Try each step in the playground: it starts with a bare div and adds one thing at a time.

<div className="fake-button" onClick={addTea}>
  Add tea
</div>

Click Before in the playground's page, then press Tab. On the first three steps Tab passes the div, or Enter does nothing. On + onKeyDown and <button>, the log shows Enter or Space. The checklist's last line stays No until the real button.

How to read the table: each row is a job, the element made for it, and what the browser gives that element for free.

A link goes somewhere and a button does something. <span onClick={() => navigate("/offers")}> breaks both rules: write <a href="/offers">. And because a component can return a Fragment, <>…</>, you never need a wrapper <div> that would break a list or a table: a component can return two <li> elements or two <td> cells as they are.

Accessibility attributes go in JSX much as in HTML. How to read the table: the HTML you may know, how to write it in JSX, and why.

A name for every control, and ids that don't clash

A screen reader says two things about each control: its role and its name, as in "Remove Cake, button". A button's name is its text. A field's name is its label. A button that shows only a symbol gets the symbol as its name:

1export default function App() {2  return (3    <ul>4      <li>5        Tea <button>×</button>6      </li>7      <li>8        Cake <button aria-label="Remove Cake">×</button>9      </li>10    </ul>11  );12}

The two buttons look the same, and that's the problem: the difference only shows to a screen reader. Line 5's button is named by its text, the symbol ×, which screen readers read as "times" or "multiplication sign". Line 8 adds aria-label="Remove Cake", which replaces the text as the name, so the button is read as "Remove Cake, button". Give every control that has no words of its own an aria-label. When a control does show words, keep them in its name, so people who say "click Remove" can still reach it.

Fields get their names from labels. The Forms lesson joined a <label> to its field with htmlFor and an id. An id has to be unique on the page, and a hard-coded id isn't, once you use the component twice. Click Cake quantity in this result:

1function QuantityField({ label }) {2  return (3    <p>4      <label htmlFor="quantity">{label}</label>{" "}5      <input id="quantity" type="number" defaultValue={1} min={1} />6    </p>7  );8}9 10export default function App() {11  return (12    <>13      <QuantityField label="Tea quantity" />14      <QuantityField label="Cake quantity" />15    </>16  );17}

The cursor jumps into Tea's box. Lines 4 and 5 write id="quantity" in the component, so lines 13 and 14 put two elements with that id on the page. The browser joins each label to the first element with the id: both labels point at Tea's box, and Cake's box has no label at all. A screen reader user moving to it hears only what kind of box it is, with no idea what it's for.

React's useId Hook fixes it. It gives each copy of a component its own id, and the same id every time that copy renders:

1import { useId } from "react";2 3function QuantityField({ label }) {4  const id = useId();5  return (6    <p>7      <label htmlFor={id}>{label}</label>{" "}8      <input id={id} type="number" defaultValue={1} min={1} />9    </p>10  );11}12 13export default function App() {14  return (15    <>16      <QuantityField label="Tea quantity" />17      <QuantityField label="Cake quantity" />18    </>19  );20}

Line 4 asks React for this copy's id. Line 7 joins the label to it, and line 8 gives the box the same id. Click Cake quantity now: the cursor goes into the second box. The ids look like _r_0_ and _r_1_; you never write them yourself.

Why not count yourself, with a variable outside the component? It works in one browser, but not on a site whose HTML a server makes first:

let nextId = 0;

function QuantityField({ label }) {
  const id = `quantity-${++nextId}`;
  return (
    <p>
      <label htmlFor={id}>{label}</label>{" "}
      <input id={id} type="number" defaultValue={1} min={1} />
    </p>
  );
}

Line 1 keeps a counter, and line 4 takes the next number on every render. Frameworks like Next.js first run your components on a server to make the page's HTML, then React runs them again in the browser and connects to that HTML. This is called hydration, and it expects both runs to produce the same page. But the server keeps the module loaded between visitors, so the second visitor's HTML says quantity-3 and quantity-4, while their browser starts counting at 1. React warns that the server's HTML doesn't match. Even in the browser alone, the counter counts renders, not fields: in development, StrictMode calls each component twice, so this example's ids come out as quantity-2 and quantity-4. useId builds the id from the component's place in the tree, which is the same on the server and in the browser. The Server rendering and hydration lesson covers hydration.

Move the focus when the page changes

The focus is where the keyboard's keys go. When an action removes the focused element, or opens something new, the browser doesn't know where the user wants to be next. You do. This cart's rows each have a Remove button, named with aria-label. The FocusReport.jsx tab adds a line under the cart that says where the focus is; you don't need to read it.

1import { useState } from "react";2import FocusReport from "./FocusReport.jsx";3 4const startItems = [5  { id: 1, name: "Tea" },6  { id: 2, name: "Cake" },7  { id: 3, name: "Lemonade" },8];9 10export default function App() {11  const [items, setItems] = useState(startItems);12 13  function remove(index) {14    setItems(items.filter((_, i) => i !== index));15  }16 17  return (18    <>19      <h2>Your cart ({items.length})</h2>20      <ul>21        {items.map((item, index) => (22          <li key={item.id}>23            {item.name}{" "}24            <button onClick={() => remove(index)} aria-label={`Remove ${item.name}`}>25              Remove26            </button>27          </li>28        ))}29      </ul>30      <FocusReport />31    </>32  );33}

Click the heading Your cart in the result, press Tab twice to reach Cake's button, and press Enter. The row goes, and the last line says Focus: the page itself (<body>). Line 14 only removes the item from the list. The focused button was in that row, line 24, and when React removes it, the browser can't keep the focus on an element that's gone, so it puts the focus on <body>. Press Tab: you're back at the first button, and a screen reader user has lost their place.

Fix it by deciding where the focus goes: to the next row's button, to the one before when you removed the last row, and to the heading when the cart is empty. You need the DOM nodes, so this is a job for refs:

1import { useRef, useState } from "react";2import FocusReport from "./FocusReport.jsx";3 4const startItems = [5  { id: 1, name: "Tea" },6  { id: 2, name: "Cake" },7  { id: 3, name: "Lemonade" },8];9 10export default function App() {11  const [items, setItems] = useState(startItems);12  const heading = useRef(null);13  const buttons = useRef(new Map());14 15  function remove(index) {16    const next = items[index + 1] ?? items[index - 1];17    setItems(items.filter((_, i) => i !== index));18    if (next) buttons.current.get(next.id).focus();19    else heading.current.focus();20  }21 22  return (23    <>24      <h2 ref={heading} tabIndex={-1}>25        Your cart ({items.length})26      </h2>27      <ul>28        {items.map((item, index) => (29          <li key={item.id}>30            {item.name}{" "}31            <button32              ref={(node) => {33                buttons.current.set(item.id, node);34                return () => buttons.current.delete(item.id);35              }}36              onClick={() => remove(index)}37              aria-label={`Remove ${item.name}`}38            >39              Remove40            </button>41          </li>42        ))}43      </ul>44      <FocusReport />45    </>46  );47}

• Line 12 is a ref for the heading, and line 24 lets code focus it: tabIndex={-1} makes an element focusable by focus() without adding a Tab stop.
• Line 13 keeps a Map of buttons by item id. Lines 32 to 35 are a ref callback: React calls it with each button's node, which it adds to the Map, and calls the function it returns when the button goes, which deletes it.
• Line 16 picks the row after the removed one, or the row before when there is none after.
• Line 18 focuses that row's button, and line 19 focuses the heading when no row is left. That button is already on the page, and React keeps it because its key doesn't change, so focus() can run right away, before React re-renders.

Try the same keys again. After Remove Cake, the last line says Focus: <button> Remove Lemonade. Remove the rest, and it ends on the heading.

Opening something works the other way: the focus should move into it, and come back when it closes. A dialog, a box that sits over the page until you answer it, needs three things: the focus moves into it when it opens, Tab stays inside it while it's open, and the focus returns to the button that opened it when it closes. The browser's <dialog> element does all three when you open it with showModal():

1import { useId, useRef, useState } from "react";2import FocusReport from "./FocusReport.jsx";3 4export default function App() {5  const [items, setItems] = useState(["Tea", "Cake"]);6  const dialog = useRef(null);7  const titleId = useId();8 9  function emptyCart() {10    setItems([]);11    dialog.current.close();12  }13 14  return (15    <>16      <p>Items in cart: {items.length}</p>17      <button onClick={() => dialog.current.showModal()}>Empty cart…</button>18      <dialog ref={dialog} aria-labelledby={titleId}>19        <h2 id={titleId}>Empty your cart?</h2>20        <button onClick={() => dialog.current.close()}>Keep my items</button>21        <button onClick={emptyCart}>Empty it</button>22      </dialog>23      <FocusReport />24    </>25  );26}

Line 17 calls showModal() on the dialog through the ref from line 6. Line 18 names the dialog with aria-labelledby, pointing at the heading on line 19 through an id from useId on line 7, so a screen reader announces "Empty your cart?, dialog". Press Empty cart… from the keyboard: the focus moves to Keep my items, and the rest of the page is inert: Tab and clicks can't reach it. Press Escape or either button, and the focus returns to Empty cart…. The Portals lesson covers modals you build yourself.

For a panel that isn't a dialog, like a filter list that opens under a button, focus its first control in the same handler that opens it, after flushSync has put it on the page (flushSync, from Manipulating the DOM with refs, makes React update the page before the next line runs). And move the focus only after an action the user took; a focus that jumps while someone reads or types is as confusing as one that's lost.

Announce changes with a live region

Some changes happen away from the focus: "Added to cart", "12 results", "Saved". A sighted user sees them; a screen reader user hears nothing, because a screen reader reads what the focus is on. A live region is an element whose text changes the screen reader reads aloud, wherever the focus is.

1import { useState } from "react";2 3export default function App() {4  const [items, setItems] = useState([]);5  const [message, setMessage] = useState("");6 7  function add(name) {8    const count = items.length + 1;9    setItems([...items, name]);10    setMessage(`Added ${name}. ${count} ${count === 1 ? "item" : "items"} in your cart.`);11  }12 13  return (14    <>15      <button onClick={() => add("Tea")}>Add tea</button>16      <button onClick={() => add("Cake")}>Add cake</button>17      <p role="status">{message}</p>18    </>19  );20}

Line 5 keeps the message in state. Line 10 writes a new message on each click, with the new count. Line 17 is the live region: role="status" makes the paragraph one. It's on the page from the start, empty, and each click only changes its text. Click Add tea: the line says Added Tea. 1 item in your cart. With a screen reader on (VoiceOver: Command+F5 on a Mac; NVDA is free on Windows), you'd hear it read while the focus stays on the button.

The order matters. A screen reader watches the live regions already on the page for changes. If the region arrives together with its text, as with {message && <p role="status">{message}</p>}, many screen readers miss that message. Try the three ways of writing line 17:

1import { useState } from "react";2 3export default function App() {4  const [items, setItems] = useState([]);5  const [message, setMessage] = useState("");6 7  function add(name) {8    const count = items.length + 1;9    setItems([...items, name]);10    setMessage(`Added ${name}. ${count} ${count === 1 ? "item" : "items"} in your cart.`);11  }12 13  return (14    <>15      <button onClick={() => add("Tea")}>Add tea</button>16      <button onClick={() => add("Cake")}>Add cake</button>17      <p role="status">{message}</p>18    </>19  );20}

With the region always there, both clicks are read. Added with the message, the first click's message may be missed, and the second is read, because by then the region exists. With no live region, nothing is read at all.

How to read the table: each kind of live region, how it speaks, and what it's for.

Keep messages short, and announce only what the user needs. A status line can also be hidden from sight with a CSS class that keeps it readable, often called visually-hidden; don't use display: none, which hides it from screen readers too.

Form errors a screen reader can find

A red border and a message beside a field are clear if you can see them. To a screen reader they're just more text somewhere on the page. An accessible error is joined to its field, and the focus takes the user to it. This checkout form puts together everything so far:

1import { useId, useState } from "react";2import { flushSync } from "react-dom";3 4function Field({ label, name, type = "text", error }) {5  const id = useId();6  const errorId = `${id}-error`;7  return (8    <p>9      <label htmlFor={id}>{label}</label>{" "}10      <input11        id={id}12        name={name}13        type={type}14        aria-invalid={error ? true : undefined}15        aria-describedby={error ? errorId : undefined}16      />17      {error && (18        <span id={errorId} className="error">19          {error}20        </span>21      )}22    </p>23  );24}25 26function check({ name, email }) {27  const errors = {};28  if (!name.trim()) errors.name = "Enter your name.";29  if (!email.includes("@")) errors.email = "Enter an email address with an @.";30  return errors;31}32 33export default function App() {34  const [errors, setErrors] = useState({});35  const [sent, setSent] = useState(false);36 37  function handleSubmit(event) {38    event.preventDefault();39    const form = event.currentTarget;40    const found = check(Object.fromEntries(new FormData(form)));41    flushSync(() => setErrors(found));42    const first = Object.keys(found)[0];43    if (first) form.elements[first].focus();44    setSent(!first);45  }46 47  return (48    <form onSubmit={handleSubmit} noValidate>49      <Field label="Name" name="name" error={errors.name} />50      <Field label="Email" name="email" type="email" error={errors.email} />51      <button>Place order</button>52      <p role="status">{sent ? "Thanks! Your order is on its way." : ""}</p>53    </form>54  );55}

Press Place order with both boxes empty. Both errors appear, the boxes turn red, and the cursor lands in Name. Type a name and press it again: the cursor moves to Email. Fill in both, and the status line thanks you.

• Line 5 gets an id for each Field, and line 6 makes the error's id from it. Line 9 joins the label, as in the names section.
• While there's an error, line 14 sets aria-invalid, so a screen reader says "invalid", and line 15 sets aria-describedby to the error's id, so it reads the message after the label. Line 18 gives the message that id. With no error, both are undefined, and React leaves them out.
• Line 48's noValidate turns off the browser's own error bubbles, so these messages are the only ones. The Form validation lesson covers the browser's checks.
• In handleSubmit, line 40 reads the boxes with FormData and checks them with check. Line 41 sets the errors inside flushSync, which makes React put them on the page before the next line runs. Line 43 then focuses the first wrong field, found by its name in form.elements.

Why flushSync? A screen reader reads a field when the focus arrives. Without it, line 43 would focus the field before React added the error and aria-describedby, and the field would be read without them. With it, the user hears something like "Name, invalid entry, Enter your name." The [aria-invalid="true"] rule in styles.css draws the red border from the same attribute, so the color and what's read can't disagree.

Test with the keyboard, a linter, and axe

Each kind of check finds problems the others miss. The quickest is your own keyboard:

• Put the mouse away. Press Tab and Shift+Tab through the page: every control should get a stop, in reading order.
• Watch the focus ring at every stop. Never remove it with outline: none unless you draw another one in its place, for example with the :focus-visible selector.
• Press Enter and Space on buttons, Escape in dialogs, and do every action you would do with the mouse.
• After each action, check where the focus went.

A linter reads your code as you type and reports mistakes. eslint-plugin-jsx-a11y is ESLint's accessibility plugin for JSX. Next.js's ESLint config turns on a few of its rules; this turns on its recommended set:

// eslint.config.js
import jsxA11y from "eslint-plugin-jsx-a11y";

export default [
  jsxA11y.flatConfigs.recommended,
];

Line 2 imports the plugin, and line 5 adds its recommended rules to an ESLint flat config. Given the overview's div, the plugin reports two problems:

<div className="fake-button" onClick={() => setCount(count + 1)}>
  Add tea
</div>

• jsx-a11y/click-events-have-key-events: "Visible, non-interactive elements with click handlers must have at least one keyboard listener."
• jsx-a11y/no-static-element-interactions: "Avoid non-native interactive elements. If using native HTML is not possible, add an appropriate role and support for tabbing, mouse, keyboard, and touch inputs to an interactive content element."

The first says a click handler needs a keyboard handler beside it. The second says the div isn't a control, so it shouldn't take one at all. Both point to the same fix, a <button>. The plugin doesn't catch everything: its recommended rules say nothing about the unnamed × button from the names section, because a button with any text, even a symbol, counts as named.

axe, from the company Deque, checks the page as it's rendered: buttons and fields with no name, missing labels, colors too faint to read, and wrong ARIA. Run it as the axe DevTools browser extension; Chrome's Lighthouse report uses it too. In tests, axe-core runs inside jest-axe, vitest-axe, or @axe-core/playwright. The older @axe-core/react package doesn't support React 18 or later (its README says so, checked in October 2026). axe can't see your click handlers or where the focus goes, so it doesn't replace the keyboard. The Testing React components lesson finds elements by role and name, the way a screen reader does.

How to read the table: each check, what it finds, and what it can't find.

An accessible cart

Here is a cart that uses every part of the lesson: real buttons, names for the symbol buttons, the focus moved after a remove, and a status line. Use it with only the keyboard.

1import { useRef, useState } from "react";2import FocusReport from "./FocusReport.jsx";3 4const startItems = [5  { id: 1, name: "Tea", quantity: 1 },6  { id: 2, name: "Cake", quantity: 2 },7  { id: 3, name: "Lemonade", quantity: 1 },8];9 10export default function App() {11  const [items, setItems] = useState(startItems);12  const [message, setMessage] = useState("");13  const heading = useRef(null);14  const removeButtons = useRef(new Map());15 16  function changeQuantity(item, change) {17    const quantity = Math.max(1, item.quantity + change);18    setItems(items.map((other) => (other.id === item.id ? { ...other, quantity } : other)));19    setMessage(`${item.name}: ${quantity}`);20  }21 22  function remove(index) {23    const next = items[index + 1] ?? items[index - 1];24    setItems(items.filter((_, i) => i !== index));25    setMessage(`Removed ${items[index].name}.`);26    if (next) removeButtons.current.get(next.id).focus();27    else heading.current.focus();28  }29 30  return (31    <section aria-label="Shopping cart">32      <h2 ref={heading} tabIndex={-1}>33        Your cart ({items.length})34      </h2>35      <ul>36        {items.map((item, index) => (37          <li key={item.id}>38            {item.name}{" "}39            <button onClick={() => changeQuantity(item, -1)} aria-label={`One less ${item.name}`}>40              −41            </button>{" "}42            {item.quantity}{" "}43            <button onClick={() => changeQuantity(item, 1)} aria-label={`One more ${item.name}`}>44              +45            </button>46            <button47              ref={(node) => {48                removeButtons.current.set(item.id, node);49                return () => removeButtons.current.delete(item.id);50              }}51              onClick={() => remove(index)}52              aria-label={`Remove ${item.name}`}53            >54              ×55            </button>56          </li>57        ))}58      </ul>59      <p role="status">{message}</p>60      <FocusReport />61    </section>62  );63}

• Lines 39 to 45 are the − and + buttons. They show symbols, so aria-label names them: One less Tea, One more Tea. Line 19 says the new quantity in the status line on line 59.
• Lines 46 to 55 are the × button, named Remove Tea, with the ref callback from the focus section. remove, lines 22 to 28, picks the next row, removes the item, says Removed Tea., and moves the focus.
• Line 31's aria-label names the whole <section>, so a screen reader can list it as a landmark, Shopping cart.

Click the heading, press Tab twice to reach One more Tea, and press Enter: the quantity becomes 2 and the status line says Tea: 2. Tab to Tea's × and press Enter: the status line says Removed Tea. and the focus line says <button> Remove Cake.

Common mix-ups

• "role="button" turns a div into a button." No. It only changes what screen readers say. Tab, Enter, Space, and disabled still need code, and a <button> has them already.
• "A placeholder is a label." No. It disappears as soon as you type, so the field loses its name on screen, and some screen readers don't read it. Join a <label>.
• "React makes my components accessible." No. React puts the elements you write on the page. A div with onClick is as hard to use in React as in plain HTML.
• "aria-label on everything helps." No. It replaces an element's own text as its name. Use it for controls with no words, like ×; on a button that already says "Remove", keep that word in the name.
• "tabIndex={1} fixes the Tab order." No. A positive tabIndex jumps ahead of everything else on the page. Put the elements in the right order in JSX, and use only 0 and -1.
• "The focus ring looks untidy, so remove it." No. Without it, keyboard users can't tell where they are. Restyle it with :focus-visible instead.
• "If axe finds nothing, the page is accessible." No. axe can't press keys or follow the focus. Test with the keyboard, and with a screen reader when you can.

Practice exercises

Each exercise shows its code's result. Click in it and use the keyboard: Tab, Shift+Tab, Enter, and Space. Change the code with Edit & run, and the result updates as you type.

1export default function App() {2  return (3    <>4      <div onClick={() => {}}>Menu</div>5      <button>Search</button>6      <a href="#offers">Offers</a>7      <span onClick={() => {}}>Help</span>8      <a>Contact</a>9      <input aria-label="Email" placeholder="Email" />10    </>11  );12}

1export default function App() {2  return (3    <>4      <div onClick={() => {}}>Menu</div>5      <button>Search</button>6      <a href="#offers">Offers</a>7      <span onClick={() => {}}>Help</span>8      <a>Contact</a>9      <input aria-label="Email" placeholder="Email" />10    </>11  );12}

1import { useState } from "react";2 3export default function App() {4  const [quantity, setQuantity] = useState(1);5 6  return (7    <p>8      Tea{" "}9      <button onClick={() => setQuantity(Math.max(1, quantity - 1))}>−</button>10      {" "}{quantity}{" "}11      <button onClick={() => setQuantity(quantity + 1)}>+</button>12    </p>13  );14}

1import { useState } from "react";2 3export default function App() {4  const [quantity, setQuantity] = useState(1);5 6  return (7    <p>8      Tea{" "}9      <button onClick={() => setQuantity(Math.max(1, quantity - 1))} aria-label="One less Tea">10        −11      </button>12      {" "}{quantity}{" "}13      <button onClick={() => setQuantity(quantity + 1)} aria-label="One more Tea">14        +15      </button>16    </p>17  );18}

1function NoteField({ label }) {2  return (3    <p>4      <label htmlFor="note">{label}</label>5      <br />6      <textarea id="note" rows={2} />7    </p>8  );9}10 11export default function App() {12  return (13    <>14      <NoteField label="Gift note" />15      <NoteField label="Delivery note" />16    </>17  );18}

1import { useId } from "react";2 3function NoteField({ label }) {4  const id = useId();5  return (6    <p>7      <label htmlFor={id}>{label}</label>8      <br />9      <textarea id={id} rows={2} />10    </p>11  );12}13 14export default function App() {15  return (16    <>17      <NoteField label="Gift note" />18      <NoteField label="Delivery note" />19    </>20  );21}

1import { useState } from "react";2 3export default function App() {4  const [open, setOpen] = useState(false);5 6  return (7    <>8      <div className="fake-button" onClick={() => setOpen(!open)}>9        {open ? "Hide" : "Show"} delivery details10      </div>11      {open && <p>Orders before 2 pm leave the same day.</p>}12    </>13  );14}

1import { useId, useState } from "react";2 3export default function App() {4  const [open, setOpen] = useState(false);5  const detailsId = useId();6 7  return (8    <>9      <button aria-expanded={open} aria-controls={detailsId} onClick={() => setOpen(!open)}>10        {open ? "Hide" : "Show"} delivery details11      </button>12      <p id={detailsId} hidden={!open}>13        Orders before 2 pm leave the same day.14      </p>15    </>16  );17}

1import { useState } from "react";2import FocusReport from "./FocusReport.jsx";3 4const startWishes = [5  { id: 1, name: "Green tea" },6  { id: 2, name: "Lemon cake" },7  { id: 3, name: "Mint tea" },8];9 10export default function App() {11  const [wishes, setWishes] = useState(startWishes);12 13  function remove(index) {14    setWishes(wishes.filter((_, i) => i !== index));15  }16 17  return (18    <>19      <h2>Wishlist</h2>20      <ul>21        {wishes.map((wish, index) => (22          <li key={wish.id}>23            {wish.name}{" "}24            <button onClick={() => remove(index)}>Remove {wish.name}</button>25          </li>26        ))}27      </ul>28      <FocusReport />29    </>30  );31}

1import { useRef, useState } from "react";2import FocusReport from "./FocusReport.jsx";3 4const startWishes = [5  { id: 1, name: "Green tea" },6  { id: 2, name: "Lemon cake" },7  { id: 3, name: "Mint tea" },8];9 10export default function App() {11  const [wishes, setWishes] = useState(startWishes);12  const heading = useRef(null);13  const buttons = useRef(new Map());14 15  function remove(index) {16    const next = wishes[index + 1] ?? wishes[index - 1];17    setWishes(wishes.filter((_, i) => i !== index));18    if (next) buttons.current.get(next.id).focus();19    else heading.current.focus();20  }21 22  return (23    <>24      <h2 ref={heading} tabIndex={-1}>25        Wishlist26      </h2>27      <ul>28        {wishes.map((wish, index) => (29          <li key={wish.id}>30            {wish.name}{" "}31            <button32              ref={(node) => {33                buttons.current.set(wish.id, node);34                return () => buttons.current.delete(wish.id);35              }}36              onClick={() => remove(index)}37            >38              Remove {wish.name}39            </button>40          </li>41        ))}42      </ul>43      <FocusReport />44    </>45  );46}

1import { useState } from "react";2 3export default function App() {4  const [error, setError] = useState("");5 6  function handleSubmit(event) {7    event.preventDefault();8    const code = new FormData(event.currentTarget).get("coupon");9    setError(code.trim() ? "" : "Enter a coupon code.");10  }11 12  return (13    <form onSubmit={handleSubmit}>14      <label>15        Coupon code <input name="coupon" />16      </label>{" "}17      <button>Apply</button>18      {error && <p className="error">{error}</p>}19    </form>20  );21}

1import { useId, useState } from "react";2import { flushSync } from "react-dom";3 4export default function App() {5  const [error, setError] = useState("");6  const errorId = useId();7 8  function handleSubmit(event) {9    event.preventDefault();10    const form = event.currentTarget;11    const code = new FormData(form).get("coupon");12    flushSync(() => setError(code.trim() ? "" : "Enter a coupon code."));13    if (!code.trim()) form.elements.coupon.focus();14  }15 16  return (17    <form onSubmit={handleSubmit}>18      <label>19        Coupon code{" "}20        <input21          name="coupon"22          aria-invalid={error ? true : undefined}23          aria-describedby={error ? errorId : undefined}24        />25      </label>{" "}26      <button>Apply</button>27      {error && (28        <p id={errorId} className="error">29          {error}30        </p>31      )}32    </form>33  );34}

Check your understanding

For each question, picture someone using only a keyboard, and someone using a screen reader.

Key takeaways

• React renders the elements you write. Accessibility starts with choosing the right ones in JSX.
• Use a <button> for actions and an <a href> for going somewhere. A div with onClick misses Tab, keys, a role, and disabled.
• Every control needs a name: its text, its label, or an aria-label when it shows only a symbol.
• Make ids with useId: one per copy of a component, the same on the server and in the browser.
• When an action removes the focused element or opens something, move the focus with a ref. <dialog> with showModal() handles a dialog's focus for you.
• Announce changes with a role="status" region that's on the page from the start.
• Join errors with aria-describedby and aria-invalid, and focus the first wrong field after flushSync.
• Test with the keyboard, eslint-plugin-jsx-a11y, axe, and a screen reader. Each finds what the others miss.

Coming next: Class components and older patterns. It shows how to read and maintain React code written before Hooks.