Forms
Keep a form usable after validation fails
Recover from form errors with persistent labels, errors next to the field, server checks, kept non-sensitive entries and a deliberate focus target.
A person fills in five fields, presses Register, and the page returns with a red banner and half the answers gone. The validation worked, but the form still failed. The state after a rejected submission is part of the task and needs its own plan.
This guide covers that state: what stays visible, where errors appear, which check decides, what gets refilled, and where focus lands. The example is a fictional walk signup with ordinary contact fields. Those fields are still personal data and need appropriate handling.
Keep labels and hints on screen
Placeholder text disappears once someone starts typing, so it cannot serve as a label while they correct an entry. Give each field a visible label that stays in place, and keep format hints in text beside the field. Add an error alongside the label and hint, never in place of them. The person needs all three to fix the entry.
Write errors where the fix happens
The WAI forms tutorial describes giving feedback in two places: a summary near the top after submission, and a message at each affected field. Messages should name the problem and how to correct it. They must also reach assistive technology users, so colour alone is not enough.
Treat that as a writing rule. Replace 'Invalid input' with 'Enter a group size from 1 to 6.' Associate each message with its field in the markup so the two are announced together. Make each summary item a link to the field it names.
Sources: W3C WAI: User Notifications in Forms
Let the server make the final decision
MDN notes that client-side validation is a convenience for catching mistakes early. Anyone can disable it or bypass it by sending requests directly. It cannot guarantee security or data integrity, so the server must validate every submission again.
Make the server's response match the browser's: the same wording, the same summary and the same field messages. If the two checks disagree, for example the browser accepts a group size that the server rejects, fix the rule instead of shipping two error styles.
Sources: MDN: Client-side form validation
Refill entries field by field
Where your data-handling rules permit, show ordinary entries again within the current form correction flow, including invalid ones, so the person edits instead of retyping. Do not expose another person’s entries or store form contents solely to make refilling convenient. Decide this per field rather than with one blanket rule. Never echo passwords, card numbers or security codes back into the page. Ask for them again and say why.
| Field | Refill after error? | Reason |
|---|---|---|
| Full name | Yes | Still personal data; refill only within the permitted correction flow |
| Yes, as typed | The person must see the mistake to fix it | |
| Route choice | Yes | A lost selection is easy to miss |
| Group size | Yes, as typed | Shows exactly which value was rejected |
Decide where focus goes
After a server round trip, move focus to the error summary heading. That tells keyboard and screen reader users that the submission failed and how many problems remain. When the browser checks on submit, focusing the first invalid field is a reasonable alternative. Choose one behavior per path, document it, and never move focus while someone is typing.
In the fictional Riverside Walk signup, Sam enters a name, picks the River Loop route, types sam.example.org as the email and 8 as the group size. The server rejects both values. The page returns with focus on the heading '2 problems to fix'. Two linked summary items appear, both rejected values stay visible beside their messages, and the name and route are intact. Sam follows each link, changes the email to sam@example.org and the group size to 4, and submits again.
Recovery checklist and limits
This guide does not cover multi-step forms, session timeouts or verification challenges. It also cannot predict how a particular screen reader will announce a message, so test with the assistive technologies your audience uses. Personal data retention rules may limit what you can refill.
| Check | Passes when |
|---|---|
| Labels | Every label and hint is still visible after the error |
| Messages | Each one says what to change, beside its field and in the summary |
| Server path | The same messages appear with browser validation turned off |
| Refill | Non-sensitive entries return; secrets are cleared and the page says why |
| Focus | Focus lands once on the documented target, then stays where the person puts it |
Related guides
Primary references
Useful Tomorrow home · All guides and studies · Awesome Patel’s publication profile