Error Identification
When a form rejects something, the page has to say which field is wrong and what is wrong with it, in text. A red border is not text. It carries nothing for a blind user and it is invisible to plenty of colorblind ones. A line reading Email address is missing an @ works for everybody, however they read the page. Two limits on this rule are worth having. It only bites where your code detects the error, so it never obliges you to add validation you did not have. And it says nothing about how the message is shown, so inline, at the top of the form, or in an alert are all acceptable. Getting that message announced is a separate rule, 4.1.3, which is where W3C files it and where we do too.
Why it matters
An error nobody can perceive looks like a form that refuses to submit for no reason. For a screen reader user the failure is silent as well as red, so there is no signal at all that anything went wrong. Press Submit, hear nothing, press Submit again. That loop is where a customer who had already decided to buy quietly gives up. And it costs one string of text to end it.
Who this rule protects
Screen reader users learn only that something failed, with no way to tell which field caused it. Colorblind users may not read a red border as different from any other border. People with cognitive, language and learning disabilities need the reason spelled out, because the shape of a form does not always make it obvious. Everybody else just loses the time.
How to check it yourself
- Submit each key form empty, then submit it again with deliberately bad data in one field at a time.
- Read what comes back. Each error has to name the field it belongs to and say what is wrong with it, in words. Redisplaying the form with no message at all is the failure this rule was written for.
- Check the errors that get fixed silently. If your code clamps a value into range, such as pulling a quantity of 500 down to the 10 you actually stock, it still has to tell the user it did.
- Check any field the browser validates rather than your code, then zoom the page to 200% and try again. In several browsers the built-in message is drawn at interface size and does not magnify with the page, which is a support problem to record rather than a failure of this rule.
- Test the announcement in the same session and write it up under 4.1.3. Both checks belong in one sitting, and they belong in two findings.
Failures we see most often
- A red border is the only sign anything is wrong, with no text anywhere on the page.
- The form comes back looking exactly as it did, entries still in place, with nothing to say the submission failed.
- A message at the top reads Please correct the errors below and nothing marks which fields those are.
- A quantity field silently rounds 500 down to 10 and submits, so the buyer finds out what they ordered when it arrives.
- Script cancels the submit and suppresses the browser's own validation message without putting anything in its place, so the form simply refuses to send and says nothing about why.
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
- Cognitive and learningpeople for whom the difficulty is understanding, remembering, or staying with it
How this one is tested
We list 1 ACT rule against 3.3.1. Each one defines exactly what a checker looks at, which is how automated tools decide what to flag. Each one also checks a slice, so passing every rule here is not the same as meeting the criterion, and a rule can be proposed rather than approved or need a person to finish it. The note beside each says which.
- Error message describes invalid form field valueA tool finds candidates, you decide
How to fix it
- Write a message that names the field and the problem, in words a person would use. Email address is missing an @ beats Invalid input in about the same number of characters.
- Put the message where it will be found. Next to the field, in a summary at the top of the form, or both. The rule does not choose for you, so choose whatever your form's shape makes easiest to reach.
- Say it in the page title too when the whole page reloads on failure, so a screen reader user hears 3 errors, Billing address before anything else on the page.
- Keep the red border and the icon. Color is welcome alongside the text, and it only fails when it is carrying the message on its own.
- Announce the error as well, under 4.1.3's rules, which means either moving focus to a summary or firing a live region. Pick one and test it, because doing both can announce the same thing twice in some screen reader and browser pairings and does nothing at all in others.
Step-by-step fix guides (13)
- ARIA2: Tell screen readers a field is requiredAdvisory
- ARIA18: Raise blocking errors in an alert dialog
- ARIA19: Announce form errors with role=alert
- ARIA21: Flag invalid fields with aria-invalid
- SCR18: Validate in the browser and describe the error
- SCR32: Put validation errors in the page as text
- G83: Tell users which required fields they missed
- 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
- G199: Confirm success when a submission works
- PDF5: Mark required fields in PDF forms
- PDF22: Tell users when PDF form input is invalid
Passes vs. fails
Passes
The page comes back titled 3 errors, Billing address, a summary at the top names all three, and each field carries the sentence that explains what it needs.
Fails
The submission fails, three fields glow red, and there is no text anywhere on the page to say what any of them wanted.
In audits and lawsuits
Checkout and lead-generation forms are where this rule earns its keep, so we submit them empty, submit them with bad data, and read everything that comes back. We do one thing differently from most reports. The text goes under this rule and the announcement goes under 4.1.3, because W3C says outright that the programmatic half is not required here. That matters the moment a developer disputes a finding, since the first thing they will do is look up what 3.3.1 actually says. Native browser validation satisfies this rule, and W3C says so, so the four drawbacks it brings belong in a report as advice rather than as findings. Depending on the browser the message may not stay on screen, and it may not magnify when the page is zoomed. Its wording is generic enough to miss 3.3.3. And it exposes one error at a time, so a form with three problems takes three submissions to clear. None of that is a 3.3.1 failure, which is exactly why the distinction is worth writing down before a developer asks.