Accessible forms: error prevention and recovery

Forms are a primary point of interaction between users and products. But they’re also where errors most often occur. For many users, especially those with cognitive impairments, low vision, or motor difficulties, unclear or inaccessible error handling can make forms unusable.

Accessible forms reduce errors through clear guidance, validation, and recovery options. They not only support compliance with WCAG but also improve confidence, trust, and completion rates for all users.

Guidelines for preventing and recovering from errors in forms.

Prevent errors before they happen

Use inline hints, examples, and constraints (like input masks) to guide users before submission. Prevention reduces frustration and abandonment.

References:

• WCAG 3.3.6: Error prevention

Validate inputs at the right time

Run validation after users complete a field, not while typing every character. Provide immediate but non-intrusive feedback.

References:

• Indicators, validations, and notifications – Nielsen Norman Group
• 10 design guidelines for reporting errors in forms – Nielsen Norman Group

Provide clear and actionable error messages

Tell users exactly what went wrong and how to fix it (“Password must include at least one number”) instead of vague phrases (“Invalid input”).

References:

• Forms that work – Caroline Jarrett & Gerry Gaffney

Keep errors close to the field

Place error text directly below or beside the field so users can fix issues without scanning the whole page.

References:

• Error identification – W3C WAI

Offer a summary of errors when needed

For long forms, include an error summary at the top with links that jump to each problematic field.

Form with error summary at the top. Red box lists multiple errors: missing ‘@’ in email and required full name. Each field also shows inline error messages

‍

References:

• Error summary – GOV.UK Design System

Allow easy recovery from mistakes

Preserve user input when reloading after errors. Never wipe data, re-entering is especially painful for users with cognitive or motor difficulties.

References:

• WCAG 3.3.4: Error prevention (legal, financial, data)

Support accessibility with ARIA attributes

Use aria-invalid="true" on fields with errors and aria-describedby to link inputs with their error messages.

References:

• ARIA Authoring Practices – W3C

Frequent mistakes in error prevention and recovery.

Showing vague or technical error codes

Using “Error 503” instead of clear instructions confuses users.

Highlighting errors only with color

Errors must have text or programmatic labels in addition to color.

Clearing all inputs after submission errors

Forces users to re-enter data and increases frustration.

Grouping multiple error messages far from fields

Users must not scan the whole page to understand which field failed.

Triggering validation too early

Overwhelms users mid-typing with unnecessary feedback.

Key takeaways for accessible error prevention and recovery.

• Prevent errors with inline hints and examples.
• Validate at the right moment, not too early, not too late.
• Use clear, actionable, accessible error messages.
• Place errors near the field, with optional summaries for long forms.
• Always preserve user input and support ARIA roles for accessibility.

Accessible error prevention and recovery transforms frustrating forms into supportive, inclusive experiences.

Scenario 1: Preventing errors before they happen

Use when designing forms where users frequently make avoidable mistakes: payment fields, address inputs, date fields, or any field with strict formatting requirements.

You are a UX-focused design agent. Design error prevention for a [form type: payment / registration / address / event booking] form.

Rules:
- Show formatting requirements as helper text beneath each field before the user types:
  Date: "Format: DD/MM/YYYY"
  Phone: "Include country code — e.g. +1 555 000 0000"
  Password: "At least 8 characters, one number, one special character"
- Helper text must be visible by default — never hidden in a tooltip
- Use input masks for structured fields: auto-insert spaces in card numbers, dashes in phone numbers
  Input masks must format — never delete — user input
- Use HTML input constraints: type="email", type="tel", maxlength, min/max, pattern
- For sensitive fields, explain why you need the data:
  "We need your date of birth to verify your age"
- Show live character count for fields with a limit
- Pre-fill where possible (country from locale, state from postal code) — label pre-filled values clearly

Accessibility:
- All helper text associated with its field via aria-describedby
- Character counters: aria-live="polite" so updates are announced

Constraints:
- Never hide formatting hints in tooltips — users may never see them
- Never use input masks that delete characters the user has typed
- Never pre-fill passwords or payment details

Scenario 2: Helping users recover from errors

Use when validation has run and one or more fields have failed: the focus shifts from prevention to guiding the user to fix mistakes as quickly as possible.

You are a UX-focused design agent. Design the error recovery experience for a [form type] form that has just failed validation.

Rules:
- Show all errors simultaneously on submit — never reveal them one at a time
- Error summary at the top of the form for 3+ errors:
  Heading: "Please fix [N] errors before continuing"
  Each item: a link that scrolls to and focuses the affected field
  The summary receives keyboard focus when it appears
- Inline error at each field:
  Red border + error icon + specific message directly below the field
  Format: what went wrong + how to fix it
  ✓ "Password must be at least 8 characters — add 3 more"
  ✗ "Invalid password"
- Never clear valid field values when showing errors
- Clear each field's error as soon as the user corrects it on next blur
- aria-invalid="true" on all invalid fields; remove when corrected

Error copy per failure type:
- Empty required field: "Please enter your [field name]"
- Wrong format: "Enter a valid [field name] — for example, [example]"
- Out of range: "[Field name] must be between [min] and [max]"
- Duplicate: "This [field name] is already in use"

Accessibility:
- Error summary: role="alert" or tabindex="-1" to receive programmatic focus
- Each inline error: aria-describedby on the input
- aria-invalid="true" on invalid fields, removed on correction

Constraints:
- Never reveal errors one at a time
- Never clear valid user input when showing errors
- Never write messages that blame the user ("You entered an invalid email")
- Never place the error summary only at the bottom