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.
- Field and problem identifiable.
- Correction action explicit.
- Constraints explained early.
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.
- Summary and field messages.
- Accessible error associations.
- Focus and contrast tested.
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.