Guide

Accessible forms: labels, errors, and structure

Last updated: 29 June 2026

Forms are where accessibility problems hurt most — they're the checkout, the sign-up, the contact page, the thing standing between a user and what they came for. A form that a screen-reader or keyboard user can't complete is a lost customer and a clear WCAG failure. The good news: accessible forms come down to a handful of reliable habits.

1. Every field needs a real, associated label

Use a <label> tied to its input with for and id (or wrap the input in the label). This is the single most important rule — without it, a screen reader can't tell the user what a field is for (WCAG 1.3.1, 4.1.2). Placeholder text is not a label: it disappears when typing and is often too low-contrast. Visible labels also give everyone a bigger click target.

2. Don't rely on placeholders or color alone

Placeholders should only be examples ("e.g. jane@company.com"), never the field's name. And don't mark required fields or errors with color only — add text or an icon too, so color-blind users get the message (WCAG 1.4.1). Spell out "(required)" rather than relying on a red asterisk by itself.

3. Make errors clear and programmatic

  • Say what's wrong and how to fix it — "Enter a valid email like name@example.com," not just "Invalid" (WCAG 3.3.1, 3.3.3).
  • Put the message next to the field, and connect it to the input with aria-describedby so screen readers announce it.
  • Mark invalid fields with aria-invalid="true".
  • Move focus to the first error (or a summary) on submit so keyboard users aren't left guessing.

4. Group and structure related fields

Use <fieldset> + <legend> for groups like a set of radio buttons or an address block, so the group's purpose is announced. Use proper input types (type="email", type="tel") and autocomplete attributes — they help everyone, and autocomplete on common fields is a WCAG 1.3.5 requirement.

5. Keyboard + focus

Every control must be reachable and operable by keyboard, in a logical order, with a visible focus ring. Custom controls (date pickers, comboboxes) need real keyboard support and ARIA — or use native HTML elements, which give you all of this for free. See keyboard accessibility testing.

Quick checklist

  • Every input has a visible, associated <label>.
  • Required state and errors use text/icons, not color alone.
  • Errors are specific, beside the field, and linked with aria-describedby.
  • Related fields grouped with fieldset/legend.
  • Correct input types + autocomplete.
  • Fully keyboard-operable with visible focus.

How to check your forms

An automated scan reliably catches the big ones — inputs with no label, missing accessible names, fields with no programmatic association. Scan your site free with WCAGwise to find them and the exact elements, then manually tab through the form and trigger an error to confirm the experience. WCAGwise is an audit aid, not a legal guarantee.

Related guides