Accessible forms: labels, errors and validation

Forms are where accessibility turns into revenue, applications and appointments — or into lost customers and lawsuits. Checkout, sign-up, booking and contact forms are the flows plaintiffs’ testers try first.

1. Every field needs a visible, connected label

<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email">

• The for attribute matches the input’s id, so clicking the label focuses the field and screen readers announce it.
• Placeholder text is not a label. It disappears when you type, usually has poor contrast, and isn’t reliably announced.

2. Group related fields

Radio buttons and checkbox groups need a group label:

<fieldset>
  <legend>Preferred contact method</legend>
  <input type="radio" id="c-email" name="contact" value="email">
  <label for="c-email">Email</label>
  <input type="radio" id="c-phone" name="contact" value="phone">
  <label for="c-phone">Phone</label>
</fieldset>

3. Mark required fields in text

Say which fields are required in a way that doesn’t depend on color, and use the required attribute so assistive technology announces it:

<label for="name">Full name <span aria-hidden="true">*</span>
  <span class="sr-only">(required)</span></label>
<input id="name" name="name" required autocomplete="name">

Explain the asterisk at the top of the form: “Fields marked * are required.”

4. Give hints before the field, not after the error

<label for="dob">Date of birth</label>
<span id="dob-hint" class="hint">For example, 03/27/1985</span>
<input id="dob" name="dob" aria-describedby="dob-hint" inputmode="numeric">

5. Write error messages that help

Bad: “Invalid input.” Good: “Enter a date of birth in the format MM/DD/YYYY.”

Each error should:

• appear next to the field, in text (not just a red border),
• be connected with aria-describedby,
• set aria-invalid="true" on the field,
• say what’s wrong and how to fix it.

<input id="email" aria-invalid="true" aria-describedby="email-error">
<p id="email-error" class="field-error">Enter an email address like name@example.com</p>

6. Add an error summary for long forms

When a form is submitted with errors, show a summary at the top, move focus to it, and link each item to the field. Our own contact form works this way.

7. Use autocomplete

autocomplete="name", "email", "tel", "street-address", "postal-code" let browsers and password managers fill fields — essential for people with motor and cognitive disabilities, and required by WCAG 1.3.5.

8. Don’t make login a puzzle

WCAG 2.2’s Accessible Authentication criterion (3.3.8) means users shouldn’t have to memorize, transcribe or solve something to log in unless there’s an alternative. Allow paste in password and code fields, support password managers, and offer passkeys, email links or other alternatives to puzzle CAPTCHAs.

9. Don’t ask twice

If the user already gave you their address, pre-fill it or offer “Same as billing” (WCAG 3.3.7 Redundant Entry).

10. Confirm success out loud

After submission, announce the result with a live region or move focus to a confirmation heading, so screen reader users know it worked.