WCAG 3.3.3 Error Suggestion

Success criterion 3.3.3 helps people fix a form after something went wrong. A message like "Invalid input" tells a customer that there is a problem, but not what to do. People with cognitive disabilities, screen reader users and people with motor disabilities who make typing errors often give up at this point. It is level AA and appears in EN 301 549 as clause 9.3.3.3.

What the criterion requires

If an input error is automatically detected and suggestions for correction are known, the suggestions must be provided to the user.

• An input error includes required information that was left out and information outside the required format or values.
• "Known" means the site can tell what would be accepted — for example, the expected format, the allowed range, or the list of valid options.
• Exception: a suggestion may be withheld if it would jeopardise the security or purpose of the content — for example, revealing which part of a login was wrong, or giving away the answer in a quiz.

The suggestion is usually text, and it must meet the other criteria (for example, be readable and reachable by screen readers).

Typical failures on an online shop

• "Invalid postcode" with no hint of the expected format for the selected country;
• "Invalid date" in a card expiry field without saying the format is MM/YY;
• "Password does not meet requirements" without listing the requirements;
• "Quantity not available" without saying how many items are in stock;
• a coupon field that only says "Error" when the code has expired;
• a VAT ID field that rejects input without showing an example.

How to check it

Automated: our checker has no rule for this criterion. It needs a manual check.

By hand: for each form, enter typical wrong values: a postcode in the wrong format, a date in the past, a too-short password, a quantity above stock, an email without "@". Read each message and ask: does it say how to correct the input? Check also that the message is announced by a screen reader when it appears or when you move to the field.

How to fix it

• Write messages that state the fix: "Enter the postcode as 5 digits, for example 10115".
• List rules up front (password length, allowed characters) and repeat them in the error.
• Where there is a small set of valid values, suggest the closest ones or offer a selection.
• Keep the user's input in the field so they can correct it rather than retype it.

Related criteria

• 3.3.1 Error Identification — the error must be identified and described.
• 3.3.4 Error Prevention (Legal, Financial, Data) — checks before an order is final.
• 3.3.2 Labels or Instructions — explain the format before the user types.

Frequently asked questions

What is the difference between 3.3.1 and 3.3.3?

3.3.1 asks you to identify the field in error and describe the error in text. 3.3.3 goes a step further: when you know how the user can fix it, you must tell them.

Should a login form say whether the email or the password was wrong?

Not necessarily. 3.3.3 has an exception when a suggestion would jeopardise the security or purpose of the content, so a generic "email or password is incorrect" is acceptable.

Can an automated tool check error suggestions?

No. It would have to submit forms with wrong data and judge the wording of the messages, so this is checked by hand.