Understandable · 3.3 Input Assistance
When an input error is detected automatically, the item in error must be identified and the error must be described to the user in text. A color change or border alone is not enough; the text should say what is wrong.
Live demo
The same task, done two ways: switch between the version that passes and the one that fails, or put them side by side. Everything in the box is live, so try it with a keyboard, a pointer or a screen reader.
Leave Full name empty, type an email address without an @, and press Continue to payment. Compare how each version tells you what went wrong.
The tools follow the version you last used.
What happened
Why it passes
Each field in error gets a message in words, a screen reader reads the message with the field, and focus moves to the first problem.
Why it fails
The wrong fields only turn red. A screen reader user, or someone who cannot see red, is not told that anything is wrong or which field to fix.
Examples
Four examples, each one running: the usual ways this criterion fails, and code that passes. Listen to them, measure them, or copy the code.
Fails
Live preview
<label for="email">Email address</label><input id="email" name="email" type="email" value="sam.example.com" style="border: 2px solid #d32f2f"><button type="submit">Continue</button>The red border is the only sign of the error. A screen reader user, or someone who cannot see red, is not told that the email address is wrong or what is wrong with it.
Passes
Live preview
<label for="email">Email address</label><input id="email" name="email" type="email" value="sam.example.com" aria-invalid="true" aria-describedby="email-error"><p id="email-error" class="error">Error: This email address is missing the @ sign.</p>The message says in words what is wrong. aria-describedby makes a screen reader read it with the field, and aria-invalid marks the field as invalid (ARIA21).
Fails
Live preview
<p class="form-error">There is an error in the form.</p><label for="name">Full name</label><input id="name" name="name" autocomplete="name"><label for="phone">Mobile number</label><input id="phone" name="phone" type="tel" autocomplete="tel" value="98765">The message does not say which field is wrong or what the problem is, so the user has to check every field to find it.
Passes
Live preview
<div class="error-summary" role="alert"> <h2>There are 2 problems with your details</h2> <ul> <li><a href="#name">Enter your full name</a></li> <li><a href="#phone">The mobile number must be 10 digits</a></li> </ul></div>Each problem is described in text and linked to its field. When script adds this summary after a failed submit, role="alert" makes screen readers read it at once (ARIA19).
Why it matters
Screen reader users, people who cannot perceive color, and people with cognitive or learning disabilities need to know that an error occurred, where it is, and what went wrong. A text description makes errors perceivable and understandable.
W3C: Understanding 3.3.1Level A
Level A is the minimum: failing it can shut some people out completely.
Where it is required
Required where the law names WCAG 2.0 or later at this level: the United States, Canada, the European Union, the United Kingdom, France, Germany, Italy, Spain, the Netherlands, Ireland, Norway, Switzerland, India, Japan, Australia, New Zealand and Israel.
How to test
A few concrete steps. Automated tools find some failures; most need a person.
Common failures