WCAG 3.3.1 Error Identification

Success criterion 3.3.1 makes sure people notice when a form was not accepted and know which field is wrong. Blind users do not see a red border, people with colour vision deficiency may not notice it, and people with cognitive disabilities may not understand an icon. In a shop, this is often the difference between a finished checkout and an abandoned cart. It is level A and appears in EN 301 549 as clause 9.3.3.1.

What the criterion requires

If an input error is automatically detected, then:

1. the item in error is identified, and
2. the error is described to the user in text.

An input error is information the user provided that is not accepted. That includes required information left out and information outside the required format or values. WCAG does not prescribe how errors are displayed. Telling the user how to correct the error is covered separately by 3.3.3 Error Suggestion.

Typical failures on an online shop

• an invalid field is only shown with a red border or a red icon, without text;
• the checkout reloads after "Place order" with no message, or only a generic "Something went wrong";
• a message appears at the top of the page but does not say which field is affected;
• card errors from the payment widget are shown as an image or disappear after a few seconds;
• error text is present visually but not connected to the field, so a screen reader user on the field does not hear it.

How to check it

Automated: our checker has no rule for this criterion. An automated scan does not submit your forms with wrong data, so this needs a manual check.

By hand: for each important form — sign-up, login, newsletter, contact, checkout, address book — submit it with required fields empty, then with wrong formats (email without @, short postcode, past expiry date). Confirm that every error is shown in text, names or points to the field, and is read by a screen reader when you move to the field.

How to fix it

• Show a text message next to each invalid field, for example "Email address: enter an address like [email protected]".
• Connect the message to the field with aria-describedby and set aria-invalid="true" on the field.
• For long forms, add an error summary at the top with links to the fields, and move focus to it after submit.
• Keep messages visible until the error is fixed; do not rely on colour or icons alone.

Related criteria

• 3.3.3 Error Suggestion — tell users how to fix the error.
• 4.1.3 Status Messages — announce errors that appear without focus moving.
• 1.4.1 Use of Color — colour must not be the only signal.

Frequently asked questions

Is a red border enough to show a form error?

No. WCAG 3.3.1 asks for the error to be described in text. Colour alone also fails 1.4.1 Use of Color. Add a message such as "Enter your postcode" next to the field.

Does 3.3.1 apply to empty required fields?

Yes. Information the page requires but the user leaves out counts as an input error, so an empty required field must be identified and described in text.

Does WCAG say where error messages must appear?

No particular display is required. Common good practice is a message next to the field, linked to it with aria-describedby, and a summary at the top of the form for long forms.