Error Suggestion
When your code knows what would fix an error, it has to say so. Invalid date is a verdict. Enter the date as month, then day, then a four-digit year is a suggestion, and only one of those lets somebody finish. Two conditions have to hold before the rule applies. The error has to be one your code detected, and a correction has to actually be knowable. One exception lifts it, which is where telling the user would give away something the content depends on keeping. That exception is why a login may say only that the username or password was wrong, and why a test is not obliged to hand back the right answer.
Why it matters
Validation code always knows why it rejected the input. It compared something against something. Withholding that reason is a decision somebody made, not a limit of the technology. W3C is blunt about what the decision costs, because its own account of this rule says users abandon forms when they know an error happened and cannot work out how to fix it. Every guess-and-resubmit cycle sheds people. For somebody with a motor impairment each cycle is a physical cost, since every correction is another round of typing.
Who this rule protects
People with cognitive and learning disabilities are hit hardest, because knowing something is wrong is not the same as knowing what to do. Blind and low-vision users need the fix described rather than shown, since the field will not look wrong to them. People with motor impairments pay for every extra attempt in effort. Everybody else is stuck in the same loop with less at stake.
How to check it yourself
- Trigger every validation error you can and read the message. Ask whether it says what to do, not just that something is wrong.
- Where the field wants a format, check the message shows that format with a real example inside it.
- Where the field wants one of a fixed set of values, check the message either lists the acceptable ones or names the one the user probably meant.
- Check whether the message even comes from you. Browsers supply their own for built-in validation, and those are generic enough that they usually identify the error and miss the fix.
- Ask whether a correction is knowable before filing a finding. If nothing in the system knows what a right answer looks like, this is not the rule being broken.
Failures we see most often
- A rejected phone number produces Invalid input, with no hint at the format the field expects.
- A password is rejected against rules the message does not repeat, so the user scrolls back up to look for them, if they were ever stated at all.
- A date field says Date is invalid on a page that never said which order it wanted the day and the month in.
- A form falls back on the browser's own message, which says the value does not match the requested format and nothing about what that format is.
- A month field rejects 12 and offers nothing, when it could list the twelve month names or simply ask whether December was meant.
Who this one is for
Read from this rule's own note above, so the grouping and the note cannot disagree.
- Blind and screen reader userspeople who cannot see the screen
- Low visionpeople who can see the screen but not easily
- Motor and keyboard-onlypeople who cannot use a mouse, or cannot use one precisely
- Cognitive and learningpeople for whom the difficulty is understanding, remembering, or staying with it
How to fix it
- Rewrite every message so it carries the fix as well as the fault, with a concrete example inside it wherever a format is involved.
- Repeat the format rules inside the message even though they appear above the field. That is the moment the user needs them, and sending somebody back up the page is sending them away from the error.
- Where the field takes one of a known set of values, put the set in the message, or match what was typed against the set and offer the nearest one back.
- Where security means you have to withhold the reason, say so plainly and offer the route that does work, such as a password reset, rather than leaving somebody guessing at a message that cannot help them.
Step-by-step fix guides (9)
- ARIA18: Raise blocking errors in an alert dialog
- SCR18: Validate in the browser and describe the error
- SCR32: Put validation errors in the page as text
- G84: Explain when input is not an allowed value
- G85: Explain format errors and show the fix
- G139: Let users jump straight to form errorsAdvisory
- G177: Suggest corrections when input fails validation
- G199: Confirm success when a submission works
- PDF22: Tell users when PDF form input is invalid
Passes vs. fails
Passes
The field says Enter your date of birth as MM/DD/YYYY, for example 03/15/1985, so the user can fix it without guessing.
Fails
The only feedback the field gives is Date is invalid, and nothing on the page ever said which format it wanted.
In audits and lawsuits
We grade every validation message on an audited form against one bar, which is whether it tells the user what to do next. The ones that fail, we rewrite, so the client's team can paste our wording straight in. Two things keep the findings defensible. The rule only applies where a correction is knowable, so a rejection with no knowable fix is a feature request rather than a finding. And the security exception is real, so we do not raise anything against a login that declines to say which half was wrong. This criterion has no automated rule. The one that sounds like it, which checks whether an error message describes the invalid value, is filed under 3.3.1 and is still only proposed.