Knowing that an error exists is not always enough. When a system can determine how an input error can be fixed, users should not be left to guess the solution.
WCAG 3.3.3 requires that clear suggestions for correcting errors are provided when those suggestions are known, unless doing so would compromise security or the purpose of the content. This criterion builds on Error Identification (3.3.1) by moving from awareness to resolution.
WCAG Success Criterion
3.3.3 Error Suggestion (Level AA)
If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardise the security or purpose of the content.
Level AA is commonly required by accessibility laws and policies, making this a practical compliance requirement, not an optional enhancement.
What This Criterion Is About
If your system knows how to fix the user’s mistake, it must tell them how.
Identifying that something went wrong is not enough if users still have to experiment, retry, or abandon the task to figure out what to do next.
What Counts as a “Known Suggestion”
A known suggestion is a correction the system can reasonably determine without guessing.
This includes:
- Required input that was omitted
- Invalid formats (email, date, phone number)
- Values outside an allowed range
- Inputs that can be interpreted safely (e.g. “12” → “December”)
If the system can validate the input, it already knows the rule. If it knows the rule, it can usually explain how to fix the error. WCAG does not require artificial intelligence, spell-checking, or advanced inference. It only applies when a reasonable correction is already known.
Relationship to Error Identification (3.3.1)
- 3.3.1 Error Identification
Users are told what went wrong. - 3.3.3 Error Suggestion
Users are told how to fix it when the fix is known.
In practice, many error messages can satisfy both criteria at once:
- “Email is invalid” → identifies the error
- “Enter a valid email address in the format name@domain.com” → suggests the correction
Security and Purpose Exception
Suggestions are not required when providing them would:
- Compromise security (e.g. login attempts, verification codes)
- Undermine the purpose of the activity (e.g. exams, assessments, games)
In these cases, identifying the error without revealing corrective guidance is acceptable.
This exception should be applied narrowly. Most everyday form errors do not fall under it.
Implementation Notes
To meet this criterion in practice:
- Suggestions must be provided in text, not icons alone
- Suggestions should be programmatically associated with the field (for example, via
aria-describedby) - Placeholder text is not sufficient as the only error guidance
- Dynamic error suggestions must be announced to assistive technologies
- Suggestions may be inline, in a summary, or both; silence is not allowed
When implemented correctly, assistive technologies can announce both the error and the suggested fix together.
Example announcement a screen reader user might hear:
“Email address, invalid. Enter a valid email address in the format name@domain.com.”
What This Criterion Does Not Require
- Guessing user intent
- Complex logic or AI-driven correction
- Automatic fixing of user input
- A specific visual layout or error style
It only requires that known solutions are communicated clearly.
Common Failures (Even When Errors Are Identified)
- Error messages that say only “Invalid input”
- Highlighting fields without explaining how to fix them
- Placeholder-only hints that disappear on focus
- One-error-at-a-time loops that force repeated submission
- Visual suggestions not exposed to screen readers
Some of these patterns may technically pass Error Identification (3.3.1) but still fail 3.3.3.
Examples
Passing Example: Format Guidance
A form rejects an email address and displays: “Enter a valid email address in the format name@domain.com.”
The error is identified, and the correction is explained.
Passing Example: Limited Set of Values
A month field rejects “12” and provides:
- “Choose one of: January through December.”
- “Did you mean ‘December’?”
Both suggestions are known and safe.
Failing Example
A form reloads with the message:
“There was an error.”
No guidance is provided, even though the system knows the required format.
How to Test
- Trigger a known validation error
- Confirm the error message explains how to fix it
- Check that suggestions are available in text
- Verify that assistive technologies announce the suggestion
- Confirm no security-sensitive hints are exposed
If users know something is wrong but not how to fix it, the criterion is not met.
Benefits
This success criterion helps people who:
- Have cognitive or learning disabilities
- Use screen readers or magnification
- Have limited motor control and want to avoid repeated corrections
- Experience fatigue or frustration from trial-and-error workflows
Clear suggestions reduce effort, retries, and abandonment.
Wrapping Up
Error Suggestion is about removing guesswork. When a system knows the rule, it should share it clearly, accessibly, and at the moment the error occurs. While security-sensitive cases are exempt, most form errors are not. Meeting WCAG 3.3.3 turns error handling from a blocker into guidance and helps users complete tasks instead of fighting the interface.
