Getting color contrast for accessibility right is one of the cheapest wins in any design project. It costs nothing but attention, it makes text easier to read for everyone, and it removes a common reason a finished layout gets sent back for rework. This guide explains what the contrast rules actually say, how to check your work, and how to build contrast into your process so it stops being a last-minute fix.

What contrast means in practical terms

Contrast is the difference in perceived brightness between two colors, usually text and the background behind it. WebAIM explains that the Web Content Accessibility Guidelines (WCAG) express it as a ratio running from 1:1 (no difference) up to 21:1 (black on white). The same WebAIM guide notes that swapping the text and background colors does not change the result.

That last point matters in daily work. A pale blue button with white text and a white card with pale blue text have exactly the same ratio. If one fails, the other fails too.

The WCAG thresholds you need to know

Level AA is a sensible default target for most projects, and its core numbers are short enough to memorize.

Text contrast (Success Criterion 1.4.3)

According to the W3C explanation of Contrast (Minimum), normal body text needs a ratio of at least 4.5:1 against its background, and large text needs at least 3:1. That W3C page defines large text as at least 18 point, or 14 point when bold.

In plain terms, bigger and heavier letterforms are easier to read, which is why the W3C allows a lower ratio for large text.

Enhanced contrast (Level AAA)

If you are designing for long-form reading, consider the stricter AAA targets. WebAIM summarizes these as 7:1 for normal text and 4.5:1 for large text.

Non-text contrast (Success Criterion 1.4.11)

Contrast is not only about words. The W3C guidance on Non-text Contrast asks for at least 3:1 for the visual parts of interface components that people need to see to use them, such as input borders, checkbox marks, toggle states and focus indicators. It also covers graphical objects that carry meaning, like the lines in a chart or an icon with no text label.

A common failure here is the light gray form field border on a white page. It looks clean in a mockup, but on a real screen in a bright room the field can almost disappear. The fix is usually simple: darken the border, or add a subtle filled background to the field so its edges are easier to find. Check the result against the surrounding surface, not just the page background.

What the rules do not cover

Knowing the exceptions saves time in reviews. The W3C page on text contrast lists these cases with no contrast requirement:

• Incidental text, such as text in a disabled control, purely decorative lettering, or words that happen to appear inside a photo.
• Logotypes, meaning text that forms part of a logo or brand name.
• Invisible text that is not meant to be seen at all.

Treat these as narrow exceptions rather than loopholes. A disabled button still needs to be recognizable as a button, and a logo that doubles as a navigation link is still something people need to find.

Do not rely on color alone

Contrast has a close relative that trips up a lot of designs. The W3C guidance on Use of Color says color should not be the only visual way to convey information, prompt an action or tell elements apart.

In practice that means:

• Form errors should show a text message or an icon, not just a red border.
• Required fields need a label or symbol in addition to a color change.
• Charts should use labels, patterns or direct annotations, not only a color legend.
• Links inside paragraphs should be distinguishable by more than hue, which is why underlines remain such a reliable choice.

WebAIM points out that un-underlined links are tricky: to rely on color alone, a link needs enough contrast against the background and against the surrounding body text, plus a non-color cue on hover and focus. With some palettes, meeting all of those at once is not possible, so an underline is often the simpler answer.

How to check contrast during design

Checking is quick once it becomes a habit. Here is a workflow that fits most small teams.

1. Test the palette before the layout

Before you place a single component, pair every text color in your palette with every background it might appear on and record which combinations pass at 4.5:1 and which only pass at 3:1. That gives you an approved pairing list. Designers then pick from known-good combinations instead of testing every screen from scratch.

2. Use a dedicated checker

Paste hex values into a contrast checker, or use the contrast tools built into browser developer tools. WebAIM recommends verifying with these tools rather than trusting your eye, because perceived contrast changes with screen brightness and surrounding colors.

3. Never round up

The thresholds are hard limits. The W3C non-text contrast page notes that a computed value just under 3:1 fails, and WebAIM applies the same rule to text ratios just under 4.5:1.

4. Check every state

Hover, focus, active, visited and selected states are separate color combinations, and WebAIM notes that each state of text needs to meet the requirement on its own. A button that passes at rest but fades to a pale tint on hover has a problem.

5. Test the hard places

Text over photos, gradients and semi-transparent overlays is a frequent trouble spot. WebAIM suggests testing the lowest-contrast area of the background, because transparency lets underlying colors bleed through and lowers the effective ratio. A solid or darkened scrim behind the text is usually more dependable than hoping the photo cooperates.

Building contrast into a design system

One-off checks catch problems. A system prevents them. If your team keeps components in a shared library, contrast is easiest to manage at the token level.

• Name tokens by role, not shade. A token called “text-on-surface” can carry a note that it was tested against the surface color it is paired with. A token called “gray-400” tells nobody where it is safe to use.
• Document approved pairings. Keep a small table in your style guide that lists which foreground tokens pass on which backgrounds, and at which level.
• Define focus styles once. A single, high-contrast focus ring applied across components is easier to verify than dozens of custom treatments.
• Review brand colors early. Some brand palettes include mid-tone colors that may not pass as text on white. Decide up front whether those colors are for large display text, fills or accents only.

If you are formalizing this kind of documentation, our business systems articles cover how to turn one-off decisions into repeatable checklists.

A quick pre-handoff checklist

Before you hand a design to development or a client, run through this list. The numbers come from the W3C text contrast and non-text contrast guidance covered above.

• Body text meets at least 4.5:1 against its background.
• Large headings meet at least 3:1.
• Input borders, icons that carry meaning and focus indicators meet at least 3:1.
• Hover, focus and selected states have been checked separately.
• Text over images has a scrim or solid backing and has been tested at its weakest point.
• No information depends on color alone.
• Placeholder text is not being used as the only label for a field.

Why this belongs in your workflow, not your QA queue

Contrast problems found after development tend to mean rework across files and code, while problems caught at the palette stage are usually quick to fix. Treating color contrast for accessibility as a design input rather than a compliance check keeps projects moving and produces work more people can actually read.

Start small: test your current palette this week, write down the pairings that pass, and share that list with everyone who touches your files. That one document will prevent more back-and-forth than any late-stage audit.