Skip to main content
Accessibility Field Guide

Color Contrast

Check whether text, icons, controls, and meaningful visual boundaries are easy to see before contrast becomes a late review finding.

Two people point at blue and green color swatches in a design book.
Photo: High Angle View of Men Discussing Colours for an Interior Project via Pexels — https://www.pexels.com/photo/high-angle-view-of-men-discussing-colours-for-an-interior-project-6322363/
View full screen Download image

Color contrast is one of the easiest accessibility issues to notice late and one of the cheapest to prevent early.

It shows up in quiet places: helper text, placeholder text, inactive-looking buttons, gray icons, chart labels, table borders, focus indicators, error messages, badges, and text placed over images.

The goal is not to make every interface loud. The goal is to make important information readable, controls findable, and states visible in the real conditions people use the screen in.

The common project moment

A screen looks polished in the design file.

The palette feels calm. Secondary text is soft. Disabled states are subtle. Status colors look coordinated. A hero image has white text over it. A dashboard uses light gray labels and thin chart lines.

Then the screen reaches review, QA, or production and someone asks:

Can people actually read this?

That question should not wait until the end. Contrast belongs in the same early pass as labels, headings, focus order, status messages, and color-only meaning.

Use this when

Use this page when a screen includes:

  • small text, helper text, placeholder text, captions, or metadata;
  • text over images, gradients, cards, tinted panels, or charts;
  • icon buttons, status icons, badges, tags, chips, or pills;
  • low-emphasis controls, disabled-looking actions, selected states, or focus indicators;
  • dashboards, tables, maps, reports, or other dense visual displays;
  • brand colors that are being used for body text, links, errors, warnings, or success states.

Start with the text people must read

Look first at the words someone needs to complete the task.

That usually includes labels, instructions, button text, links, values, errors, warnings, status messages, table cells, and confirmation text.

If the text is too light against its background, the screen may look clean but still be hard to use.

Do not only check the main body copy. Many failures hide in the smaller pieces that teams think of as secondary.

Check interactive things next

Controls need to be findable before someone can use them.

Check contrast for:

  • button text;
  • link text;
  • icon-only buttons;
  • selected tabs or filters;
  • toggles, checkboxes, radio buttons, and switches;
  • input borders and error borders;
  • focus indicators;
  • disabled or unavailable states.

A control that technically exists but visually disappears creates the same practical problem as unclear labeling: people cannot confidently tell what they can do.

Do not treat placeholder text as the label

Placeholder text is often low contrast by design.

That can be fine when it is only an example, but it becomes a problem when the placeholder is the only visible instruction or label.

If people need the text to understand the field, make it a real label or instruction with enough contrast.

Watch text over images and tinted backgrounds

Text over images is fragile because the background is not one flat color.

A heading may pass over the dark part of the image and fail over the light part. A caption may pass in the mockup but fail after the image changes.

Safer patterns include:

  • place text outside the image;
  • add a solid or semi-opaque background behind the text;
  • use a consistent overlay that is tested against the actual image;
  • avoid putting critical instructions on unpredictable imagery.

Check icons, borders, and visual boundaries

Contrast is not only about paragraphs.

People also need to perceive important non-text visual information: icons, button outlines, focus rings, input borders, selected states, chart lines, and meaningful separators.

If an icon communicates an action or state, it needs to be visible enough to notice. If a border is the only clue that something is an input field, the border needs enough contrast to be seen.

Pair contrast with color-only checks

Passing contrast does not mean the meaning is accessible.

A red error state might have enough contrast and still fail if red is the only thing identifying the problem. A green success badge might be visible and still unclear if the word “success” never appears.

Use contrast to make the cue visible.

Use Color-Only Meaning to make sure color is not carrying the whole message.

Charts, tables, and dashboards need extra care

Dense displays create contrast problems quickly.

Check:

  • axis labels and legends;
  • chart lines, bars, dots, and fills;
  • table header text;
  • sorted or selected column indicators;
  • status badges and risk colors;
  • row separators when they help people track across a row;
  • tooltip text and hover/focus states.

If a chart is published as an image, also check Alt Text Basics so the useful takeaway is available as text.

Questions teams can ask

Ask these before the screen goes to final review:

  • Which text is required to complete the task?
  • Which text is intentionally secondary, and is it still readable?
  • Are links visually distinct from surrounding text without relying on color alone?
  • Are icons, outlines, focus indicators, and selected states visible enough to notice?
  • Does any text sit on top of an image, gradient, or variable background?
  • Do brand colors pass when used for normal-size text?
  • Does the design still work in bright light, low-quality monitors, high contrast settings, or grayscale printing?

Common trail hazards

  • Testing only body text and missing helper text, captions, metadata, placeholders, and labels.
  • Assuming larger display text always passes because it feels prominent.
  • Using light gray text to make a screen feel calmer, then making instructions hard to read.
  • Treating disabled states as if they never need to be understood.
  • Placing text over photos without testing the exact image and crop.
  • Checking contrast in the design file but not after implementation changes font weight, size, background, or opacity.
  • Thinking contrast solves color-only meaning. It does not.

Small habit to build

When you review a screen, pick three things before you run any tool:

  1. the smallest text someone needs to read;
  2. the quietest interactive control;
  3. the most subtle state change.

If those three are visible and readable, the screen is usually on a better path.

Then use a contrast checker to confirm the numbers.

What to do next