# Error Identification: What WCAG 3.3.1 Actually Requires Beyond the Red Border

Source: https://accesswatchhq.com/blog/2026-11-14-error-identification-3-3-1-text-not-red-border.html

November 14, 2026

*A shopper submits a checkout form with one wrong field. The field gets a red border. Nothing else changes. A sighted user finds it in seconds. A screen reader user hears nothing, because the error was never identified in text, and the page fails WCAG 3.3.1 on a form that takes money.*

## What 3.3.1 actually asks for

WCAG 3.3.1, Error Identification, Level A, says that when an input error is automatically detected, the item in error is identified and the error is described to the user in text. The words matter: identified, and in text. A red border identifies the field to a sighted user and says nothing to anyone else. An icon does the same. The criterion is not about the visual design. It is about whether the user is told, in words, what went wrong and where.

The criterion sits next to two others that get confused with it. 3.3.3, Error Suggestion, Level AA, wants a suggestion for how to fix the error, where one is known. 3.3.4, Error Prevention, wants a review step for legal and financial submissions. A checkout form that flags the error in text, suggests the fix, and offers a review before payment satisfies all three. A form that turns a border red satisfies none of them, and the audit will say so in one line.

## The red border and nothing else

The failure mode is almost always the same. The form validation adds a class to the field, the class turns the border red, and the developer considers the job done. The error message exists in the code, usually as a string in the validation function, but it is never rendered into the page, or it is rendered in a tooltip that only appears on hover, or in a summary at the top that has no link to the field. The [error summary at the top of the form](2026-11-13-error-summary-top-form.md) only works when it links to the fields and focus moves to it, and the [inline error pattern](2026-11-12-error-identification-3-3-1-inline-errors-checkout.md) only works when the message sits next to the field it belongs to. Either one alone, done properly, passes. A red border alone never does.

Color is the other half of the failure. WCAG 1.4.1, Use of Color, says color must not be the only visual means of conveying information. Red means error only to a user who can see red and knows the convention. Add the message in text and the icon becomes decoration, which is fine. The message is the identification. Everything else is presentation.

## Where the text has to live

The error message belongs in two places at once. Inline, next to the field, connected with aria-describedby so the screen reader announces it when the user lands on the field. And in the summary at the top, as a link to the field, with focus moved to the summary when the form is submitted with errors. The inline message serves the user who is already at the field. The summary serves the user who submitted and needs to know how many errors there are and where they are. GOV.UK's design system documents this pattern precisely because it works: the summary lists each error, each one links to its field, and the order matches the order of the fields on the page.

Mark the field with aria-invalid true as well. It tells the screen reader the field has an error before the user even reaches the message. The three pieces together, invalid on the field, describedby pointing at the message, summary linking back, are the whole implementation. There is no fourth piece, and there is no shortcut that replaces any of the three.

## The test: submit empty, then submit wrong

Submit the form empty and count the errors the screen reader announces. Then submit it with a card number that is one digit short and listen for the specific message. If the announcement is a number of errors with no locations, the summary is broken. If it is silence, the inline messages are broken. If it is a red border and nothing else, the form fails 3.3.1, and the fix is text, not color. Two submits, two minutes, and the audit finding disappears.

## Frequently asked questions

### Does a red border around the wrong field count as identifying the error?

Yes, and it is the usual failure. WCAG 1.4.1 says color must not be the only way information is conveyed, and 3.3.1 says the error must be identified in text. A red border on its own fails both. Add the error message in text next to the field.

### What is the difference between error identification and error suggestion?

Identification says what is wrong. Suggestion says how to fix it. 3.3.1, Level A, requires identification. 3.3.3, Level AA, requires a suggestion where one is known. A message that says the card number is invalid identifies the error; one that says it must be 16 digits also suggests the fix.

### Is an error summary at the top enough on its own?

Only if the summary links to the fields and focus moves to the summary. GOV.UK's error summary pattern puts the summary at the top, lists each error as a link to the field, and moves focus to it on submit. A summary that sits at the top with no links and no focus move is decoration.

### Do I need aria-invalid if I already have an error message?

Yes. aria-invalid true tells the screen reader the field has an error, and aria-describedby points it at the error message text. Use both together: invalid marks the field, describedby delivers the message. Either one alone leaves half the information out.