Write form errors that help people finish.

1. Separate input problems from service problems

Start with the actual reason the form cannot continue. A required answer left blank is different from a server outage, an unavailable appointment, or a permission restriction. The GOV.UK Design System distinguishes errors a user can correct in their input from problems that require a different explanation and next step.

Do not keep asking someone to retype a valid email address when the service itself is unavailable. ATN suggests mapping each validation rule to a specific message and each service failure to a separate recovery state. Record which team or component determines the result so the wording does not promise an action the interface cannot support.

Sources: [2]

2. Explain the correction in plain language

Use the visible field name and describe what is needed. An original ATN example for a required subject field is “Enter a subject so we can route your message.” A vague “Invalid input” does not tell the person what to change. Avoid technical codes as the only explanation.

Where a format matters, show an example that matches the actual accepted format and any existing instruction. W3C’s form guidance recommends concise, understandable descriptions and guidance for correcting mistakes. Check that the wording does not contradict the validator: a message asking for one date format while the system expects another creates an unnecessary loop.

Sources: [1]

3. Make the affected field easy to locate

For a form with several errors, W3C describes an error list near the beginning of the form, with references to the corresponding controls. It also documents associating a field with its error text, including through aria-describedby. The relationship must be available beyond visual proximity alone.

Keep messages close enough to the relevant answer to support correction, and do not rely only on a color change. Ask the builder to verify labels, associations, and focus behavior with the tools used for the project. If an error summary includes links to fields, test those links after the form has actually produced errors, not only in an isolated design mockup.

Sources: [1]

4. Make retrying less frustrating

ATN recommends preserving appropriate non-sensitive answers after a correctable submission error so people can fix the affected field without repeating the entire form. Handle sensitive fields according to the application’s requirements rather than retaining every value indiscriminately. Be clear if something must be re-entered.

Consider the timing of validation as part of the experience. A message that appears while someone is halfway through an answer may interrupt rather than help. For the chosen interaction, test whether the person understands when checking occurs, what changed, and how to try again. Do not treat a disabled button with no explanation as an adequate error message.

5. Test correction through successful completion

Use a safe test environment or an authorized test route with ordinary sample data. Try a missing required answer and a relevant formatting error, then correct them and complete the task. Also check the service-failure state if the application supports a controlled way to simulate it.

Record the test conditions and remaining limits. This article supplies an editorial and implementation review framework; it does not certify a particular form or justify sending test submissions to an unapproved live destination.