Glossary · Accessibility term

Error identification

Also called: Error messages

Error identification is the Level A rule that when your form rejects something, the page names the field that failed and says in text what went wrong. Both halves matter. The second is where most forms fall down. A red outline around the box carries the message in a colour some people cannot see, and it says nothing at all to somebody listening to the page. What the rule does not do is tell you where to put the message. A summary at the top of the form conforms as well as a line under the field, so the failure is almost never the placement. It is "Something went wrong" being the entire message. A second rule at Level AA then asks you to suggest the fix where the error was detected automatically and a fix is known, unless saying so would put the security or the purpose of the content at risk. A well-written message usually does both jobs in one sentence.

In practice

The rule bites wherever an error is automatically detected, and that is broader than it sounds, because a required field left blank counts as an input error too. So a form that quietly refuses to submit until you find the empty box has detected an error and described nothing. That is the whole failure.

Placement is free and wording is not. An error list at the start of the form and a message beside the field are both named as acceptable. Pick whichever suits the form. Spend the effort on what the sentence says. Naming the field, naming the problem and naming the fix in one line satisfies the identification rule and the suggestion rule together. That tends to happen on its own once the message is written for a person rather than for a log.

The part teams miss is announcement, and it is a separate rule with a separate test. Describing the error in text is 3.3.1. Making it available to assistive technology without the user going looking for it is 4.1.3, and what that rule asks for is a message a screen reader can present without focus moving to it. Moving focus is the other way of getting somebody's attention, and it sits outside that rule rather than inside it. Pick one and build it properly. Do both and you have two mechanisms pointed at the same sentence, which usually means hearing it twice.

Silently fixing the value is not a way out either. Where a page clamps an out-of-range number back inside the range, the person still has to be told that what they typed was not accepted, otherwise they leave believing the form took their number.

Why it matters

Forms are where accessibility stops being abstract. Plenty of failures cost somebody effort. A form failure costs them the task. The session ends, and in your analytics it looks exactly like every other abandoned session. So the failure that costs you money most directly is the one you never see in a report. There is a worse version of it. Somebody who hears nothing after pressing Submit presses Submit again, which is how a silent validation error turns into a duplicate order or a locked account.

Poor and better

"Invalid input" names nothing, describes nothing, and leaves somebody guessing which of eleven fields it meant. "Enter your date of birth as DD/MM/YYYY" names the field, the problem and the fix in one line, and it does the work of two rules at once.

Where this shows up on the site

Related terms

Knowing the word is the easy part.

Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.

Run the free scan