Form error messages design: say what went wrong and how to fix it
A useful form error message sits next to the field it belongs to, says in plain words what went wrong and how to put it right, and doesn't rely on colour alone. Keep what the person typed, list the errors at the top when there are several, and check the message reads well aloud, because some visitors will only ever hear it.
What the accessibility rules ask
Two WCAG criteria cover most of this. Error Identification, at level A, says that when a form detects a mistake, it has to identify the field in error and describe the problem in text. Re-showing the form with a red outline and no words fails it. Error Suggestion, at level AA, goes a step further: when the form knows how the entry could be fixed, it should say so, unless that would undermine security. "Email is not valid" identifies the error; "Enter an email address like name@example.com" also suggests the fix.
Wording that helps
The GOV.UK Design System's error message guidance is one of the most tested sets of rules for this, and it's worth reading in full. The core of it: say what happened and how to fix it, reuse the words from the field's label, use an instruction for a missing answer and a description for a wrong one, and avoid words that blame or alarm.
| Instead of | Write | Why |
|---|---|---|
| This field is required | Enter your phone number | Names the field and the action |
| Invalid input | Enter a date in the past, like 14 3 1990 | Says what kind of answer works |
| Oops, something went wrong | Choose a time between 9am and 5pm | Specific beats friendly |
| Illegal characters | Postcode must only include letters and numbers | No blame, just the rule |
| Error 422 | Message must be 2,000 characters or fewer | No codes the visitor can't act on |
Read each message aloud. If it sounds like something a helpful person at a counter would say, it's probably right. Drop "please", "sorry" and jokes; they add length without adding information.
Where errors appear
- Next to the field, between the label and the input, so it's read before the person starts typing again. Below the field is common too, but on a phone it can be hidden by the keyboard.
- In a summary at the top when the form has more than a couple of fields, listing each error as a link that moves focus to the field. Move focus to the summary when the page reloads with errors.
- With more than colour. Pair a red border with an icon and the text itself, so people who can't tell red from grey still see it.
- Connected in code. Reference the message from the input with
aria-describedbyand mark the field witharia-invalid="true", so a screen reader announces the problem when the field gets focus.
When to validate
Inline form validation as someone types sounds helpful but often isn't. An email field that turns red after the first letter is telling people they're wrong before they've finished. A calmer rule of thumb:
- Validate a field when the person leaves it, and only if they've typed something.
- Clear the error as soon as the entry becomes valid, while they're still in the field.
- Validate everything again when the form is sent, on the server as well as in the browser, since browser checks are easy to skip.
- Never wipe what someone typed because one field was wrong.
Prevention is better than any message. Mark optional fields rather than required ones when most are required, show the expected format in hint text before anyone gets it wrong, and use the right input type so the keyboard matches the answer. Web form design best practices and mobile form design cover those choices.
How Anticode handles form errors
Anticode's built-in contact, booking and newsletter forms have fixed fields, each with a label, a type and a length limit, and Sentinel checks every build for exactly that: typed, length-capped fields and a label on each one. Because design-engine pages run no scripts, the check before sending is the browser's own: a required field left empty or an email without an @ is stopped by the browser, in its own words, before anything is sent.
For rules of your own, a custom form tied to a site function can refuse a submission with a message you write, such as "We only deliver to postcodes starting EH". That message is shown on the page the visitor lands on after sending, so word it with the same care as an inline error: say what was wrong and what to change when they go back to the form.
Questions people ask
Is a red border enough to show a form error?
No. WCAG requires the error to be described in text. Colour can support the message, but not replace it.
Should errors go above or below the field?
Either can work. Placing the message between the label and the input means it's read first and isn't hidden by a phone keyboard.
Should forms validate as you type?
Usually not. Validate when the person leaves a field, clear the error as soon as it's fixed, and check everything again when the form is sent.