Accessible Forms: Labels, Errors, Validation

Core principles (what "good" looks like)

• All inputs have clear labels (programmatically, not just visually).

• Instructions come first before the field; it's clear which fields are required.

• Validation timing is considerate (when leaving a field or on submit, not on every keystroke).

• Errors are specific, friendly, and associated with the fields.

• Focus moves to the first error; messages are communicated to assistive technologies.

• Keyboard access and visible focus are ensured everywhere.

Labels & associations

• Use <label for="id"> for single inputs.

• Group related controls (radio/checkbox sets) with <fieldset><legend>.

• Place helper text before the input or associate it via aria-describedby.

Example: single input with helper text

<label for="email">Email address</label>
<p id="email-hint">We’ll send your receipt here.</p>
<input id="email" name="email" type="email" autocomplete="email" aria-describedby="email-hint"

Example: radio group

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

Do not replace labels with placeholders; placeholders vanish on entry and may not have enough contrast with many themes.

Required fields & instructions

• Indicate which fields are required in the label (e.g., “Email address (required)”) or provide a note at the legend level.

• Don't use asterisks without explanation.

• Provide format tips upfront (e.g., “U.S. ZIP code, e.g., 90210”).

Validation timing (be considerate)

• Validate on exit from the field and on submit—don’t hinder typing.

• Avoid real-time, per-keystroke corrections.

• Don’t allow submission if data is invalid, then focus on the first error.

Error messages & announcements

• Be specific and actionable (“Please enter a valid email, such as name@domain.com”).

• Link the message to the input with aria-describedby.

• Create a polite live region for errors that appear dynamically.

Example: error pattern

<form aria-describedby="form-errors" novalidate>
  <div id="form-errors" aria-live="polite"></div>

  <label for="email">Email address</label>
  <span id="email-error" class="error" hidden>Enter a valid email like name@domain.com</span>
  <input id="email" name="email" type="email" autocomplete="email"
         aria-describedby="email-error" aria-invalid="true">
</form>

When an error is shown, remove hidden, set aria-invalid="true", and direct focus to the first erroneous field or a summary error panel that links back to the respective fields.

Autocomplete, input modes & helpful defaults

• Utilize autocomplete to expedite input: name, email, tel, address-line1, postal-code, cc-number, etc.

• On mobile, apply input modes: type="email", type="tel", inputmode="numeric" as needed.

• Prefill useful defaults and keep user input when a submit fails.

Keyboard, focus & sequencing

• Tab order matches the visual order; avoid hidden focus traps.

• Focus is always visible on inputs, buttons, and custom controls.

• When modals or inline steppers contain form content, trap focus within and restore it upon closure.

Contrast & hit areas

• Labels, inputs, and errors meet AA contrast requirements (including placeholder text).

• Tap targets are comfortable on mobile; space adequately to prevent accidental touches.

Pattern library (copy/paste)

Accessible inline error (JS snippet)

function showError(input, message) {
  const id = input.id;
  const err = document.getElementById(`${id}-error`);
  if (err) {
    err.textContent = message;
    err.hidden = false;
    input.setAttribute('aria-invalid', 'true');
    input.setAttribute('aria-describedby', `${id}-error`);
  }
}

function clearError(input) {
  const id = input.id;
  const err = document.getElementById(`${id}-error`);
  if (err) {
    err.hidden = true;
    input.removeAttribute('aria-invalid');
    input.removeAttribute('aria-describedby');
  }
}

Error summary linking to fields

<div id="error-summary" aria-live="polite" role="alert">
  <p><strong>There’s a problem</strong></p>
  <ul>
    <li><a href="#email">Enter a valid email address</a></li>
    <li><a href="#postcode">Enter a UK postcode, e.g., SW1A 1AA</a></li>
  </ul>
</div>

Copy-paste checklist (Markdown)

- [ ] Each input has a <label for="…">; groups use <fieldset><legend>

Quick QA routine (10 minutes)

1. Keyboard pass: Tab through every control; try submitting an empty form; verify focus and messages.

2. Screen reader overview: Ensure labels are read correctly; errors are announced; summary links are functional.

3. Mobile check: Validate input modes, touch target sizes, and autocorrect behavior.

4. Edge cases: Interplay of required and optional fields, ZIP code/email formatting, international inputs.

How Adjustable helps

Once forms are structurally sound, Adjustable assists more people in completing them:

• Text-size and contrast options enhance readability and reduce errors.

• Reading aids and motion preferences help ease fatigue during lengthy forms.

• Simple installation and visible inclusivity—perfect for Marketing Managers and Website Owners.

Try Adjustable

FAQs

Do placeholders replace labels?
No. Placeholders disappear and aren’t always announced correctly. Ensure there’s always a visible, programmatic label.

When should validation run?
Upon blur for a gentle prompt, and on submit to catch everything. Avoid per-keystroke errors.

How do I announce errors?
Tie messages to fields via aria-describedby, set aria-invalid="true", and utilize a polite live region or an error summary with links.

What about multi-step forms or modals?
Move focus into the step or dialog, trap focus while open, and bring it back to the trigger on closure. Maintain state between steps.

Next steps

• Audit your top lead/checkout forms against the checklist above.

• Implement the error pattern and summary components throughout your templates.

• Add Adjustable to support visitors needing higher contrast or larger text.

• Read next: Keyboard-Only Navigation, Color Contrast Made Simple, WCAG 2.2 AA Checklist.