The Second Sentence: A 2026 Audit of UK Form Errors That Announce but Do Not Explain
The red outline is only the beginning
A form error has two jobs. The first is to be noticed. The second is to be useful. UK teams have become measurably better at the first job: error summaries, aria-live regions and red borders are now common in public-sector and commercial services alike. The second job remains uneven. A message can be announced perfectly and still leave the user staring at the field, unsure whether the fault lies with their postcode, their surname, their browser or their right to use the service at all.
This audit treats validation as a recovery journey rather than a detection event. It asks not simply whether an error is announced, but whether the wording explains the problem, avoids blame, moves focus sensibly, survives scrolling and gives the user a credible next step. The method is deliberately light enough for a UK product team to run in a sprint, and rigorous enough to produce evidence rather than opinion.
A rubric for recovery, not just detection
Score each visible error against six criteria. Give 0, 1 or 2 points for each, producing a maximum of 12.
| Criterion | 0 points | 1 point | 2 points |
|---|---|---|---|
| Clarity | The message is a code or generic verdict | It names the field but not the fix | It states the problem and the expected format in plain English |
| Ownership | It blames the user | It is neutral but impersonal | It uses calm, service-owned language such as We could not check this postcode |
| Focus | Focus stays where it was | Focus moves to the field but not the summary | Focus moves to a summary that links to the field, or to the field with clear context |
| Persistence | The message disappears on scroll or blur | The message remains but is visually detached | The message stays adjacent to the field and is repeated in the summary |
| Recovery | No next step is given | A next step is implied | A specific, achievable next step is offered |
| Consistency | The message contradicts the label or hint | The message is consistent but repeats developer language | The message, label and hint form one coherent instruction |
A score below 8 is a recovery failure even if the error is technically accessible. A score of 10 or above is a reasonable baseline for a UK service that expects repeat use under pressure.
Test one: the vague verdict
A common failure is the error that announces itself and then says almost nothing. A checkout field for a UK postcode displays Invalid input. The user has typed SW1A 1AA with a trailing space, or has entered a partial postcode, or has used a format the service did not expect. The message treats all three as the same offence.
A better rewrite separates the problem from the person: Enter a full UK postcode, for example SW1A 1AA. We could not check this one because it is incomplete. The second sentence does the work. It says what happened, avoids accusing the user and gives a model answer. For a commercial checkout, the same discipline applies: We could not verify this postcode. Check that it includes both parts, for example SW1A 1AA.
The audit test is simple. Ask five UK participants to correct the error without assistance. If any participant asks what the message means, the second sentence has failed.
Test two: the vanishing message
Errors that disappear on scroll are a persistent fault in long forms, particularly on mobile. The user submits, sees a red outline, scrolls to check another field and returns to find the message gone. The error was announced, but the recovery context was not retained.
Use the GOV.UK-style pattern as a benchmark: an error summary at the top of the page, linked to each field, plus a persistent inline message beside the field. The summary should receive focus after submission, and each link should move focus to the relevant input. The inline message should not vanish on blur. If the form uses a single-page checkout with collapsible sections, the summary should also expand the section containing the error.
Before: a toast notification that reads Please correct the errors and disappears after four seconds. After: a focused summary that reads There is a problem with your address. Enter a postcode in the format SW1A 1AA. The difference is not decorative. It is the difference between a user who can recover and a user who starts again.
Test three: instructions written for the developer
Developer-facing language leaks into public forms more often than teams expect. A date field says Value must match DD/MM/YYYY. A reference field says Field must be alphanumeric. A password field says Does not meet complexity requirements. These messages describe the validation rule, not the user's task.
Rewrite them as instructions a colleague could follow. Enter the date as DD/MM/YYYY, for example 13/11/2026. Enter your reference using letters and numbers only, for example AB123456. Your password needs at least 12 characters and one number. The audit should flag any message containing regex, field, value, invalid or complexity unless the term is explained in the label or hint.
This is also an accessibility issue, but it is not only an accessibility issue. It is a usability issue for every user who is tired, interrupted or using the service for the first time.
Running the audit in a UK sprint
Recruit five participants who reflect the service's actual users, including at least one person who uses a screen reader or magnification. Give them three error scenarios drawn from analytics: a missing required field, a format error and a server-side failure. Observe where focus lands, whether the message remains visible and what the participant says aloud. Record the six rubric scores before and after a rewrite. A small team can complete this in two days and produce a prioritised list of message rewrites for the next release.
The final question is not whether the error was announced. It is whether the user knew what to do next. In 2026, UK services should be judged on that second sentence.
