Skip to main content

Contrast Checker

What it does

The Contrast Checker compares any two colours against the WCAG 2.1 luminance ratio — the same standard browsers, screen readers, and accessibility audits use to decide whether text is legible. The result is a number with pass or fail markers for each WCAG threshold, so an opinion (“does this look readable?”) becomes a verdict (“4.7:1, passes AA for body text, fails AAA”).

Common situations

You’re rebranding a 200-page site and need to verify every primary text-on-background combination still passes WCAG AA before launch. Manually checking the most-used pairings here removes the most common audit finding before it lands in front of anyone.

You’re settling a design review where two stakeholders disagree on whether a button colour reads. A measured ratio ends the debate in a way “I think it looks fine” cannot.

You’re auditing a competitor’s site or a piece of marketing creative and want to know whether their accessibility posture is real or aspirational. Sampling their colours into the checker (paired with the Colour Picker From Image) tells you whether their stated commitment to accessibility is reflected in the rendered pixels.

You’re handing over a design system to a client and need to certify, with evidence, that every documented colour pairing passes AA. The output here is the right artefact to ship as part of that handover — every pairing, ratio, and pass/fail status, captured.

What you need to know

WCAG measures contrast as the ratio between the relative luminance of two colours. The brighter colour goes on top of the formula, the darker on the bottom, and the result is a number between 1.0 (no contrast — same colour) and 21.0 (pure black on pure white). The thresholds are:

  • 4.5:1 — minimum for body text under WCAG AA
  • 3:1 — minimum for large text (18pt+ regular or 14pt+ bold) under AA
  • 7:1 — recommended for body text under AAA
  • 4.5:1 — minimum for large text under AAA

The reason large text gets a softer threshold is that letterforms with more pixels per character remain readable at lower contrast — there is more visual information per glyph. AA is the standard most legal accessibility frameworks treat as the floor: the UK’s Web Content Accessibility Regulations, US ADA case law, and EU EN 301 549 all reference WCAG AA. AAA is aspirational and rarely required outside of healthcare and government work.

The luminance formula is sRGB-aware and applies a gamma correction before the ratio calculation, which means visually-darker hues do not always produce mathematically lower luminance. A bright yellow can have a luminance value above 0.9 despite reading as “warm and saturated” rather than “almost white”. This is why eyeballing contrast fails: the calculation captures perceptual brightness in a way casual judgement does not.

WCAG 2.2 (the current standard as of late 2025) carries the same contrast requirements as 2.1. WCAG 3 introduces APCA — a more sophisticated perceptual algorithm — but it is still in working draft and not yet legally referenced. For practical work in 2026, the 2.1 ratios are what audits and browsers measure.

Frequently asked questions

What contrast ratio do I need for accessibility?

4.5:1 is the floor for body text under WCAG AA, the standard most legal frameworks reference. 3:1 is the minimum for large text (18pt+ or 14pt+ bold). For AAA conformance, the equivalents are 7:1 and 4.5:1.

What counts as “large text” in WCAG?

18pt regular or 14pt bold — roughly 24px and 18.6px in CSS terms. Anything smaller falls under the body-text rules, regardless of how visually prominent it might be.

Does WCAG contrast cover icons and graphics?

No — icons, charts, and graphical interface elements have their own rule (WCAG 1.4.11), which requires only 3:1 against adjacent colours. The body-text 4.5:1 rule applies only to text, not to all visible elements.

Why is my colour combination passing the contrast check but still hard to read?

Contrast ratio captures luminance, not colour-blindness, font weight, or rendering quality. A pair can pass 4.5:1 yet remain hard to read for some colour-blind users, or at very thin font weights, or with subpixel rendering on certain screens. Contrast is necessary but not sufficient for legibility.

How is WCAG contrast different from APCA?

APCA (the algorithm being developed for WCAG 3) accounts for font weight and size as part of the calculation, where WCAG 2.x treats them as separate threshold tiers. APCA is more accurate perceptually but is not yet a legal standard. Use WCAG 2.x for compliance work; APCA is currently advisory.

Is contrast measured against the rendered colour or the source colour?

Source colour. The ratio calculation works on the declared CSS values, not on what the screen actually emits after gamma adjustment, anti-aliasing, or device colour profiles. This is intentional — the standard cannot account for every display, so it standardises on the input.

Do I need to check text on background images?

Yes, but the calculation is harder — you need to check against the most adverse pixel under the text, not the average colour of the background. The standard practice is to apply a semi-transparent overlay or solid colour band behind text on top of imagery, then check against that.

Can I use opacity to fail-fast through contrast checks?

No. WCAG calculations apply to the rendered colour after opacity is composited. A 50% opacity dark-grey text on a light background produces a lighter rendered grey, with a lower contrast ratio. Always test against the apparent colour, not the source.

Common problems

Problem: A pairing that passes the checker fails an automated accessibility scanner like axe or WAVE.

The scanner is reading the computed colour after CSS rules have applied. A semi-transparent text colour, a parent element with opacity, or a CSS filter can change what the scanner sees. Inspect the element in DevTools, copy the computed colour, and re-test against that — not against the colour declared in your stylesheet.

Problem: Brand colours fail AA at 4.5:1 and the brand team will not budge.

The fix is rarely the brand colour itself — it is the pairing. A brand primary fails as text on white but passes as text on a darker background tint. Or the brand primary is fine for large text and the body copy uses a near-black variant. Document the pairings that work; do not rewrite the brand.

Problem: Contrast looks fine in design tools but fails in production.

Design tools render in sRGB; some browsers and some displays apply additional gamma or P3 colour-space transforms. The fix is to test against the actual rendered output: load the page in the target browser, sample the rendered pixels with the Colour Picker From Image, and verify those values pass.

Problem: A 4.6:1 ratio passes AA but feels marginal.

Treat anything between 4.5 and 5.0 as “just” passing. Small font weight changes, subpixel anti-aliasing variations, and minor colour-profile drifts can push real-world rendering below the threshold. Aim for 5.5+ on body text where you can; reserve marginal pass values for large or display text.

Tips

  • Lighten the lighter colour first when fixing a failing pair. Darkening the darker colour usually shifts the brand more visibly than nudging the background.
  • The check is symmetric — the ratio between two colours is the same regardless of which is “foreground” and which is “background”. Foreground/background are labels for the preview, not for the maths.
  • WCAG contrast says nothing about colour-blindness simulation. Two colours with high luminance contrast can still be unreadable for some forms of colour blindness. That is a separate check.
  • Run every documented brand pairing through the checker, not just the obvious ones. Footer text on tinted backgrounds, button labels on hover states, and disabled-element styling are where most audit failures hide.
  • Save contrast results as a small spreadsheet alongside your brand guidelines. New designers joining mid-project benefit from “here are the pairings that work” more than from “here are the rules — figure it out”.

Related tools in this suite

The natural pairing is the Colour Palette Generator — build a palette around a base colour, then run every pair you intend to use through the contrast checker before locking it in. The Colour Picker From Image is what you reach for when auditing existing creative — sample colours straight off the artwork rather than retyping hex values.

What this looks like at scale

Manually checking pairings is fine for a brand refresh or a single page. For an entire site, the WP Beacon Plugin audits every page on every visit and flags contrast failures across the whole content set — including the ones content editors introduce after launch. That is the right tool when “is this site accessible?” needs to stay answered, not just answered once.

Take it further

If a quick check has surfaced enough failures to suggest a wider audit is needed, the accessibility work in our services is where that lands — turning a list of failing pairings into a concrete remediation plan with deadlines and owners.