Level AAWCAG 2.0

3.3.3 Error Suggestion

If an input error is automatically detected and suggestions for correction are known, the suggestions are provided to the user, unless it would jeopardize security or purpose.

Last reviewed: September 9, 2026

Understanding 3.3.3

This criterion goes a step beyond Error Identification (3.3.1) by requiring that, when the system knows how to fix a detected error, it tells the user how, reducing trial-and-error especially for people with cognitive or learning disabilities. The security/purpose exception exists so this can't be exploited to help an attacker guess valid usernames or passwords through overly specific error messages.

How to Meet It

When validation logic knows the cause of an error, such as an invalid date format or a required field left blank, give a specific correction suggestion in text (for example, "Enter your date of birth as MM/DD/YYYY"). For security-sensitive fields like login passwords, generic messaging ("Incorrect username or password") is acceptable and preferable, since a specific suggestion could reveal which field was wrong.

Code Examples

INCORRECT

<p id="dob-error">Invalid input.</p>
<!-- Doesn't tell the user what's actually wrong or how to fix it -->

CORRECT

<p id="dob-error">Enter your date of birth using the format MM/DD/YYYY, e.g. 04/25/1990.</p>

Frequently Asked Questions

Do I need to suggest a fix when a login attempt fails?

No. 3.3.3 explicitly exempts cases where a suggestion would compromise security, such as confirming which part of a username/password pair was incorrect. A generic error message is acceptable there.

Related Success Criteria

3.3.1 Error Identification 3.3.2 Labels or Instructions 3.3.4 Error Prevention (Legal, Financial, Data)3.3.5 Help

Quick Facts

Criterion3.3.3
LevelAA
IntroducedWCAG 2.0

Automate Compliance

AccessiSight automatically scans and identifies 3.3.3 issues in your codebase.

Try Scanner Free