# Error Identification 3.3.1: Inline Errors Screen Readers Actually Find

Source: https://accesswatchhq.com/blog/2026-11-12-error-identification-3-3-1-inline-errors-checkout.html

November 12, 2026

*When a shopper submits a form with an error, the error has to be identified in text, attached to the field it belongs to, and announced to a screen reader. A red outline alone fails WCAG 3.3.1. So does an error summary at the top of the page that never moves focus.*

## The red border that says nothing

Submit a checkout form with a bad email address and watch what happens. The field gets a red border. Maybe a small icon appears. If you can see the screen, you know something is wrong, and you can probably guess which field it is. If you cannot see the screen, you hear nothing. The screen reader does not announce a border color. It does not announce an icon. It announces the field, and the field has no error attached to it. That is a WCAG 3.3.1 failure, Error Identification, at Level A, the most basic level in the standard, and it ships on most storefronts.

The criterion asks for three things. The error is identified in text, not only in color or shape. The text is associated with the field, so the screen reader announces it when the field has focus. And the user is told the error exists, which in practice means focus moves to the first error, or the error is announced through a live region. A form that does one of the three is still failing.

## The wiring that passes

The reliable pattern is aria-describedby. The error message sits in an element with an id, and the input carries aria-describedby pointing at that id. When the field gets focus, the screen reader reads the label, then the error. The message itself states what is wrong and what to fix: "Enter an email address in the format name@example.com", not "Invalid input". The first error on submit gets focus, so a keyboard user lands on the problem instead of hunting for it.

Two mistakes undo this. The first is clearing the error the moment the user starts typing, before they have read it, which leaves the screen reader announcing a field that was just in error and now is not, with no explanation. The second is an error summary at the top of the form that lists every problem but never moves focus there, so a keyboard user has to discover it by tabbing backward. Fix both and the form works for everyone, including the sighted shopper who was guessing from a red border a minute ago. The same forms fail in other ways too: [shoppers typing the same address twice](https://accesswatchhq.com/blog/2026-11-11-redundant-entry-3-3-7-checkout-retype.md) and [the 24-pixel rule and its five exceptions](https://accesswatchhq.com/blog/2026-11-11-target-size-2-5-8-24-pixel-exceptions.md).

## Frequently asked questions

### Is a red border enough for error identification?

No. WCAG 3.3.1 requires the error to be identified in text. Color alone is also a 1.4.1 failure, since some users cannot perceive color differences. The message has to be words, attached to the field.

### Should the error message say what to fix?

Yes. The error text should name the problem and the fix: the format expected, the field that is empty, the value that is out of range. A message that only says error is identified, but the user still cannot fix it.

### Where should focus go after a failed submit?

To the first field with an error, or to an error summary at the top that then links to each field. Focus must move somewhere the user can act on; leaving it on the submit button forces a hunt.

### Does aria-describedby work for all screen readers?

It is the standard mechanism and is supported by the major screen readers when the id reference is correct and the message element is present in the page. Test with the actual combination your customers use, not only in an automated scan.