WCAG Contrast Checker

WCAG contrast in 2026 — the law, the math, and the patterns that pass

Web accessibility is no longer a moral nice-to-have. As of June 2025, the European Accessibility Act made WCAG 2.1 Level AA the minimum requirement for any digital product sold in the EU. The ADA Title III has carried similar weight in the US since the Robles v. Domino's settlement. Australia's DDA and Canada's AODA point at the same standard. The single most-checked WCAG criterion in compliance audits is 1.4.3 Contrast (Minimum) — the rule about color contrast. This guide walks through the math behind that rule, the thresholds you actually need to hit, the dark-mode and brand-color patterns that work in practice, and what the upcoming WCAG 3 / APCA shift will change.

The math, in plain English

WCAG 2.1 contrast is a ratio between the relative luminance of two colors. The four-step calculation:

1. Convert each sRGB channel from 0–255 to a 0–1 float.
2. Linearize: if the float is ≤ 0.03928, divide by 12.92; otherwise raise ((v + 0.055) / 1.055) to the 2.4 power. This undoes the gamma correction that displays apply.
3. Combine with the luminance weights: L = 0.2126·R + 0.7152·G + 0.0722·B. The green channel weighs more because human eyes are most sensitive to mid-spectrum light.
4. Add 0.05 to each color's luminance (the "Weber-Fechner" noise floor), then divide the larger by the smaller. The result is between 1:1 (no contrast) and 21:1 (pure black on pure white).

The 0.05 fudge factor exists because real screens have ambient reflectance — even pure black is not truly zero luminance. Without it, very dark colors would produce mathematically infinite contrast ratios that have no real-world meaning.

The thresholds — what each level demands

"Large text" in WCAG terms is 18pt or 24px regular, or 14pt or 19px bold. The thresholds drop because thicker strokes remain legible at lower contrast — but the visual angle matters more than the point size, so always verify on real devices and at user-zoom settings.

Where contrast applies — and where it does not

• Body text: 4.5:1 minimum (AA).
• Headings & large CTAs: 3:1 minimum (AA Large).
• Form field borders, focus rings, button outlines: 3:1 against adjacent colors (1.4.11).
• Meaningful icons (info, warnings, status): 3:1 against background.
• Decorative graphics & logos: exempt (1.4.3 explicitly).
• Disabled controls: exempt — but they need to clearly look disabled.
• Inactive parts of a logotype: exempt.
• Text in screenshots / illustrations when the user cannot interact with it: exempt.

The exemptions are narrower than people assume. "Hover state" is not an exemption. "Marketing page" is not an exemption. "It's our brand color" is not an exemption.

The legal landscape — who actually enforces this

Dark-mode contrast — not just "invert everything"

Inverting a light palette does not produce an accessible dark palette. Pure white text on pure black hits 21:1 but produces ghosting and halation for users with astigmatism. The well-tested dark-mode pattern:

• Background: not pure black. Use #0d0f11 or a very dark navy / charcoal so OLED screens still feel comfortable.
• Body text: not pure white. Use #e5e7eb or similar — pulls the contrast down to ~16:1, easier on the eye.
• Muted text: watch the contrast carefully. #9ca3af hits 4.5:1 on near-black; anything lighter starts to fail.
• Accent colors: brand colors that hit AA on white may fail on dark backgrounds. Often you need a slightly lighter "dark-mode variant" of each brand color.

Brand colors that do not pass — what to do

Every team eventually faces the conflict: marketing wants the brand teal at #3DD9D6, but it fails AA on white. Three patterns that work:

1. Dual brand palette: one set for backgrounds and decoration, one set (slightly darker) for text. This is how Stripe, Vercel, Linear all handle it.
2. Use the brand color on dark backgrounds. A bright teal that fails on white usually passes on near-black. Re-architect the layout so the brand color becomes a background, not text.
3. Pair with text shadow / outline. WCAG does not specify how the contrast is achieved — a 1 px outline in the opposite color can rescue a borderline pair. Used sparingly, this works for marketing headers; do not rely on it for body text.

The APCA / WCAG 3 shift — what is changing

The luminance ratio formula has known weaknesses: it overrates very-bright yellows on white (which actually look low-contrast) and underrates dark navy on black (which actually reads well). APCA — the Accessible Perceptual Contrast Algorithm — corrects both. APCA produces a signed lightness contrast value (typically −108 to +106) and prescribes thresholds that vary with font weight and size, not a single 4.5:1 cliff.

As of May 2026, APCA is in candidate-recommendation status for WCAG 3 with no firm ratification timeline. Practical advice: hit WCAG 2.1 AA for legal compliance today. If you have headroom, also test with an APCA tool (apcacontrast.com) so your palette future-proofs.

Tooling beyond this checker

• axe DevTools / Lighthouse: automated audits inside Chrome. Catches contrast issues across the whole page.
• Stark (Figma plugin): contrast and color-vision-deficiency simulation at design time.
• WebAIM Contrast Checker: the canonical reference implementation; cross-check anything legally important.
• Polypane: dev browser that shows contrast for every text element in the viewport simultaneously.
• Chrome DevTools "Issues" panel: surfaces contrast warnings while you debug.

Best WCAG contrast checker for 2026 — what to compare

Search results for "color contrast checker" surface a dozen tools that look identical on the surface. They differ on three things that matter: whether they run client-side, whether they support the AAA threshold and 1.4.11 non-text contrast, and whether they suggest a passing variant when your pair fails. Here is how the most-used contrast tools compare in 2026:

How do I check WCAG color contrast online without uploading my designs?

Every contrast check on this page runs in your browser using the W3C luminance formula — no color is sent to a server, no design file is uploaded, no account is required. Open the tool, paste any two hex codes (or use the native color picker), and the ratio updates as you type. The same is true of WebAIM's Contrast Checker, axe DevTools (which runs in your local Chrome), and Chrome DevTools' built-in color picker. Avoid tools that require uploading a Figma file or signing into a cloud workspace if you are checking unreleased brand colors or unannounced product designs.

What's the minimum color contrast ratio for ADA compliance?

The ADA itself does not specify a contrast number. US case law (Robles v. Domino's, Gil v. Winn-Dixie) treats WCAG 2.1 Level AA as the de-facto standard for ADA Title III compliance, which means 4.5:1 for normal text and 3:1 for large text (18pt regular or 14pt bold and above). Non-text UI components — form borders, focus rings, icon meaning — need 3:1 against adjacent colors under WCAG 1.4.11. Federal procurement (Section 508) references WCAG 2.0 AA, which has the same contrast numbers. If you ship to the EU, the European Accessibility Act enforces WCAG 2.1 AA via EN 301 549 as of June 2025 — the same 4.5:1 / 3:1 thresholds apply.

WCAG contrast checker alternative to WebAIM — 4 reasons people switched

WebAIM's Contrast Checker has been the canonical reference for over a decade, and it is excellent for what it does. The reasons developers move to alternative tools:

1. Auto-suggest passing variant. WebAIM offers a manual lightness slider; this tool walks HSL lightness automatically until your pair crosses 4.5:1, then returns the nearest passing hex.
2. 1.4.11 non-text contrast badge. Modern audits flag form borders, focus rings, and icon meaning under criterion 1.4.11. A dedicated 3:1 badge separates that check from the text thresholds.
3. Live preview at both text sizes. Some pairs pass AA Large but fail AA Normal; rendering both sample sizes side-by-side surfaces the failure mode immediately.
4. Copyable contrast report. One click copies a hex/hex/ratio block to the clipboard for design-system docs, tickets, or PR descriptions.

Pair the checker with the Color Palette Picker when designing accessible palettes from scratch, the Hex to RGB / HSL Converter for token math, and the in-depth WCAG 2.1 AA Implementation Guide for the wider compliance story.

Common contrast mistakes

• Testing only the default state. Hover, focus, disabled, and selected states each need their own contrast check.
• Forgetting placeholder text. The default browser placeholder grey (~#999) fails AA on white in every browser. Always override it.
• Putting text on hero images without an overlay. Text contrast against a photo is whatever the photo happens to provide. Add a dark gradient overlay or text shadow.
• Trusting Figma's contrast indicator on tinted backgrounds. If you compose layers with opacity, the rendered color is not what either layer reports. Test the final composited color.
• Treating focus rings as decorative. Focus indicators are required (criterion 2.4.7); contrast 3:1 with the adjacent surface is required (1.4.11). Removing the default outline without replacing it is an accessibility violation.
• Relying on color alone for status. Red error / green success works for sighted users without color blindness; everyone else needs an icon or text label too.