Describe what failed, its effect, and a concrete next action.
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.
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.
- After failed validation, use a linked error summary when it helps users find errors. Focus the summary or the first invalid field, as appropriate for the form.
- 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 a user find and understand the error, hear dynamic recovery feedback, and continue without losing work or risking a duplicate transaction?