Red for error and green for pass, with nothing else distinguishing them, fails accessibility outright
Aliases: WCAG use of colour · accessible status indicators
What it is
Interface status cues of the "red = error, green = pass" kind, where colour is the only distinguishing means, are not merely a taste problem but a compliance failure: WCAG explicitly requires that colour never be the only visual means of conveying information (the Use of Colour provision). Dashboard status dots, form validation outlines, and problem rows highlighted in red all fall under this whenever removing the colour removes the status.
Why it happens
The compliance logic continues the same chain as the previous two cards: colour-deficient readers never receive the hue difference, so the information does not exist for them — which violates an accessibility baseline, not an aesthetic preference. The screen-reader case is stricter still: colour never enters the accessibility tree, so a purely chromatic status is invisible to assistive technology. The provision therefore seals both routes: human degradation (colour deficiency, glare, monochrome print) and device degradation (screen readers). This is also why pure colour indicators almost always ship with an icon or text — that is compliance, not styling.
Where it stops holding
The requirement targets colour carrying information, not colour itself: decorative colour, or colour added atop a status already carried by text or icon, is fully compliant. It also does not demand an icon per state — a positional convention (error text below the input) plus wording satisfies it; what matters is that the status remains decidable without colour or icons. Test the shipped interface, not the design file: a red annotation frame in the mock that survives only as a colour change in production breaks compliance.
Applying it
- Inventory every "colour changes only" status expression and attach a second channel to each: icon, text label, border style, or positional convention — at least one.
- Form validation gets error text and ARIA attributes alongside the red outline; dashboard dots get shape or text; flagged table rows get a marker column, not just a fill.
- Verification: convert interface screenshots to greyscale and hand them to testers — every status must remain decidable; then run a screen reader across the flow and confirm status changes are announced.
Related
- Same group: U4.05.1 Print, glare, and colour deficiency all strip colour · U4.05.3 Colour should reinforce, never solely carry, information · U4.05.5 Verify alternatives at design time, not after feedback
- Nearby: U4.04.1 Red-green combinations fail for a substantial share of viewers · U4.06.5 Semantic colour needs a text label to be judged on its own
- Search terms:
WCAG use of colour·status indicator accessibility·screen reader status
Cards in the same group
- U4.05.1Black-and-white printing, glare, and color blindness each strip color from a chart in their own way
- U4.05.2Lightness, shape, pattern, and a direct label can each carry what color alone was supposed to
- U4.05.3Position, shape, and text should build the chart's structure; color should only speed up reading it
- U4.05.5Checking a chart in greyscale belongs in design review, since fixing it after launch costs far more