3.3.1 Error Identification

When a form rejects what someone typed, everyone needs to know two things: which field is the problem, and what is wrong with it. This criterion protects screen reader users, who cannot see a red outline; people with colour vision deficiency, for whom a red border may look like every other border; people with low vision, who may miss a subtle visual change entirely; and people with cognitive disabilities, who need the problem stated plainly rather than inferred. It has been a Level A requirement since WCAG 2.0.

The auditor's mental model is a two-part test that only fires when validation fires. First, is the item in error identified, so the user can locate the exact field? Second, is the error described in text, so the user learns what is wrong (required field empty, date in the wrong format, value out of range)? Both parts must be satisfied in text. Colour, icons, or a border change alone satisfy neither part, and a generic "something went wrong" message fails the "described" part whenever the system knows which field and what rule was broken. Note the trigger: if the site performs no automatic validation at all, this criterion does not apply.

Passes:

• On submit, an error summary appears at the top of the form, receives focus, and lists "Email address: enter an address in the format name@example.com" with a link to the field, plus matching inline messages.
• An inline message "Enter a card expiry date in MM/YY format" rendered below the expiry field and linked to it with aria-describedby, with aria-invalid="true" on the input.
• An Android form using TextInputLayout.setError("Choose a password of at least 12 characters"): the text is visible, associated, and announced.
• An iOS form that posts an accessibility announcement "Phone number is required" on submit and leaves the same text as a persistent label under the field.

Fails:

• Invalid fields get a red border and nothing else: the error is conveyed by colour alone, with no text identifying or describing anything.
• A banner reading "Something went wrong, please check the form" when the system knows exactly which field failed validation: the item in error is not identified and the error is not described.
• Error text sits visually beside the field but is not associated with it and is never announced: a screen reader user hears only "invalid entry", or nothing at all.
• An app shows the only error message in a toast that disappears after two seconds, leaving no persistent text: sighted users may catch it, screen reader users routinely do not.

Not a fail under this criterion:

• The message says what is wrong but not how to fix it ("Date is invalid" with no format hint): identification and description are present; the missing fix belongs to SC 3.3.3 Error Suggestion.
• A field with no visible label or format instructions that users therefore get wrong: grade the missing guidance under SC 3.3.2 Labels or Instructions; 3.3.1 only judges what happens after detection.
• A correct, associated inline error that appears dynamically but is never announced as it appears: reachable text satisfies 3.3.1; the silent injection is an SC 4.1.3 Status Messages finding (weak implementations often fail both).
• A form that performs no automatic validation and simply accepts the input: there is no detected error, so the criterion does not apply.

• Error Suggestion, SC 3.3.3. The Level AA sibling asks whether known corrections are offered. 3.3.1 is identification ("Email address is invalid"); 3.3.3 is suggestion ("enter an address containing @"). A message can pass here and still fail there.
• Labels or Instructions, SC 3.3.2. 3.3.2 governs what users are told before they type; 3.3.1 governs what they are told after validation rejects it. A missing label is a 3.3.2 finding even if the error handling is exemplary.
• Status Messages, SC 4.1.3. 4.1.3 asks whether dynamically appearing messages are announced without receiving focus. An error that exists in associated text but is injected silently is a 4.1.3 finding; an error that exists in no reachable text at all is a 3.3.1 finding, and sloppy validation frequently earns both.
• SC 1.4.1 Use of Color. A red border as the only error signal fails 1.4.1 (colour as the sole visual means) and fails 3.3.1 (no text identification). File both, with the missing text as the 3.3.1 evidence.
• aria-invalid on its own. Marking a field invalid programmatically flags that an error exists but neither names it in visible text nor describes what is wrong. It is a useful supplement, not a substitute for a text message.

AUDITSU's audit walkthrough covers error identification on every screen that accepts input. The walkthrough prompts you to submit each form with empty and malformed values, record what appears, and answer per-screen questions: is the failing field identified in text, is the error described in text, and does a screen reader user actually receive it (checked with the screen reader running, on web and in apps). Each question is graded pass, fail, or not applicable per screen, with the error state captured as evidence, so a red-border-only form or a vanishing toast is documented against the exact screen and field.

For European audits, note that the European standard applies this requirement to web content and to software that supports assistive technologies, and separately requires closed systems to provide error identification non-visually, so kiosk-style products cannot rely on on-screen text alone. The walkthrough surfaces the right variant for the product type you are auditing.

For the full guided workflow, see the audit platform.