A useful error message identifies the field, explains the problem and gives a correction. It stays visible, is associated with the field and makes sense without colour alone. Distinguish input errors from delivery failures and retain non-sensitive information that need not be re-entered.
Give an instruction tied to the field
Write « Enter an email address containing @ » instead of « Error 42 ». Place the message beside the field and associate it with that field in the interface. The W3C recommends clear notifications, combining overall feedback after submission with specific guidance near the relevant control.
Explain known rules beforehand
State required formats and information before entry: identifier length, date format or maximum file size. Do not reveal a known constraint only after several failed attempts. Examples should match what is really accepted and avoid asking for data unnecessary to the task.
Preserve answers and guide recovery
After server or validation errors, keep completed fields when possible. Show a summary of issues near the start and local instructions beside each affected field. Move focus to a logical point for correction, then let the person review changes before another submission.
Distinguish correction, outage and success
A mistyped field is not a service outage. If submission fails technically, say so without pretending the enquiry arrived, and offer another contact route when possible. Conversely, a successful submission needs an explicit confirmation and an explanation of what happens next.
Test realistic errors
Try a blank field, a plausible but rejected format, an oversized file and a lost connection. Test by keyboard, on a phone and with assistive technology when available. The contact form guide helps reduce the number of fields before you write their error messages.
Documented reference points for this topic
| Reference | Value or syntax | Scope |
|---|---|---|
| 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.
Verification workshop: evidence before a decision
A proposed exercise on a chosen scope, using fictional data where needed. Record what you observe; this scenario describes no test already performed on your website.
- Action to try
Trigger a format error in a test form. Try to understand the required correction, find the field and succeed using the keyboard.
- Record to retain
Keep message text, field association or link, focus and retry result. Check that other useful entries are retained.
- What this evidence does not establish
A red border alone does not explain a correction. An ARIA attribute does not prove a message is announced in the tested environment.
Further documentation : W3C WAI — User notifications
Help someone resume entry without losing it
A visitor submits a form with an invalid address and one required field empty. The page identifies each issue beside its field, summarises errors, preserves entered text and makes focus easy to find. The visitor corrects it and receives explicit confirmation.
Test with keyboard and phone. A generic “error 400” or colour alone does not explain how to recover.
