WCAG 3.3.1 Error Identification (level A) explained

What it asks for, in plain English

When a form catches a mistake, it has to tell the person which field has the problem and describe the problem in text. A red border, a shaking field or an icon on its own is not enough, because not everyone can see the colour or the movement.

The message should sit close to the field or clearly name it ("Email address: enter an address like name@example.com"). It also needs to reach people who cannot see the screen: link the message to the field with aria-describedby, mark the field with aria-invalid, and move focus to the first error or an error summary so a screen reader user knows something went wrong at all.

This criterion is about identifying and describing the error. Suggesting how to fix it is 3.3.3; the two are usually handled together.

This is an independent explanation. The binding wording is the W3C Recommendation, and the W3C's own Understanding 3.3.1 page has the full intent, techniques and definitions.

Who it affects

A screen reader user presses Submit, hears nothing, and the page simply reloads with a red border they will never see.

Someone with a colour vision deficiency cannot tell a red outline from the ordinary grey one, so cannot see which of eight fields is wrong.

A person with dyslexia needs the error explained in words beside the field, not an icon they have to decode.

Example

Broken

The only sign of the error is a red border. A screen reader announces: 'Postcode, edit text, SW1A'. Nothing is wrong, as far as it can tell.

Fixed

Announced: 'Postcode, invalid entry, edit text, SW1A, Enter a full UK postcode, like SW1A 1AA'. The summary at the top names the field and links to it.

Show the markup behind both examples

Broken

<style>body{margin:0;padding:16px;font-family:system-ui;font-size:14px}label{display:block;font-weight:600;margin-bottom:4px}input{font:inherit;padding:6px 8px;border:2px solid #9ca3af;border-radius:4px;width:200px}.err{border-color:#dc2626}button{font:inherit;margin-top:12px;padding:6px 12px}</style>
<form>
  <label for="pc">Postcode</label>
  <input id="pc" class="err" value="SW1A">
  <br>
  <button type="button">Continue</button>
</form>

Fixed

<style>body{margin:0;padding:16px;font-family:system-ui;font-size:14px}label{display:block;font-weight:600;margin-bottom:4px}input{font:inherit;padding:6px 8px;border:2px solid #9ca3af;border-radius:4px;width:200px}.err{border-color:#dc2626}.msg{margin:0 0 6px;color:#b91c1c}.summary{border-left:4px solid #b91c1c;padding:6px 10px;margin:0 0 12px}.summary a{color:#b91c1c}button{font:inherit;margin-top:12px;padding:6px 12px}</style>
<form>
  <div class="summary"><strong>There is a problem</strong><br><a href="#pc">Postcode: enter a full UK postcode</a></div>
  <label for="pc">Postcode</label>
  <p class="msg" id="pc-err">Enter a full UK postcode, like SW1A 1AA</p>
  <input id="pc" class="err" aria-invalid="true" aria-describedby="pc-err" value="SW1A">
  <br>
  <button type="button">Continue</button>
</form>

How to check it

Submit a form with a required field empty and another filled in wrongly.
Check each error is described in text next to the field, or in a summary that names the field, not just by colour or an icon.
Inspect the field: it should have aria-invalid="true" and aria-describedby pointing at the message, so a screen reader reads the error with the field.
With a screen reader running, press Submit and confirm the errors are announced or focus moves to them.

What Websight checks for 3.3.1

Websight has no automated check for this criterion. It lists it in the manual checklist that comes with every report, so it is not forgotten.

Websight can see when aria-describedby points at an id that does not exist and when ARIA attributes on a field are invalid. It cannot submit the form to see what happens, so whether errors appear at all, and whether they are in words, needs a person.

Practical tips

Put a summary of errors at the top of the form, link each one to its field, and move focus to the summary.
Keep the message beside the field as well; people fix one thing at a time.
Do not clear what the person typed when you show the error.

3.3.2 Labels or Instructions (level A)
3.3.3 Error Suggestion (level AA)
3.3.4 Error Prevention (Legal, Financial, Data) (level AA)
3.3.7 Redundant Entry (level A)
3.3.8 Accessible Authentication (Minimum) (level AA)