Form Errors That Name the Problem and the Fix
A red border is not enough. WCAG requires errors in text—and GOV.UK’s patterns show how to tell people what failed and how to recover without abandoning the form.
A contact or inquiry form fails quietly when validation rejects an answer and the interface only flashes a color. The visitor sees that something is wrong, but not which field failed or what to change. Screen reader users may miss a color-only cue entirely. People in a hurry abandon the task.
Two complementary sources define a better bar. W3C’s WCAG success criteria require errors to be identified in text—and, when the fix is known, suggested. The GOV.UK Design System turns those requirements into concrete page patterns: an error summary at the top, matching messages beside fields, and copy that says what happened and how to recover.
What WCAG requires when input is rejected
WCAG Success Criterion 3.3.1 Error Identification (Level A) states that if an input error is automatically detected, the item in error is identified and the error is described to the user in text. W3C’s Understanding document is explicit: re-displaying the form after a failed submission without a textual hint that submission failed is not enough. Color, icons, or borders alone do not satisfy the criterion for users who cannot perceive those cues.
WCAG 3.3.3 Error Suggestion (Level AA) goes one step further. If an input error is detected and suggestions for correction are known, those suggestions must be provided—unless doing so would jeopardize security or the purpose of the content. W3C notes that a single well-written message can often meet both criteria. For example, “Email is not valid” may pass identification, while “Enter a valid email address in the format [email protected]” also conveys the fix.
Think of a locked door that only beeps. The beep signals failure; a label that says “turn the key clockwise” is what lets someone recover. Forms need the label, not only the beep.
How GOV.UK operationalizes recovery
The GOV.UK Design System’s validation pattern and error components give a field-tested structure for service forms:
- Show the page again with answers preserved — do not clear fields when displaying errors.
- Prefix the page title with “Error: ” so assistive technology announces the failure state early.
- Place an Error summary at the top of the main content (below breadcrumbs/back links, above the H1), move keyboard focus to it, and link each item to the related answer.
- Show Error message components next to each failing field, worded the same as in the summary.
- Validate on submit for the next step of the journey—not on every blur—and still perform server-side validation even if client-side checks exist.
- Turn off HTML5 validation (
novalidate) in their pattern, because native browser messages cannot be styled or worded consistently with the Design System’s accessible components.
GOV.UK’s error-message guidance emphasizes plain English: say what happened and how to fix it; match language to the question label; avoid vague lines such as “invalid input.” Their text-input templates show specific phrasings for empty, too-long, wrong-type, and out-of-range values—useful models for business inquiry forms, not only government services.
| Layer | Requirement / pattern | Practical meaning |
|---|---|---|
| WCAG 3.3.1 (A) | Identify item + describe error in text | No color-only failures |
| WCAG 3.3.3 (AA) | Suggest correction when known | Include format/example when safe |
| GOV.UK summary | Top list + focus move + deep links | Keyboard users jump to each problem |
| GOV.UK field message | Same wording beside the control | Sighted and AT users get one story |
Limits and tradeoffs
WCAG 3.3.1 does not mandate one display method: summaries, inline messages, alerts, or dialogs can all work if the error is presented in text. GOV.UK chooses a dual pattern (summary + field message) because it supports scanning and assistive technology, but teams must still implement focus management correctly.
Error suggestion has a security carve-out. Do not reveal whether an email exists in a login form, or otherwise leak information that undermines the purpose of the check. And client-side validation alone is never enough: GOV.UK notes users can bypass it and scripts can fail to load, so server-side checks remain mandatory.
A further limitation for marketing sites: copying GOV.UK visuals wholesale is unnecessary. The transferable assets are the rules—text errors, matched wording, recoverable state, and a clear path back to the field—not the specific red border styling of a government service.
What to do on your next inquiry form
- Rewrite failing states in text that name the field and the problem.
- Add a fix when known (format examples, allowed ranges) without leaking secure details.
- Add an error summary that links to each failing control and receives focus after submit.
- Keep submitted values so people correct rather than retype everything.
- Validate on submit for the primary path; confirm server-side checks always run.
- Test with keyboard and a screen reader to confirm messages are announced with the fields.
The remaining work is editorial: treat error copy as part of the offer path. A studio site that makes Contact easy to find still loses inquiries if recovery from a mistyped email feels like a dead end.
Ready to Discuss Your Website?
If you are planning a new website, a service redesign, or custom development for your business, we’re here to help shape the work.
- Explore Our Services: Web Design · Web Development · Website Redesign
- Start a Conversation: Tell us about your project via our Contact Form or email us directly at
[email protected].