Interface Lab
Back to knowledge
Interaction Responsive Motion

Transactional Form Error Recovery

Error handling in high-trust forms is not about telling users they are wrong. It returns them to a recoverable state where they can continue without re-entering information.

Design Principle

Transactional service error recovery must handle visual placement, screen readers, focus, original input, error copy, and next action together.

Large Theory

Form errors are part of the user path, not exceptional popups. The higher the trust requirement in public services, finance, healthcare, compliance, or application flows, the more error recovery should become a stable loop: identify the problem, explain why, locate the field, preserve input, allow correction, and continue.

Small Points

  1. Show an error summary at the top of the page even when there is only one error.
  2. Each error summary link points to the related field, and the field displays a matching local error message.
  3. The page title includes error state so screen readers announce failure as early as possible; NHS and GOV.UK patterns both treat title state as part of recovery.
  4. Preserve user-entered values after failure, reducing WCAG Redundant Entry risk.
  5. Avoid validating on blur by default; usually validate after continue or submit so slow typists are not interrupted repeatedly.
  6. Do not rely on browser-native HTML5 validation as the accessible error pattern.
  7. Date, radio, checkbox, and address groups need a connected error anchor, legend, hint, error message, and first editable control.
  8. Healthcare, identity, and eligibility error copy should name the fix, and summary text should match inline field text.

Design Judgment

Error recovery is healthy when users can move from the top summary to the field, understand how to fix it, see what they originally entered, and continue. It fails when errors are only red borders, values are cleared, or focus lands in an unknown place.

Implementation Notes

On failed submit: disable native HTML5 validation, still validate server-side, update the document title, render an error summary, move focus to it, connect aria-describedby to hint/error text, and preserve field values. Write specific error copy instead of generic invalid-input text. On mobile, verify that errored fields are not covered by sticky headers, bottom submit bars, or the keyboard.

Counterexamples/Risks

Only showing a toast, only turning borders red, clearing the form, mismatching summary and field messages, links that do not reach fields, real-time validation that interrupts slow typists, and date groups where only the outer div is marked invalid while inputs lack labels or descriptions.

Case Study

GOV.UK Design System's Error summary guidance says to always show an error summary for validation errors and move keyboard focus to it. Its validation pattern says to show the page again with the user's values, add error state to the title, show top error summary and field-level messages, and turn off HTML5 validation. The NHS digital service manual adds healthcare-service context: the summary links to each affected answer, inline fields show matching errors, error messages explain the problem and fix, and entered information is preserved. The reusable lesson is that error recovery is a coordinated system, not one red component.

Source Links

GOV.UK Error summary: https://design-system.service.gov.uk/components/error-summary/ GOV.UK Validation pattern: https://design-system.service.gov.uk/patterns/validation/ GOV.UK Error message: https://design-system.service.gov.uk/components/error-message/ NHS Error summary: https://service-manual.nhs.uk/design-system/components/error-summary NHS Error message: https://service-manual.nhs.uk/design-system/components/error-message NHS Design system: https://service-manual.nhs.uk/design-system

Agent Directive

For high-trust forms, design error summary, field errors, focus movement, preserved input, specific copy, and submit timing; do not express errors only through toast or red borders.