What the person is doing
The form can fail after submit, cross-field validation, or server validation.
Foundation · lesson 1 of 23 · Error Prevention And Recovery
Error summary
Underlying principle: Recovery begins before the error. Clear consequences, suitable constraints, preserved work, and a visible correction path reduce the cost of a mistake.
Show a focused summary near the form heading with a clear title and linked error messages, then repeat matching messages at the affected fields.
Study the interaction
Follow the task before choosing the component
Recovery begins before the error. Clear consequences, suitable constraints, preserved work, and a visible correction path reduce the cost of a mistake.
What the interface must communicate
Show a focused summary near the form heading with a clear title and linked error messages, then repeat matching messages at the affected fields.
Failed-submit state with summary visible near the form heading.
What to look for
Do summary links land on the same fields whose messages repeat the correction?
The summary appears after failed submit where keyboard and screen-reader users can perceive it.
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
- The message is a system failure, permission problem, or outage rather than a validation issue.
Problem it prevents
The form can fail after submit, cross-field validation, or server validation.
Test the behavior
Try strong and weak versions of the interaction
Open the working example, try its controls, and compare the behavior against the decision guidance.
In the lab you can
Launch Error summary in the lab - 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.
Pattern anatomy
What a strong implementation has to make clear
The form can fail after submit, cross-field validation, or server validation.
Show a focused summary near the form heading with a clear title and linked error messages, then repeat matching messages at the affected fields.
Failed-submit state with summary visible near the form heading.
Dead links to missing or hidden fields.
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
- Summary and field messages visually disconnected or contradictory.
- Only showing errors below the fold.
- Replacing field-level guidance with only a top summary.
- Dead links to missing or hidden fields.
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
- 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
- Do summary links land on the same fields whose messages repeat the correction?
Evidence trail
Source-backed claims behind this guidance
GOV.UK Design System Error summary component
Government Digital Service - checked
GOV.UK error summary guidance requires a top-of-page summary, keyboard focus, linked error items, and matching field messages.
GOV.UK Design System Error message component
Government Digital Service - checked
GOV.UK error message guidance supports the paired field-level messages that remain beside each invalid answer.
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: