Explain format errors and show the fix
The date got typed the wrong way round, or the reference number is two digits short. G85 is the technique for saying so in text, and W3C counts it as sufficient for two rules on its own, error identification at Level A and error suggestion at Level AA. The technique asks for a description of the required format or values. We go one step past that on our own account and ask for a worked example too, because a description tells a reader the shape and an example lets them copy it. And keep what they typed. Nothing turns a small correction into a full re-entry faster than a form that empties the field it has just complained about.
How we find it in an audit
A reviewer enters data in the wrong format deliberately, on every field that carries a format rule. Dates, phone numbers, postcodes, reference numbers, card numbers. The message has to name the field, say what the format is, and ideally show one. We check the entered value is still sitting there afterwards, and that the message is tied to its field programmatically rather than floating at the top of the page with nothing connecting the two.
How affected users experience it
A screen-reader user cannot see the placeholder that hinted at the format, cannot see the small grey text under the field, and often cannot see their own entry once the field has been cleared. So the error message is the whole of what they get. Invalid format leaves them guessing at a shape. Dates use year, then month, then day, for example 2026-03-15 leaves nothing to guess at, and that is a two-second edit instead of a two-minute one.
Passes vs. fails
Passes
Dates use year, then month, then day, for example 2026-03-15. You entered 15/03/2026, and it is still in the box.
Fails
Invalid date format. The field accepts exactly one format and tells nobody which one it is.
How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- Error message describes invalid form field valueA tool finds candidates, you decide
Other ways to satisfy this rule
13 guides on this site are filed under 3.3.1 Error Identification. 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
- ARIA19sufficientAnnounce form errors with role=alert
- ARIA21sufficientFlag invalid fields with aria-invalid
- G83sufficientTell users which required fields they missed
- G84sufficientExplain when input is not an allowed value
- PDF5sufficientMark required fields in PDF forms
This guide is our interpretation of W3C technique G85: Providing a text description when user input falls outside the required format or values. 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.