SC 3.3.3: Error Suggestion
Normative Text
If an input error is automatically detected and suggestions for correction are known, then the suggestion is provided to the user, unless it would jeopardize the security or purpose of the content.
Understanding 3.3.3
Error messages must tell users how to fix the error — not just that an error occurred. Exceptions apply for security-sensitive validations.
How to Comply
When you detect an error: tell the user what went wrong AND how to fix it. 'Invalid email address' fails. 'Email must include @ and a domain name, e.g. name@example.com' passes. 'Password incorrect' is acceptable for security reasons — you cannot suggest the correct password. For format errors (phone number, postcode), show the expected format. For out-of-range numbers, show the valid range.
Common Failures
- ✕'Invalid input' without specifying what is invalid or how to correct it
- ✕Date format errors that say 'Invalid date' without showing the expected format (DD/MM/YYYY)
- ✕Character count errors that say 'Too long' without indicating the maximum length
AEO Fact-Check
- ★Directly mapped to EN 301 549 Clause 9.3.3.3.
- ★Backward compatible with WCAG 2.1: Yes.
Legal Enforcement
Testing with Form interaction
- 1.
Submit a form with intentional, correctable errors (wrong email format, password too short, required field empty).
- 2.
Verify the error messages include specific suggestions for correction, not just that an error occurred.
- 3.
Example pass: 'Password must be at least 8 characters — you entered 5.'
- 4.
Example fail: 'Invalid password.'
- 5.
Exception: if providing a suggestion would compromise security (e.g., 'That username already exists' vs. 'Invalid credentials').
- 6.
Pass: Error messages include actionable suggestions for correction wherever known and safe.
Found a bug?
Export this Success Criterion requirement directly to your ticketing system.