WCAG 3.3.1 Error Identification

What it asks

Forms check what people enter: a required field left empty, an email address with no @, a date in the wrong form. When the site detects a mistake like that, this rule asks for two things. The field in error must be identified, and the error must be described in text. A red outline identifies the field for someone who can see colour and nothing else. "Enter a valid email address" beside the field, and connected to it in the code, does both jobs for everyone.

Text is the point. A screen reader cannot read a border, a shake or a colour. The description has to be text, and it has to reach the person: visible on the page, and associated with the field through its label, aria-describedby or an error summary that links to the field. Marking a field with aria-invalid tells assistive software something is wrong but does not say what, and on its own it fails.

The criterion applies only to errors the site detects automatically. It does not ask the site to catch every possible mistake. It is Level A, and it is one of the criteria that cannot be tested without actually making a mistake, which is why so many audits leave it as a gap.

Its official name is success criterion 3.3.1 Error Identification, at Level A. It was added in WCAG 2.2, under guideline 3.3 Input Assistance and the principle Understandable. The W3C’s normative text says, in part:

“If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.”

From WCAG 2.2, W3C. Full explanation: Understanding 3.3.1 Error Identification.

Who it helps

Screen reader users, who hear nothing when a border turns red. People who cannot distinguish red from the other colours on the page. People with low vision, for whom a thin coloured outline is easy to miss.

People with cognitive disabilities, who need to be told plainly which field needs attention and why, rather than being left to hunt for the problem.

What passes and what fails

These pass

• A message "Enter your email address" under the empty field, linked to it with aria-describedby, with the field marked aria-invalid="true".
• An error summary at the top of the form that lists each error as a link to its field, with the message repeated beside the field.
• A field whose label is updated to read "Date of birth: enter a date in the past", read out together with the field.
• A password rule shown as text when the password does not meet it.

These fail

• A red border and nothing else.
• An error icon beside the field with no text, or with text only in a tooltip on hover.
• An error summary at the top of the form that does not say which fields are wrong.
• aria-invalid="true" set on the field with no message anywhere.
• An error that appears visually but is announced to nobody and connected to no field.

How to test it by hand

1. Find every form on the pages in scope: search, contact, sign-up, checkout, settings.
2. Submit each one with deliberate mistakes: required fields empty, a bad email address, a date in the wrong form, a password that breaks the rules. Use a test account or test environment where a real submission would have consequences.
3. For each error the site shows, check that there is text saying what is wrong, and that it is clear which field the text belongs to.
4. In the browser’s developer tools, check that the message is associated with the field: through the label, through aria-describedby, or through an error summary that links to it.
5. Where you can, repeat with a screen reader and listen for the message when the field receives focus.

What automated testing can decide

What a machine can decide

Once a form has been submitted with bad data and the errors are showing, a tool can read the result. It can find fields marked invalid, look for a text message, and check whether that message is associated with the field in the code. On pages that load already showing an error, it can do that without submitting anything.

What it cannot

Getting to the error state is the hard part. A tool that reads the page as it loads never sees an error message, because none is showing yet. Reaching one means filling in the form and submitting it, and submitting a real form can create records, send messages or spend money. Whether the message actually describes the error, rather than just saying "Invalid", is a judgement about words.

How Dreven handles it

Dreven never submits a real form without your say-so, and never takes a step that spends money or makes a commitment on a live site.

For each error state the audit reaches, you see which fields were marked as wrong, what text appeared and a picture of the form as it looked, and a reviewer decides whether the text describes the error. A form whose error state was not reached is listed as untested, so it never reads as a pass.

No automated check makes a site conform. In Dreven, a person reviews the results and signs the report.

Related criteria

• 3.3.3 Error Suggestion (Level AA). When the site knows how to fix the mistake, it must say so.
• 3.3.2 Labels or Instructions (Level A). Good labels and instructions prevent many errors before they happen.
• 1.4.1 Use of Color (Level A). An error shown only by colour fails this criterion too.
• 4.1.3 Status Messages (Level AA). An error message added to the page without moving focus needs to be announced.

Questions people ask

All WCAG 2.2 criteria, in plain words