Color and meaning
Show status without relying on color
Build a status legend that pairs each color with a word and a distinct shape, then check visible text and programmatic labels as separate jobs.
A green dot and a red dot look clearly different to many people and nearly the same to others. Color vision differences, glare, display settings, and black-and-white printing can all remove the distinction. If a dot is the only thing that says whether a build passed, some readers never get the message.
The fix is redundancy. Keep the color, and add a word and a shape that each carry the meaning on their own. This guide builds a fictional legend, then checks the visible layer and the programmatic layer separately.
What the guidance asks for
The W3C explanation of use of color is about cases where color is the only visual means of conveying information or telling elements apart. It does not ask designers to remove color. It asks for an additional visual cue, such as text or a shape, so the information survives when color cannot be perceived. Contrast is handled by separate requirements.
Sources: W3C: Understanding Use of Color
Build the legend
List every status the interface can show. Give each one a word that cannot be confused with the others, and a shape whose outline differs, not just its fill. Then assign color as reinforcement. Use the same word and shape everywhere the status appears, including emails and exports.
| Status | Color | Shape | Visible word | Accessible name |
|---|---|---|---|---|
| Passed | Green | Check mark | Passed | Build status: Passed |
| Failed | Red | Cross | Failed | Build status: Failed |
| Running | Blue | Half-filled circle | Running | Build status: Running |
| Skipped | Gray | Horizontal dash | Skipped | Build status: Skipped |
Check the visible layer
View the legend and a real dashboard row in grayscale. Every status should remain distinct by word and shape. Next, cover the words and confirm the shapes still differ at the size you ship. Then cover the shapes and confirm the words read clearly on their own.
Grayscale is a fast way to spot color-only meaning, but it is not an audit. It does not measure contrast, does not cover hover or focus states, and tells you nothing about assistive technology.
Check the programmatic layer separately
Visible words help sighted readers. Screen reader users depend on what the accessibility tree exposes. Inspect each status with your browser's accessibility tools and confirm its name includes the status word. If an icon repeats visible text, hide the icon from assistive technology so the status is not announced twice. Then listen with a screen reader, because the tree view does not show how announcements sound in context.
Worked example: a fictional deployment table
A team's deployment table uses colored dots only, and in grayscale the red and green dots look like the same mid-gray. The team applies the legend above. A first draft used a filled circle for Passed and an outline circle for Skipped, but at 12 pixels in grayscale the two were hard to tell apart, so Skipped became a dash.
The visible check now passes. The programmatic check finds that each icon carries a title naming its color, so the status is announced as the color followed by the word. The team marks the icons as decorative, and the announcement becomes the status word alone.
Limitations
These checks cover one legend and the states you rendered. They do not establish conformance for a page, and they do not replace testing with people who rely on these cues. Shapes can become ambiguous at very small sizes, and words need translation and consistent wording across every place a status appears.