Let users jump straight to form errors
G139 puts a link next to each reported error that takes the user straight to the field that caused it, usually from a summary at the top of the re-displayed form. W3C describes the server-side shape. The form comes back with the data still in it, a description of what went wrong at the top, and a link to each field with a problem. Now the part that decides how you read this page. W3C lists G139 as advisory at 3.3.1 Error Identification and advisory again at 3.3.3 Error Suggestion. It marks it sufficient nowhere. Advisory means the working group recommends the practice and does not accept it as evidence of conformance, so this is genuinely good error handling and it is not a route through either rule. What passes 3.3.1 is naming the error in text and saying which field it belongs to.
How we find it in an audit
Our reviewers submit forms wrong on purpose, in several ways, then look at what comes back. Does a summary appear? Does focus move to it, and does each item link to the field it names? We check that the entered data survived too. An error summary on an emptied form is a worse outcome than no summary at all.
How affected users experience it
Hearing 'there were errors below' on a thirty-field form starts a hunt. The user tabs from field to field listening for something that sounds wrong. They have no idea how many problems they are looking for, or whether they have found them all. Linked errors turn that hunt into a list, and a list is something a screen reader user can work through with certainty rather than hope.
Passes vs. fails
Passes
An error summary takes focus and lists each problem as a link, such as 'Postcode is missing', that moves focus straight to that field.
Fails
Submitting a 30-field form returns 'There were errors below' and nothing more, so the user must inspect every field to find them.
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
The other techniques filed under this rule
13 guides on this site are filed under 3.3.1 Error Identification. W3C lists this one as advisory for that rule rather than sufficient, which means it helps real readers without being accepted as evidence you conformed.
- 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
- G85sufficientExplain format errors and show the fix
This guide is our interpretation of W3C technique G139: Creating a mechanism that allows users to jump to errors. 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.