UX Patterns Guide
UI + UX Error Prevention And Recovery standard

Error summary

Show a focused summary near the form heading with a clear title and linked error messages, then repeat matching messages at the affected fields.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Form submission can produce one or more errors.
  • Errors may appear outside the current viewport or across multiple form sections.

Avoid when

  • A single local field issue can be corrected before submit without page-level orientation.
  • The message is a system failure, permission problem, or outage rather than a validation issue.

Problem it prevents

Users submit a page or step with validation errors and need an immediate overview plus a route to each answer that must be fixed.

Test the behavior

Open the interactive example when you need it

The full lab is intentionally loaded on request. That keeps this reading page fast while preserving the strong and weak states, keyboard checks, and failure scenarios.

In the lab you can
  • switch between strong UI, weak UI, strong UX, and weak UX;
  • trigger required, empty, loading, error, and recovery states;
  • inspect keyboard and accessibility expectations beside the demo.
Launch Error summary in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

The form can fail after submit, cross-field validation, or server validation.

Pattern promise

Show a focused summary near the form heading with a clear title and linked error messages, then repeat matching messages at the affected fields.

Required state

Neutral form before submit with no summary.

Recovery path

Dead links to missing or hidden fields.

Access contract

Use a heading and alert behavior that makes the summary discoverable.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • Top-of-form summary with a clear heading, linked error list, and matching inline field messages.
  • Each error link text names the correction and visually matches the message at the affected field.
  • After failed submit, focus or reading order makes the summary discoverable before users scan the form.
  • Choosing a summary item moves to the relevant field while preserving the submitted values.
Weak implementation

Vague, hidden, hard to recover from

  • Red banner saying fix errors with no links.
  • Summary and field messages visually disconnected or contradictory.
  • Only showing errors below the fold.
  • Replacing field-level guidance with only a top summary.
UI guidance
  • Render a top-of-form summary block with heading, linked error list, and matching field-level error messages.
  • Place the summary near the form heading after failed submit, not as an unrelated toast or detached banner.
UX guidance
  • Help users recover from one or more submitted-form errors without scanning the entire page.
  • Move users from the summary to the exact field, group, or first invalid control that needs correction.
Implementation contract

What the implementation must handle

States

  • Neutral form before submit with no summary.
  • Failed-submit state with summary visible near the form heading.
  • Summary-link navigation to the affected field or first invalid grouped input.
  • Corrected form state with the summary removed or replaced by a success outcome.

Interaction

  • The summary appears after failed submit where keyboard and screen-reader users can perceive it.
  • Each summary item names one error and moves focus or scroll position to the relevant answer.
  • Field messages and summary messages use the same correction wording.

Accessibility

  • Use a heading and alert behavior that makes the summary discoverable.
  • Link summary items to fields with stable focus targets.
  • Keep the summary text and field error text consistent for screen-reader and visual users.
  • Focus can move to the summary after failed submit.

Review

  • Can users recover from the first failed submit without scanning the full page?
  • Do summary links land on the same fields whose messages repeat the correction?
Evidence trail

Source-backed claims behind this guidance

Full agent/debug reference

Problem Context

  • The form can fail after submit, cross-field validation, or server validation.
  • Errors may be below the fold, spread across sections, or easy to miss when focus remains on the submit control.

Selection Rules

  • Choose an error summary when submit-time validation can leave one or more errors across a page or step.
  • Link each summary item to the exact field, first invalid field in a group, or section that contains the failing answer.
  • Keep summary wording consistent with field-level messages so the user does not have to reconcile two explanations.

Required States

  • Neutral form before submit with no summary.
  • Failed-submit state with summary visible near the form heading.
  • Summary-link navigation to the affected field or first invalid grouped input.
  • Corrected form state with the summary removed or replaced by a success outcome.

Interaction Contract

  • The summary appears after failed submit where keyboard and screen-reader users can perceive it.
  • Each summary item names one error and moves focus or scroll position to the relevant answer.
  • Field messages and summary messages use the same correction wording.

Implementation Checklist

  • Place the summary near the form heading before the fields that contain errors.
  • Move focus to the summary after failed submit unless the platform has an equivalent announcement pattern.
  • Link each summary message to the field, group, or first invalid subfield it describes.
  • Keep entered values intact so users can edit rather than start again.
  • Repeat matching field-level error messages at the affected controls.

Common Generated-UI Mistakes

  • Showing a red banner or toast with no links to the invalid answers.
  • Replacing field-level messages with only a top-level summary.
  • Using vague summary messages that do not identify the answer or correction.

Critique Questions

  • Can users recover from the first failed submit without scanning the full page?
  • Do summary links land on the same fields whose messages repeat the correction?
Accessibility
  • Use a heading and alert behavior that makes the summary discoverable.
  • Link summary items to fields with stable focus targets.
  • Keep the summary text and field error text consistent for screen-reader and visual users.
Keyboard Behavior
  • Focus can move to the summary after failed submit.
  • Summary links move focus to the affected field, fieldset, or first invalid grouped control.
  • Tab order continues from the summary into the form without trapping the user.
Variants
  • Page-level summary
  • Step-level summary
  • Server validation summary
  • Grouped-field summary link

Verification

Source trail checked:

Saved items