Form Error Messages: Help People Recover Without Starting Again

Can someone recover the intended task?

The form says “Something went wrong.” The fields are empty again. The person who just completed them now has two problems: recovering their work and discovering what failed.

An error message belongs to a recovery path. To review it, follow what a person can understand, correct and resume after the interruption. The sentence matters, along with the data retained, the location of the problem and the next available action.

Start with the failure the person encounters

Consider an invented supplier-registration form. It asks for a company name, work email and delivery address. Two failures can interrupt submission:

• A required postcode is missing.
• The service cannot confirm whether a submitted registration was saved.

Those situations need different recovery paths. In the first, the person can supply information. In the second, the interface needs to represent uncertainty about an operation. Asking them to “correct your details” would point them toward a remedy that may have nothing to do with the failure.

Review the state of the operation before choosing the copy. What is known? What remains uncertain? What can the person safely do next?

Use established guidance for the interaction

W3C's forms guidance covers notifying people about errors and helping them correct submissions. GOV.UK's Design System provides a specific pattern that combines an error summary with errors beside affected inputs. Its summary links people to the relevant fields, while the field message explains the issue and the correction. W3C user notifications, GOV.UK error summary, GOV.UK error message.

Use those sources as references for an implementation and its review. The GOV.UK pattern is a documented design-system approach; copying its appearance does not by itself establish accessibility or suitability for every form.

Review the missing-postcode case end to end

For the fictional form, a review might propose:

Summary: There is a problem. Linked item: Enter a delivery postcode. Field message: Enter a delivery postcode.

The wording has a job: identify the missing information and the next action. Now inspect whether the rest of the interaction supports it.

Does the previously entered company name remain? Does activating the summary link take the person to the relevant input? Is the relationship between the field and its message available to assistive technology? Can the person reach, understand and correct the issue using a keyboard?

A static mockup cannot answer all those questions. Keep them in the implementation review and verify them in the working flow. A message can be clear while its focus behavior or programmatic association prevents someone from using it.

Review the uncertain-submission case differently

Suppose the service times out after the person presses Submit. The interface does not yet know whether the registration was saved.

Before writing “Try again,” ask engineering what a retry does. Could it create a second registration? Is there a request identifier or status check? Can the application recover a confirmed result? What should happen while the answer remains unknown?

An illustrative message might say:

We could not confirm whether your registration was saved. Check its status before submitting again.

That copy is appropriate only if a usable status-check path exists. If the system cannot support it, the team needs another recovery design. A reassuring sentence cannot supply a capability the service lacks.

The same review should cover what information remains available while the status is checked, how long the state persists and where a person can obtain help if the uncertainty continues.

Keep a small recovery table beside the design

The table is an original review aid. It is not a complete accessibility checklist. Its purpose is to stop several different system states collapsing into one generic error.

Agree on the evidence before closing the review

For each state, record how it will be reproduced and who will verify it. A required-field error can be triggered with a missing value. A timeout may need a controlled test environment. Do not rely on a production failure occurring during a demonstration.

Review the flow with keyboard and relevant assistive-technology checks, inspect the retained information, and confirm that the proposed next action works. Where user understanding remains uncertain, make that a research question rather than marking the copy as settled because the team likes it.

The next design discussion becomes more concrete: “Can someone recover their intended task after this failure, with the information and controls we actually provide?”