Accessible Forms in React: Labels, Errors, and useId

Every input needs a programmatically associated label — a real <label> tied to the input by matching htmlFor and id. In React the trap is the id: hard-code it and the moment the component renders twice on a page you have duplicate ids, which silently break the association. The useId hook exists to solve exactly this.

import { useId } from 'react';

function TextField({ label, ...props }) {
  const id = useId(); // unique & stable, even across many instances

  return (
    <div className="field">
      <label htmlFor={id}>{label}</label>
      <input id={id} {...props} />
    </div>
  );
}

useId generates a unique, render-stable identifier that also matches between server and client rendering, so it will not cause hydration mismatches. Use it for every id you need to wire up an accessibility relationship — label to input, input to error, group to description. Never invent ids from array indexes or props that might repeat. For the fundamentals of labelling, see the form labeling guide.

Controlled inputs — where React state is the source of truth and onChange updates it — are perfectly accessible, as long as you do not break the basics the browser gives you for free. Keep the native input type, keep a real label, and add the right autocomplete so browsers and password managers can fill it.

function EmailField({ value, onChange }) {
  const id = useId();
  return (
    <div className="field">
      <label htmlFor={id}>Email</label>
      <input
        id={id}
        type="email"          // native type: correct keyboard & validation
        value={value}
        onChange={(e) => onChange(e.target.value)}
        autoComplete="email"  // let the browser autofill
      />
    </div>
  );
}

An error message that is only visible is invisible to a screen reader. Two attributes tie an error to its field so assistive tech reports it: aria-describedby points the input at the error's id, and aria-invalid marks the field as in error.

function EmailField({ value, onChange, error }) {
  const id = useId();
  const errorId = `${id}-error`;

  return (
    <div className="field">
      <label htmlFor={id}>Email</label>
      <input
        id={id}
        type="email"
        value={value}
        onChange={(e) => onChange(e.target.value)}
        autoComplete="email"
        aria-invalid={error ? true : undefined}
        aria-describedby={error ? errorId : undefined}
      />
      {error && (
        <p id={errorId} className="field-error" role="alert">
          {error}
        </p>
      )}
    </div>
  );
}

How it works: aria-describedby makes a screen reader read the error text when the field gains focus, and aria-invalid announces the field as invalid. Adding role="alert" to the error element means it is also announced the moment it appears, so a user does not have to re-focus the field to hear it. Set aria-invalid and aria-describedby to undefined (not false/empty) when there is no error, so the attributes are omitted entirely rather than pointing at nothing.

Per-field errors handle the field-by-field case. When a whole form fails validation on submit, do not leave the user to hunt for the problems — take them straight there. Two proven patterns, often combined:

• Move focus to the first invalid field so the next thing the user does is fix it.
• Render an error summary at the top of the form listing every error as a link to its field, and move focus to that summary.

Both rely on the ref-and-effect focus pattern — capture a ref, then call .focus() after the failed submit. The full mechanics (including a reusable focusable error summary) are in the focus management in React guide. The summary should be a focusable container (tabIndex={-1}) with role="alert", so it is both announced and navigable.

Radio buttons and related checkboxes need a group label, not just individual labels — otherwise a screen reader user hears "Standard, radio button" with no idea what question it answers. Wrap the group in a <fieldset> with a <legend>.

function ShippingChoice({ value, onChange }) {
  return (
    <fieldset>
      <legend>Shipping speed</legend>
      {['standard', 'express'].map((option) => {
        const id = `ship-${option}`;
        return (
          <div key={option}>
            <input
              type="radio"
              id={id}
              name="shipping"   // shared name groups the radios
              value={option}
              checked={value === option}
              onChange={(e) => onChange(e.target.value)}
            />
            <label htmlFor={id}>{option}</label>
          </div>
        );
      })}
    </fieldset>
  );
}

The <legend> becomes the group's accessible name, announced alongside each option, and the shared name is what makes the radios mutually exclusive. Associating a <label> with each option also extends the clickable target to the text — an accessibility and a target-size win at once.

• Hard-coded ids. Duplicate when a field component renders more than once, breaking label and error associations. Use useId.
• Placeholder as label. A placeholder is not a label — it vanishes on input and is poorly announced. Use a real <label>.
• Errors not tied to fields. Visible-only error text with no aria-describedby / aria-invalid. Wire them up.
• No announcement on validation. Errors that appear silently. Add role="alert" or move focus to a summary.
• Radio/checkbox groups with no <fieldset>/<legend>. Options with no group context.
• Div-and-onClick submit buttons. A form submits with a real <button type="submit">, which also enables Enter-to-submit.