Write form errors that help people recover
Write form errors that identify the problem, preserve input and explain recovery, with keyboard focus and server-state acceptance checks.
What should an error message help someone do?
The message should make the next action clear. “Invalid input” is too vague when the person does not know which field failed. “Enter an email address such as name@example.com” points to a recoverable problem. Network and server failures need a different explanation because editing a correct address will not repair the service.
W3C WAI’s notification tutorial recommends identifying errors and explaining how to correct them. Its labeling guidance connects controls with meaningful labels. The examples below are an editorial copy specification to test with your form, not evidence of a measured conversion uplift or complete accessibility conformance. [User notification] [Labeling controls]
A complete recoverable message set
| State | Suggested copy | Required behavior |
|---|---|---|
| Required name missing | Enter the name you want us to use. | Associate error with Name; retain other fields |
| Malformed email | Enter an email address such as name@example.com. | Focus the field after summary navigation |
| Unsupported file | Upload a supported file type listed above. | List the real permitted types and preserve the rest |
| Offline before submit | You appear to be offline. Reconnect, then try again. | Do not claim the inquiry was saved |
| Temporary server failure | We could not confirm receipt. Please try again. | Use safe retry identity when the outcome is uncertain |
| Confirmed save | Your inquiry was received. | Show the actual next step without inventing a response time |
Examples are not a replacement for the application’s actual constraints. If the server allows a particular file size, expose the verified limit in the interface. Do not invent a convenient maximum in the copy. Keep the client message and server validation consistent so users do not repair one error only to encounter an undisclosed rule.
Where should focus go after an error?
For a failed submission with several invalid fields, a concise error summary can orient the user and link to each affected control. Focus movement should make the failure discoverable without unexpectedly erasing the current task. Inline errors should remain associated with their controls, including when the field scrolls out of view.
- Submit using only the keyboard and verify the first announced context.
- Follow every summary link and confirm it reaches the correct field.
- Correct a field and verify stale error text clears appropriately.
- Resubmit and confirm valid entries remain intact.
- Check that success or failure is communicated through more than color alone.
Do not announce an error on every keystroke before the user has had a reasonable chance to finish. Some checks are best performed after a field is completed or on submit. Choose timing based on the actual interaction and test whether the resulting announcements are comprehensible rather than noisy.
Separate failed validation from uncertain delivery
A rejected value means the server did not accept that input. A lost response may mean the operation was saved but its confirmation disappeared. The recovery path should preserve that distinction. A blind fresh submission can create duplicates unless the application has an idempotent operation design.
Keep raw exception text, database details and provider credentials out of user-facing messages. The public message can be concise while the restricted diagnostic record contains the error class and recovery information. A request reference may help support, but avoid sending identifiers or form contents into public analytics.
Test the recovery, not just the wording
Use a fixture containing an empty required field, a malformed address, a temporary server error and a lost-response case. Record the text, focus position, retained values and resulting durable state. A polished sentence is incomplete if the user cannot reach the field or the retry loses their work.
Sources
AI-assisted writing and an AI-generated editorial cover. Source links and checked dates are listed below; illustrative examples are labeled in the text.
- User notification — checked 2026-10-18
- Labeling controls — checked 2026-10-18