Suggest corrections when input fails validation
When a form rejects an entry and the system can work out what was probably intended, G177 says offer that correction rather than only reporting the error. It applies to input with restrictions on format, value or type, and only where a possible correct text is actually known. It is not a rule for every field on every form. Placement is part of the test, not a detail. W3C requires the suggestion to sit next to the field it belongs to, or a link to it to sit close by, and a correct suggestion parked at the top of a long form fails on that alone. This is a sufficient technique for 3.3.3 Error Suggestion at Level AA. W3C also lists it for status messages at the same level, when paired with the technique that announces the message to assistive technology.
How we find it in an audit
Our reviewers submit realistic wrong answers rather than nonsense. Common email typos, dates in the wrong order, phone numbers with spaces. Then we look at what comes back and where. A message reading 'invalid entry' with no suggestion is one finding. A good suggestion sitting far from its field is another.
How affected users experience it
A screen reader user who hears 'error, invalid email address' has to go back to the field, listen to what they typed character by character, and spot a transposed letter by ear. That is slow and it often fails. Naming the likely correction turns it into one decision. People with cognitive disabilities and anyone typing with a head pointer or switch get the same benefit, because the fix costs a click instead of a retype.
Passes vs. fails
Passes
The form answers beside the field, 'We do not recognize gmial.com. Did you mean john@gmail.com? Choose the suggestion or edit your entry.'
Fails
A user enters 'john@gmial.com' and the form answers 'Error, invalid email address.'
Other ways to satisfy this rule
9 guides on this site are filed under 3.3.3 Error Suggestion. W3C lists this one as sufficient for that rule on its own. Implement it correctly, in a way your readers' software actually supports, and the rule is met.
- ARIA18sufficientRaise blocking errors in an alert dialog
- G84sufficientExplain when input is not an allowed value
- G85sufficientExplain format errors and show the fix
- PDF22sufficientTell users when PDF form input is invalid
- G139advisoryLet users jump straight to form errors
- G199advisoryConfirm success when a submission works
This guide is our interpretation of W3C technique G177: Providing suggested correction text. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.