Estimated reading time : 5 min · Published
Describe the expected correction
Connect each message to its field and explain the required information. “Email address is incomplete” helps more than a technical code. Do not blame the user for a server outage or unavailable service.
Explain rules before entry where possible: format, length, accepted files and optional information. The contact form guide helps reduce fields and clarify expectations.
Validation timing is part of the message. An initially empty required field should not be announced as invalid before any submission attempt. While an address is being entered, a temporary value such as alex@ does not necessarily warrant an alert on every keystroke. Depending on the task, validate on leaving the field or after submission; immediate feedback can still help when checking availability remotely.
aria-invalid indicates that a value failed validation; it neither defines the rules nor blocks submission itself. Connect that state to a message explaining the correction, then reassess it after correction. Do not present an accepted email format as proof of reachability. Pending verification and service failure need their own messages.
- Field and problem identifiable.
- Correction action explicit.
- Constraints explained early.
Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.
| Observed moment | Feedback suited to this case | Check to perform |
|---|---|---|
| First opening, required field empty | Label, required indication and help | No premature aria-invalid="true" |
| Address entry still in progress | Let the person finish according to the chosen strategy | Avoid repeated alerts for a temporary state |
| Submission attempted with a rejected value | Explicit error associated with the field | aria-invalid, accessible message and a way to correct |
Make feedback perceivable
After submission, show a summary near the beginning and a message beside each affected field. Move focus predictably and connect each field to its error for assistive technology. Colour alone is insufficient.
The W3C notification tutorial gives examples of local and overall feedback. Test keyboard, screen reader, zoom and narrow screens.
Fictional example: a form contains name, email address and message fields. The name is missing and the address is incomplete; the message is already valid. The initial check must therefore report 2 errors, not 3. Correcting only the name leaves 1 error; correcting the address leaves none. At each step, compare the summary, local errors and retained values without requiring the message to be entered again.
In this test contract, each summary link leads to the affected field; aria-describedby associates the explanation with its control and aria-invalid indicates the invalid state. Once corrected, remove the obsolete error association while keeping useful instructions. A service failure after validation is not another input error and does not prove that anything was saved. The table therefore distinguishes 0 field errors from a genuinely confirmed submission.
- Summary and field messages.
- Accessible error associations.
- Focus and contrast tested.
Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.
| Test step | Remaining field errors | Expected outcome |
|---|---|---|
| Initial check | 2: name and email address | Message retained; both errors accessible |
| Only name corrected | 1: email address | Name error removed; other error retained |
| Address corrected too | 0 | Valid fields; saving still needs verification |
| Service unavailable after validation | 0; separate service incident | No false confirmation; recovery explained |
- W3C WAI : User Notification
W3C WAI, consulted 22 October 2026: form notifications. The fields and steps form a fictional teaching example.
Preserve input and intention
Keep valid values after an error, except sensitive data that should not be displayed again. A long form should let someone resume in place. A rejected file needs a format or size explanation.
Distinguish validation errors, network delays and duplicate submission. Repeated clicks should not create multiple requests or orders. Confirmation must say whether the action was actually recorded.
- Valid fields retained.
- Network failures handled clearly.
- Duplicate submissions controlled.
Test real cases
Try empty fields, accented characters, mistyped email, oversized file, expired session and unavailable server. Ask someone unfamiliar with the form to recover without help and observe hesitation.
After correction, check the email or next step, not just the on-screen message. Confirmation and error content also need review in every published language.
- Representative errors covered.
- Complete journey checked.
- Messages translated and reviewed.
Preserve input after an error
Proposed case: an invalid date clears other fields. The message identifies the issue but forces the person to restart the request.
Trigger expected errors with fictional values. Check retention, message association and recovery; correction should not require guessing a hidden rule.
- Trigger an expected error
- Check retained data
- Complete the corrected journey
- Verify the received request
Design a contact form that genuinely helps
Separate a correction from a complete restart
A rejected field should not unnecessarily erase valid answers elsewhere in the process. Test the actual server response, then revisit the previous step: preserving information only in the browser is insufficient if a server error returns an empty form.
Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.
| Situation | Expected result | Check boundary |
|---|---|---|
| Invalid field | Identify the field and explain the correction. | Keep other valid, non-sensitive answers. |
| Expired process | Explain what can be resumed and what must be checked again. | Do not expose previous input to another session. |
| Back then forward | Correct one value and review the updated summary. | Confirm that old and new values are not mixed. |
- W3C WAI · WCAG 3.3.7
Read the criterion’s scope and exceptions; this scenario is a practical interpretation, not a compliance certificate.
Reference documents
- W3C WAI : Validating Input · Source consulted
- W3C : Error identification · Source consulted
- MDN : aria-invalid · Source consulted
- W3C notification tutorial · Source consulted
Content updated on
Documented reference points for this topic
| Reference | Value or syntax | Scope |
|---|---|---|
| WCAG 2.2 · 1.4.10 | 320 CSS px | Vertical content without two-dimensional scrolling; exceptions cover inherently two-dimensional content. |
| WCAG 2.2 · 2.5.8 | 24 × 24 CSS px | A smaller target can satisfy the criterion through spacing; other exceptions apply. |
| WCAG 2.2 · 3.3.7 | A · same process | Within one process, previously supplied information must be auto-populated or available to select, subject to the criterion’s exceptions. Browser autocomplete alone is insufficient; the site must offer the information already received or avoid requesting it again. |
Dates indicate when references were consulted. These facts are neither a site audit nor an overall compliance statement.