WCAG 3.3.3 Error Suggestion

What it asks

3.3.1 Error Identification asks that an error is pointed out and described. This criterion goes one step further. Where the site knows what a correct entry would look like, it must say so. If a date field expects day, month, year, the message should say that and give an example. If a username is already taken, the message should say so rather than "Invalid username". If a required field is empty, the message should say what to put in it.

The condition is that a suggestion is known. A site is not asked to guess. If the only thing the site knows is that the value did not match, and it cannot tell why, 3.3.1 applies and this criterion asks nothing more. In practice the site almost always knows more than it says: it knows the format it is checking against, the list it is checking in, and the length it is enforcing.

There is one exception. A suggestion may be withheld when giving it would jeopardise the security or purpose of the content. A sign-in form should not say which of the username and password was wrong, and a quiz should not say what the right answer was. The criterion is Level AA, and products commonly pass 3.3.1 and fail this one, because "Error" is quicker to write than "Enter a postcode such as SW1A 1AA".

Its official name is success criterion 3.3.3 Error Suggestion, at Level AA. It was added in WCAG 2.2, under guideline 3.3 Input Assistance and the principle Understandable. The W3C’s normative text says, in part:

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

From WCAG 2.2, W3C. Full explanation: Understanding 3.3.3 Error Suggestion.

Who it helps

People with cognitive and learning disabilities, who may not be able to work out what went wrong from "Invalid" alone. People with low vision and screen reader users, for whom finding the problem by trial and error is slow and tiring.

People with motor disabilities, for whom each failed attempt costs effort, and everyone who has ever stared at a form wondering what it wanted.

What passes and what fails

These pass

• "Enter the date as DD/MM/YYYY, for example 04/07/1990."
• "That username is taken. Try adding a number, or choose another."
• "Enter a UK postcode, such as SW1A 1AA."
• "Your password needs at least 8 characters, including one number."
• A sign-in form that says "The email address or password is incorrect", without saying which, because saying which would help an attacker.

These fail

• "Invalid input" with no hint of what a valid input would be.
• "Error" beside a field, with no explanation at all.
• A format error with no example of a valid value, when the site is checking against a known format.
• "Please correct the highlighted fields", when the site knows exactly what is wrong with each one.

How to test it by hand

1. Submit each form with deliberate mistakes, as for 3.3.1: a wrong format, an out-of-range value, a taken username, a value that breaks a stated rule.
2. For each error message, ask whether the site could have known how to fix it. A format it checks against, a range it enforces or a list it looks up all count as known.
3. Where it could, check that the message says how: the expected format, an example, the range, or a different value to try.
4. For sign-in and other security-sensitive forms, check that the message does not give away more than it should, which the exception allows.
5. Write down every message that identifies an error without suggesting a fix the site could have given.

What automated testing can decide

What a machine can decide

A tool can read what a field declares: a pattern, a type, a minimum and maximum, a required status. When such a field is in an error state, the tool knows that a correction was derivable, and it can read the message that was shown. It can also recognise credential fields and set them aside, since the exception usually applies to them.

What it cannot

As with 3.3.1, reaching an error state means submitting a form, which a tool must do with care or not at all. And whether a message actually suggests a correction is a judgement about words. "Check the date" and "Enter the date as DD/MM/YYYY" are both short sentences near a field, and only one of them helps.

How Dreven handles it

Dreven never submits a real form without your say-so, and never takes a step that spends money or makes a commitment on a live site.

For each error state the audit reaches, you see the field, the message that was shown and a picture of it, and a reviewer decides whether the message suggests a correction. A form whose error state was not reached is listed as untested, never as a pass.

No automated check makes a site conform. In Dreven, a person reviews the results and signs the report.

Related criteria

• 3.3.1 Error Identification (Level A). The error must be identified and described first; this adds the fix.
• 3.3.2 Labels or Instructions (Level A). Instructions given before the person types prevent the error in the first place.
• 3.3.4 Error Prevention (Legal, Financial, Data) (Level AA). For payments and legal commitments, the person must also be able to check and correct before committing.

Questions people ask

All WCAG 2.2 criteria, in plain words