Accessible Error Recovery

Last updated:

Error recovery affects accessibility and usability directly — recovery should reduce stress.

01 — Purpose

Recovery shapes trust after failure

Error recovery affects accessibility and usability directly — vague failures erode confidence fast.

When something goes wrong, users need to understand what happened, what to do next, and whether their work is still there. Poor recovery hits assistive technology users hardest — silent errors, lost form data, and colour-only status are common failure modes.

Align with accessible forms, error states, and retry patterns.

02 — Principles

Recovery should reduce stress

Clear messaging, accessible validation, and preserved input.

  • clear messaging — say what failed and how to fix it in plain language
  • accessible validation — error summary, field errors, aria-invalid, and aria-describedby
  • preserved form state — do not wipe fields on validation failure
  • announce errors for screen reader users — role="alert" or focus to summary — see live regions

03 — Practice

Good recovery UX

Users should leave an error state knowing what to do — not guessing.

  • same error text in summary and beside the field — GOV.UK-style consistency
  • move focus to the error summary on submit failure when multiple fields fail
  • offer retry only when it is safe — network blips yes, validation errors no
  • keep destructive actions reversible where possible — see undo and restore

04 — Avoid

Recovery that blocks people

Vague errors, lost input, and colour-only feedback fail everyone — especially under stress.

  • vague errors — “Invalid input”, “Error”, “Something went wrong”
  • losing user input — clearing the form after a failed POST
  • colour-only messaging — red border with no text or programmatic name
  • errors only in toasts — see toast notifications (last resort)

05 — Close

Recovery should reduce stress

A failed form should feel fixable — not like starting over.

Test error paths with keyboard and a screen reader: submit empty forms, trigger server errors, and confirm focus and announcements match the visual message.

See confirmation, loading states, and accessibility QA checklist.