WCAG Use of Color: Don't Rely on Color Alone

Colour can communicate quickly, but it cannot carry essential meaning by itself. A red dot might mean overdue, disconnected, or destructive. Someone who cannot distinguish it from a green dot, uses a monochrome display, or encounters a washed-out screen needs another way to understand the difference. The solution is not abandoning colour; it is making the information survive without it.

Separate meaning from visual emphasis

Inventory every place where colour changes an interpretation or suggests an action. Look for status indicators, selected filters, required fields, chart series, validation borders, and links embedded in paragraphs. Ask what would become ambiguous if all those colours looked alike. This is a more useful starting point than debating whether a particular palette feels accessible.

Use the contrast checker to test actual foreground and background combinations, including small badge text and hover states. Record the pair and the component state rather than a vague statement that “the green passed.” Contrast and meaning are separate checks: strong contrast does not make an unexplained coloured dot understandable.

The WCAG use of colour guidance requires a visible alternative when colour conveys information, indicates an action, or distinguishes an element. Screen-reader text alone does not solve that visual problem. A sighted person who cannot distinguish the colours still needs an observable cue.

Give statuses words and stable visual cues

Prefer a badge that says “Paid,” “Pending,” or “Failed” over a coloured circle with a tooltip. Visible status text provides an unambiguous interpretation and remains available on touchscreens, in screenshots, and when someone enlarges the page. A dot can remain as reinforcement, but it is no longer responsible for the entire message.

For dense interfaces, pair a consistent icon shape with a concise label. A check mark plus “Complete” differs structurally from a triangle plus “Needs attention.” Do not assume an unfamiliar icon is self-explanatory. Use the same wording across lists, detail views, exported reports, and notification messages so people do not have to relearn the vocabulary.

<p class="status status--failed">
<span aria-hidden="true">!</span>
<span>Payment failed</span>
</p>

<label for="email">Email address</label>
<input id="email" type="email" aria-invalid="true"
     aria-describedby="email-error">
<p id="email-error">Enter an email address with an @ symbol.</p>

Here, the exclamation mark is decorative because the text supplies the meaning. The error message also explains a repair, rather than merely declaring that something is red. Set aria-invalid when validation actually identifies an error, not on every untouched field at initial load.

Selected states need a similar review. A selected filter can use a check mark, an explicit selected label, or an appropriate native checked control. Apply programmatic state as well, such as aria-pressed for a genuine toggle button. Visible redundancy and accessible state solve different problems; neither should be treated as a substitute for the other.

Make chart series distinguishable without a palette key

Start with a question: what comparison should the reader make? If a chart answers “Which service is least reliable?” make service names and relevant values available near the data. A legend of five coloured squares forces people to repeatedly match colours and does not work when those hues are indistinguishable.

Use direct labels where space permits. For line charts, distinguish series with marker shapes or dash patterns as well as colour. For bars or areas, consider borders or patterns that remain understandable at the rendered size. Avoid patterns so dense that they turn into visual noise or disappear when the chart shrinks.

Do not encode critical values only in hover tooltips. Support keyboard interaction when points are interactive, and offer the same information on touch. A static chart may be better served by a concise text summary and an adjacent accessible data table than by hundreds of focusable points.

A useful summary describes the principal trend, units, time range, and noteworthy exceptions. “Revenue rose overall from January to June, with a decline in March” explains more than “Revenue chart.” A table supplies exact values for readers who need them. The WAI complex images tutorial explains how descriptions and detailed data can complement a visual presentation.

Check a chart against the non-text contrast guidance where graphical objects or controls are needed to understand the content. Not every decorative gridline needs the same treatment as an essential data boundary. Document what carries meaning before measuring arbitrary pairs of colours.

Keep links recognisable inside real content

The simplest robust default for inline links is a persistent underline. It distinguishes a link from surrounding prose before hover or focus. A colour-only style can make links disappear for readers who do not perceive that hue difference, even when the text itself has adequate contrast against the page background.

WCAG techniques describe a colour-based approach involving sufficient contrast against surrounding text and an additional cue on hover and focus. That approach is easy to implement incorrectly and can become fragile across themes. Underlines reduce that maintenance burden and keep the affordance visible on touch devices.

.article a {
color: #164b9b;
text-decoration: underline;
text-underline-offset: 0.15em;
text-decoration-thickness: 0.08em;
}
.article a:focus-visible {
outline: 3px solid currentColor;
outline-offset: 3px;
}

Test the actual background before adopting these example values. Distinguish a focus indicator from a hover treatment, and do not remove outlines without a reliable replacement. Link text must also explain the destination; styling “click here” cannot supply missing context. The WCAG interface guide connects these visual decisions with keyboard and naming requirements.

Review themes, forced colours and handoff rules

Create a review fixture containing every meaningful state beside its alternative cue. Include default, hover, focus, selected, invalid, disabled, loading, and success where applicable. State coverage catches failures that a single polished screenshot misses, particularly when themes use different background surfaces.

Inspect the fixture in grayscale as a quick ambiguity check, then use colour-vision simulations as an additional diagnostic. Neither proves accessibility. Test actual high-contrast or forced-colours settings too: backgrounds, shadows, and custom fills may disappear or be remapped. Native controls often retain useful platform behavior that custom drawings must recreate carefully.

Connect the findings to semantic component contracts rather than scattered overrides. For example, an error badge must always include text, and every chart series must have a non-colour identifier. The design tokens guide helps organise reusable values, while the accessibility category offers related testing practices.

At handoff, name the intended meaning, visible fallback, programmatic state, and tested colour pairs. That makes redundant encoding an acceptance criterion instead of a last-minute suggestion. Recheck those contracts when a redesign removes labels to save space or replaces underlines with subtle colour changes.

Key takeaways

• Pair meaningful colour with visible text, shape, pattern, or position.
• Check contrast independently from whether information survives without colour.
• Label charts directly and make exact data available when needed.
• Keep links recognisable and test all meaningful states across themes.