← All criteria

Understandable · Level AA · 3.3.3

Error Suggestion

When a form catches an input error and a fix is knowable, the error message has to actually suggest that fix — not just flag that something's wrong — as long as suggesting it doesn't compromise security or the form's purpose.

  • Blind
  • Low vision
  • Cognitive
  • Motor
The problem, in practice — select the image to enlarge it
A shipping details form compared with errors that are flagged with no fix versus errors paired with a specific suggestion. 'Poor error messages' shows Email, Password, and Phone number fields each marked 'Invalid email address', 'Invalid password', or 'Invalid phone number' with no guidance on what a valid value looks like. 'Good error messages with suggestions' shows the same fields each paired with a concrete suggestion, such as 'Please enter a valid email address. Suggestion: Include @ and a domain (example: ana@example.com)'. Paired examples below contrast an email, password, date of birth, and postal code field each flagged with only 'Invalid X' text against the same fields each given a specific corrective suggestion with an example value.

How to recognize it

Trigger a validation error and read the message: 'Invalid input' or 'This field has an error' with no explanation of what's actually wrong is a common failure, when a more specific and correctable explanation was available — a date field could say 'Use the format MM/DD/YYYY' instead of just flagging the date as invalid; a password field that requires a number could say so instead of leaving the user to guess which of several rules they broke. This builds directly on 3.3.1's requirement that an error be identified at all — this criterion goes a step further and asks for guidance toward the fix. Someone with a learning disability may not be able to infer the correction from a generic error alone; a blind or low-vision user gets a much clearer picture of what to actually do from a specific suggestion than from re-parsing a vague message; someone with a motor impairment benefits from getting it right in fewer attempts, since each failed submission costs them more effort to retry. The exception is narrow: suggestions aren't required where offering them would undermine security (revealing exactly why a password or login attempt failed) or the content's purpose.

How to fix it

Write validation messages that name the specific rule that was violated and, where possible, what to do about it: 'Enter a date in MM/DD/YYYY format' rather than 'Invalid date'; 'Password must include at least one number' rather than 'Password is invalid.' Keep the exception in mind for genuinely sensitive contexts — a failed login shouldn't reveal whether the username or the password was the wrong part, since that specificity would help an attacker, not the user.

Example

Avoid

<input type="date" aria-invalid="true" aria-describedby="date-err">
<span id="date-err">Invalid input</span>

Prefer

<input type="date" aria-invalid="true" aria-describedby="date-err">
<span id="date-err">Enter a date in MM/DD/YYYY format</span>

Resources

  • 3.3.1 Error Identification

    3.3.1 only requires that an error be identified and described in text at all; this criterion goes further and requires a specific correction suggestion when one is knowable and safe to give.