Key takeaways
- Give every control a persistent programmatic label and put format instructions before the visitor needs them.
- Describe each detected error in text; color, an icon, and aria-invalid can support the message but cannot replace it.
- For multiple errors, provide a linked summary, associate each message with its field, and move focus deliberately.
- Preserve valid input, test server and client failure paths, and confirm success in a way assistive technology can perceive.
01
Prevent the error before styling it
Use a visible label for every input. Keep placeholder text for examples rather than identity because it disappears as someone types. Mark required fields in text and programmatically, explain unusual formats before entry, group related choices with fieldset and legend, and use the appropriate input type and autocomplete token.
W3C’s forms guidance recommends asking only for information required to complete the process. Fewer unnecessary questions reduce cognitive work, privacy exposure, validation paths, and the number of ways a mobile visitor can be interrupted.
02
Write an error as the next useful action
WCAG 2.2 requires automatically detected input errors to be identified and described in text. “Invalid value” names no problem. “Enter a work email such as name@company.com” explains the condition when that requirement is genuinely necessary. Avoid blaming language and do not erase the value merely because it needs correction.
Associate the message with the field using a supported description relationship and set aria-invalid when the current value is invalid. Keep a visible cue as well. Announce dynamic changes carefully; aggressive validation during typing can interrupt people before they have finished.
Swipe to compare every column
| State | Visible message | Programmatic support |
|---|---|---|
| Required and empty | Add your email address | Label, required, linked message |
| Wrong format | Use name@example.com | aria-invalid and described error |
| Server rejected | We could not send this yet; your details are still here | Status or alert plus retry |
| Success | Message sent; expect a reply by… | Perceivable status and stable next step |
03
Help people recover from more than one problem
After submit, place a concise error summary before the form, give it a descriptive heading, and link each item to the affected field. Move focus to the summary or first invalid field according to the interaction, then ensure the field-level message remains available when the visitor arrives there.
Preserve every valid field and the original message. If the session expired or an attachment failed, say so directly and explain what remains. Recovery should not turn one mistake into the punishment of rewriting the whole inquiry.
04
Test the path where JavaScript, networks, and integrations fail
Test keyboard-only use, common screen-reader flows, zoom, small screens, autofill, password managers, client validation, server validation, duplicate submit, slow response, offline transition, CRM rejection, and successful retry. Confirm the submit button cannot silently trap focus or remain disabled after recovery.
Measure field errors and technical failures without recording sensitive values. Pair completion with qualified inquiries and accessibility feedback. The objective is not a form with zero errors; it is a form where an error never becomes a dead end.
Primary sources and further reading
Use the source material to validate details against your own context and current platform configuration.
This field note follows the XenGrowth editorial policy: primary sources where available, visible limitations, material review dates, and no invented first-hand experience.
Stay with the problem
