WCAG 3.3.1, the Error Identification criterion at Level A, is short: if your site automatically detects a mistake in what someone entered, it must show which field has the problem and describe the problem in text. A red border, a shake animation or a small warning icon on its own is not enough.
Forms are where users get stuck most often in audits. This page shows what a passing message looks like, how to wire it up in HTML so assistive technology hears it, and how to test it in a few minutes.
Quick facts
Level
AAdded in
WCAG 2.0Applies when
The site itself detects an input error, on submit or as the user typesMust do
Identify the field in error and describe the error in textCommon failure
Red outline only, or one generic message at the topHelps
Screen reader users, color blind users, people with cognitive disabilities
The two jobs of a WCAG 3.3.1 error message
The criterion boils down to two duties, and a message must do both:
- Identify the item. The user must be able to tell which field is wrong. Placing the message beside the field and connecting it in code usually covers this.
- Describe the error in text. Words such as "Enter an email address in the format name@example.com" tell the user what happened. Color, icons and sounds can add to this but cannot replace it.
The rule only applies to errors your site detects automatically. It does not require you to catch every possible mistake, and it says nothing about when you validate. Checking on submit and checking as the user leaves a field can both pass. You can read the W3C Understanding text for Error Identification for the official intent.
Weak and strong error messages compared
| What the user sees | Result | Why |
|---|---|---|
| Field border turns red, no text | Fails | Color only; nothing is described and screen readers announce nothing |
| A red exclamation icon with no text alternative | Fails | The icon has no words, so the error is not described |
| "There were errors in your form" at the top only | Fails | Neither the field nor the problem is identified |
| "Required" under the empty Name field | Passes | Field identified by position and code, problem described |
| "Date of birth: enter it as DD/MM/YYYY with a four digit year" | Passes | Names the field and the expected format |
A summary box at the top listing each problem with a link to its field is a good extra, especially on long forms. It works best combined with messages next to each field.
Code example: tie the message to its input
Put the error text in an element with an id, point to it from the input with aria-describedby, and set aria-invalid so screen readers say "invalid entry".
Fails: the only signal is a CSS class that paints the border red.
<label for="email">Email</label>
<input id="email" type="email" class="error-border">Passes: the problem is in text and linked to the field.
<label for="email">Email</label>
<input id="email" type="email" aria-invalid="true" aria-describedby="email-err">
<p id="email-err">Enter an email address like name@example.com</p>When the user fixes the value, remove the message and set aria-invalid back to false or delete it.
Testing error identification
- Open the form and press submit straight away. Every required field should now show its own text message.
- Fill fields with wrong values on purpose: an email without the @ sign, letters in a number field, a password that breaks the stated rules.
- Check each message on screen. Does it say which field, and does it say what is wrong in words?
- Turn on grayscale in your operating system or take a black and white screenshot. Is the error still obvious?
- Open developer tools and confirm the input has
aria-invalidand thataria-describedbypoints to the message. - Use a screen reader, tab into the broken field and pay attention: the announcement ought to include the label, the word "invalid" and the message.
Check what happens to focus after submit. Sending it to the first field in error, or to an error summary, saves screen reader users from hunting for the problem.
Who is helped by clear error text
Blind users get nothing from a red outline; they need words that their screen reader can speak. People with color vision deficiency may not see red at all, especially red against grey. Users with learning or memory disabilities need the message to be specific and to stay on screen while they correct the entry.
Clear errors also cut abandoned checkouts and support calls for everyone, which is why this is one of the quickest wins in a form audit.
Where 3.3.1 ends and other criteria begin
- The labels criterion, 3.3.2, prevents errors in the first place with clear labels and format hints.
- 3.3.3, at Level AA, goes one step further: when you know how to fix the error, say how.
- 3.3.4, also AA, covers legal, financial and data deletion forms, which need review, confirm or undo.
- The color criterion (1.4.1) fails separately when red is the only sign of an error.
- The status message rule, 4.1.3, applies when you announce an error count without moving focus.
- Structure in code (1.3.1) expects the message to be connected to its field in code.
Questions people ask
What does WCAG 3.3.1 require?
When your site detects an input error automatically, it must point out the item in error and describe the error to the user in text. Both parts are needed.
Is a red border enough for error identification?
No. A red border gives no description and depends on color. Add a short text message next to the field and connect it with aria-describedby.
Do I have to validate every field?
No. The rule applies only to errors you already detect. If you choose to check a field, the result must be shown in text and tied to that field.
Does browser built in validation pass 3.3.1?
The native messages from the required attribute and type email are shown as text and linked to the field, so they often pass. Their wording and display vary by browser and they vanish quickly, so many teams prefer their own messages.
Should the error message appear on submit or while typing?
Either can pass. Messages that appear while someone is still typing can be distracting, so many teams check when the user leaves the field and again on submit.