How should form errors use colour accessibly?

What the criteria ask of an error

Three WCAG 2.2 criteria meet at a form error. Criterion 3.3.1 Error Identification (Level A) requires that when an input error is automatically detected, the field in error is identified and the error is described to the user in text. The W3C is explicit that colour, images and other visual indicators are welcome in addition to the text, not instead of it. Criterion 1.4.1 rules out a red border or red label as the only sign of an error. And criterion 3.3.3 Error Suggestion (Level AA) asks that where a correction is known, it is suggested — 'Enter a date as DD/MM/YYYY' rather than 'Invalid'. Colour's role is to draw the eye to the problem quickly; the words do the work.

Choosing the error red

An error system needs one red that works in two roles: message text, which needs 4.5:1 against its background, and a field border or icon, which needs 3:1 under 1.4.11 if it is what shows the error state. Many forms also put the message inside a pale red tint, which lowers text contrast further. The table measures five reds against white and against a pale error tint (#FDECEA). Pure red sits just under 4:1 on white and lower still on the tint, so it can be a border but not message text; the lighter Material-style red passes on white but not on the tint. Darker reds around #C62828 pass as text on both. The simplest robust choice is one dark error red used for text, icon and border alike, which also keeps the error state unmistakable.

Layout: put the message where the eye already is

Place the error message directly below or beside the field, between the field and the next one, not in a summary at the top alone and not only in a tooltip. Start it with an icon that has a distinct shape (a warning triangle or an exclamation mark in a circle), since icon shape survives greyscale and colour-vision deficiency. Keep the field's label visible and unchanged, rather than replacing it with the error. For long forms, add an error summary at the top that links to each field in error, and move focus to it on submit; the summary is then the first thing a screen-reader or magnifier user meets. Keep the field's content; clearing what someone typed is one of the most frustrating errors a form can make.

Programmatic connection and timing

Visual design is half of an accessible error. The message must be programmatically associated with the field, typically with aria-describedby pointing at the message element, and the field marked invalid with aria-invalid="true", so a screen reader announces both the field and its problem. Validate on submit or when the user leaves a field, not on every keystroke; red text appearing while someone is still typing an email address is noise, and for people using screen magnification it can pull the view away from where they are working. When errors are fixed, remove the red styling and the message together, so the colour always means 'there is a current problem here'.

The data

What goes wrong, and what to do

How to check it yourself

1. Submit the form empty and with invalid data; every error should appear as text beside its field.
2. Check the error red against both white and the error tint in the contrast checker.
3. View the error state in greyscale and confirm each error is still obvious.

What the evidence says

Each statement is labelled by kind — established fact, a standard’s requirement, observed market data, a convention, or Colourwise’s own interpretation or analysis — with the strength of the evidence behind it.

• StandardStrong evidence

  WCAG 2.2 success criterion 3.3.1 Error Identification (Level A) requires that when an input error is automatically detected, the item in error is identified and the error is described to the user in text; colour or icons may be used in addition to the text.

  Source: Web Content Accessibility Guidelines (WCAG) 2.2; Understanding Success Criterion 3.3.1: Error Identification (WCAG 2.2)

• StandardStrong evidence

  The W3C's Understanding document for 1.4.1 gives required or error fields identified only by colour as a case that fails the criterion unless another visual cue, such as text or an icon, is added.

  Source: Understanding Success Criterion 1.4.1: Use of Color (WCAG 2.2)

• Colourwise analysisStrong evidence

  Pure red #FF0000 has just under 4:1 contrast on white and less on a pale error tint, so it can serve as a 3:1 border but not as error message text, whereas darker reds such as #C62828 pass 4.5:1 on both.

  Based on: Computed by Colourwise with the WCAG 2.2 contrast formula; see the table.

  Source: Web Content Accessibility Guidelines (WCAG) 2.2; Understanding Success Criterion 1.4.3: Contrast (Minimum) (WCAG 2.2)

Related questions

Should error messages be red?

Red is the expected convention and helps people find errors quickly, but it must be a red dark enough for 4.5:1 text contrast, and the message and an icon must carry the meaning without it.

Where should form error messages go?

Directly next to the field, usually below it, plus a linked summary at the top for longer forms. Tooltips alone are easy to miss and hard to reach by keyboard.

Should success states be green in forms?

Green confirmation is fine as reinforcement, but pair it with a tick icon or 'Saved' text, since green and red are the pair most likely to be confused.

Related topics

Go further

Sources

• Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative (WAI) (Official standard or government)
• Understanding Success Criterion 3.3.1: Error Identification (WCAG 2.2) — W3C Web Accessibility Initiative (Standards body)
• Understanding Success Criterion 1.4.1: Use of Color (WCAG 2.2) — W3C Web Accessibility Initiative (Standards body)
• Understanding Success Criterion 1.4.3: Contrast (Minimum) (WCAG 2.2) — W3C Web Accessibility Initiative (Standards body)

Reviewed 29 September 2026. Colourwise summarises its sources in its own words and does not reproduce standards text or proprietary colour data. Spotted an error? Tell us.