Sources take different approaches
GOV.UK says to show and focus an error summary even for one validation error and directs permission, eligibility and service failures to explanatory pages. WCAG requires input errors to be identified and described in text, with known correction suggestions when safe. It does not prescribe that summary or page layout. This guide follows WCAG and chooses presentation according to the task.
Preferred source: WCAG 2.2 · Error identification (3.3.1). Use WCAG 3.3.1, 3.3.3 and 4.1.3 as the basis for error identification, safe correction suggestions and dynamic status feedback. GOV.UK’s always-show-a-summary rule is a design-system convention. Inline messages, summaries and explanatory pages remain contextual choices.
Compare: GOV.UK · Error summaries for validation · GOV.UK · Field errors and service failures. How we choose sources.
Recommendation
Explain what failed and how to recover. For detected input errors, identify the affected field and describe the problem in text; provide a known correction when safe. Choose presentation for the task: WCAG does not require an error summary for every error.
Problem
Something failed and the user needs a way forward.
Show an error message when
- The user can fix input, retry an operation, or choose another route.
- A service failure needs a persistent explanation separate from field errors.
Error-message mistakes to avoid
- Blaming users for an infrastructure problem.
- Showing a generic error code as the only explanation or retrying a payment blindly.
What WCAG requires
These requirements describe the result users need. They do not prescribe a single error-summary component or a separate page for every failure.
- Error identification (3.3.1, Level A): identify the input with an automatically detected error and describe the error in text. Colour or an icon alone is not enough.
- Error suggestions (3.3.3, Level AA): provide known suggestions for correcting an input error, unless that would jeopardize security or the purpose of the content.
- Status messages (4.1.3, Level AA): make dynamic status messages available to assistive technology through appropriate roles or properties when they are presented without a change of context.
Choose placement for the problem
Our implementation recommendation is to keep the explanation close to the problem and use a summary when it helps people find errors. These are presentation choices, not additional WCAG requirements.
- For a clear, local input error, put the message beside the affected field and associate it programmatically with that field.
- For multiple errors or a long form, consider a linked summary so people can find the affected fields. Choose useful focus management for the form.
- For permission or service failures, explain the blocked action separately from field-format errors. Use a persistent form-level message, or an explanatory page when the task cannot continue. Do not ask users to change valid input to fix a service problem.
Example
Couldn’t load your projects
Your saved projects have not been changed. Try loading them again.
Projects loaded in demo
- Website redesign
- Research notes
No request was sent to a server.
Implementation
- Preserve entered data. Distinguish a rejected request from an unknown outcome: a timeout does not prove that a write failed.
- Identify input errors in text and give a known correction when safe to disclose. Associate inline errors with their inputs, for example using aria-describedby.
- Use a linked error summary when it helps users find errors, such as in a long form. Focus the summary or the first invalid field as appropriate. WCAG does not require an always-present summary or one specific focus target.
- Keep service failures separate from invalid input. Expose dynamic recovery messages through an appropriate live region when focus stays in place; use role="status" for routine completion feedback.
- Offer retry only when repeating the operation is safe. For an unknown transaction outcome, check its status or offer a support route before suggesting another attempt.
Tradeoffs
More detail helps only when it supports recovery. Keep internal diagnostics out of the main message while retaining a reference users can share with support.
Verification
Can users identify the affected input and understand its error in text, get a known correction when safe, and perceive dynamic status feedback? Can they recover without losing work or risking a duplicate transaction?
References
- WCAG 2.2 · Error identification (3.3.1, Level A)
- WCAG 2.2 · Error suggestion (3.3.3, Level AA)
- WCAG 2.2 · Status messages (4.1.3, Level AA)
- GOV.UK · Error summaries for validation
- GOV.UK · Field errors and service failures
- W3C · Error identification (WCAG 3.3.1)
- W3C · Error suggestions (WCAG 3.3.3)
- W3C · Dynamic status messages (WCAG 4.1.3)
- IETF · HTTP retry and idempotency semantics