Search topics
Error summaries that don't say which fields failed
A sign-up form answers a failed submission with one banner that says "Please check the form" and red borders on the fields, so nothing in text says which fields are wrong or what to change.
The problem
People told only to "check the form" have to find the failed fields themselves, and many can't.
A pottery studio's sign-up form asks for a full name, an email address and a postcode, with a "Sign up" button at the bottom. A visitor types their name, mistypes their email as "alex@" and leaves the postcode empty. They press "Sign up". A banner appears above the form: "Something went wrong. Please check the form." The email and postcode fields get red borders. Focus stays on the button. A sighted mouse user can scan for red; a screen reader user hears nothing at all, and on a phone the banner is already scrolled out of view.
3.3.1 asks that when an input error is detected automatically, the item in error is identified and the error is described to the user in text. The banner is text, but it identifies nothing: it doesn't say which fields failed or why. The fields are identified only by a border colour, which is not text, and their markup doesn't mark them invalid or carry a message. So nothing in text tells anyone which items are in error.
The longer the form, the worse this gets. On a short form the red borders may sit in one view; on a checkout or an application form they are spread over several screens, and every person who can't take them all in at once has to search.
5 of 10 groups affected
- No vision (affected)
- Low vision (affected)
- Colour vision (affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (affected)
- Reach, strength (not affected)
- Cognitive (affected)
- Seizures (not affected)
- Without vision Focus stays on the button at the bottom, so a screen reader says nothing about the banner at the top, and the fields themselves are announced with no error.
- Limited vision With a magnifier only part of the form is in view, so the banner and each red border have to be found one by one.
- Limited manipulation Keyboard users have to Tab back through the whole form, checking every field, to find the ones that failed.
- Without perception of colour The red borders are the only thing that sets the failed fields apart, and they look like every other border.
- Limited language, cognitive and learning abilities "Please check the form" gives no starting point, so people have to remember what they typed and guess what was wrong.
Scanners load the empty form and see labelled fields, so it passes; the failure only exists after a failed submission. A test that does submit finds a banner with text in it, which looks like an error message. Whether that text names the failed fields is a judgement no rule makes. An AI fix often adds role="alert" to the banner: screen readers then announce "Please check the form", which tells them something failed but still not what.
Try it
Press Sign up, then find what to fix.
Send the form as it is, then look, or listen, for which fields failed and why.
Broken Can you fix this?
A recreated demo. The broken version is intentionally inaccessible.
The fix
Name each failed field and what to change in text, and lead people to them.
- 1Name every field in error in text, with what to change.
- 2Never let a general message, colour or border be the only sign of which field failed.
- 3After a failed submission, put the first problem where people already are, or move focus there.
<div class="banner">Something went wrong. Please check the form.</div> <form novalidate> <label for="name">Full name</label> <input id="name" name="name" autocomplete="name" value="Alex Morgan"> <label for="email">Email address</label> <input id="email" name="email" type="email" autocomplete="email" class="invalid" value="alex@"> <label for="postcode">Postcode</label> <input id="postcode" name="postcode" autocomplete="postal-code" class="invalid"> <button>Sign up</button></form>The banner says something failed but not what. The invalid class only paints a red border, so the two fields in error are identified by colour and nothing else.
This is the page as the server, or the script, renders it after the failed submission.
Focus moves to the summary, so a screen reader reads its heading straight away and keyboard users start from the list. Each link names the problem in the words of the field's label and goes to that field: a link to an input's id moves focus into it. The message at each field says the same thing again, so people who reach a field by Tab, or who have scrolled down, still hear and see what to change.
All three name each failed field in text and pass 3.3.1. Use the error summary with linked messages at each field: it is the only one that tells people at once how many problems there are, takes them to each, and still explains each field when they arrive, and the other two are each missing one of those. Naming the problems in the banner is a quick patch for a template you can't change yet. Focusing the first field is enough on its own only on a form so short that every field is in view.
Render the summary after the submission, not before. Don't keep an empty summary on the page, and don't update it on every keystroke. Build it once from the same list of errors the server, or your client-side check, returns, so the summary and the field messages can't disagree.
Move focus once. Focus the summary after the failed response has rendered, and not again while people are fixing things. Don't add role="alert" to a summary you also focus: screen readers would read it twice.
Tell people in the page title. On a full page reload, start the <title> with "Error:" ("Error: Sign up | Pottery studio"). Screen readers read the title first, so people learn the outcome before anything else.
Link to the field, and keep its label in view. A link to an input's id focuses the input, but some browsers scroll so the label sits above the top of the window, or under a sticky header. Give the fields scroll-margin-top larger than any sticky header, or handle the click in script and scroll the label into view. For a group of radio buttons, link to the first radio button and put the message inside the fieldset.
Say "Error:" in the field message. The word, visible or in visually hidden text, tells people who can't see the red that this is an error and not a hint. It also tells screen reader users why the field description has changed.
Keep the values. Return the entered values, except passwords and card numbers, so people correct the mistake rather than fill in the form again. For the wording of each message, see the guide on form errors.
Verify the fix
5 checks, no mouse.
Test with: Keyboard, Screen reader, Zoom
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat when fields are added or the shared form component changes.
Limits
This is a starting pattern, not a guarantee for every application. It covers how people learn which fields failed after a submission, not how each message is worded, nor errors in single-field searches, where focusing the field is enough. Forms built by third-party widgets, such as payment fields in an iframe, report errors their own way and need the same check. Test the complete journey with your target assistive technology.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.