WCAG Color Contrast: The Complete Guide to Accessible Color Palettes

Roughly 300 million people worldwide have some form of color vision deficiency. Another 246 million have moderate to severe visual impairment. When you ship a color palette without checking contrast ratios, you're actively excluding a significant portion of your users — and potentially exposing your organization to legal liability under the ADA, Section 508, and equivalent laws in the EU and UK.

WCAG color contrast is not optional. This guide walks through everything you need to know: the exact requirements, how to calculate and test ratios, the most common mistakes designers make, and how to fix failing pairs without destroying your brand identity.

What WCAG Is and Why It Matters

The Web Content Accessibility Guidelines (WCAG) are published by the W3C and define the international standard for web accessibility. WCAG 2.1 is currently the most widely enforced version. WCAG 3.0 is in development and introduces a new contrast model (APCA), but 2.1 AA remains the legal baseline in most jurisdictions.

WCAG is organized around three conformance levels:

• Level A: Minimum accessibility — critical failures removed
• Level AA: Mid-range accessibility — the legal standard in most markets
• Level AAA: Enhanced accessibility — ideal for specialized accessibility-focused products

For contrast specifically, you'll primarily work with AA and AAA requirements.

Understanding Contrast Ratios

WCAG measures contrast as a ratio between the relative luminance of two colors. Luminance is calculated from the RGB values after gamma correction — it's a measure of perceived brightness, not just mathematical brightness.

The formula produces ratios from 1:1 (identical colors, zero contrast) to 21:1 (pure black on pure white, maximum contrast).

White — Luminance 1.0#FFFFFF Black — Luminance 0#000000

A white (#FFFFFF) background with black (#000000) text gives you 21:1 — the maximum possible ratio. Here's how the WCAG thresholds map to practical use:

Use Case	AA Minimum	AAA Target
Normal text (under 18pt / 14pt bold)	4.5:1	7:1
Large text (18pt+ / 14pt+ bold)	3:1	4.5:1
UI components and graphical objects	3:1	Not defined
Decorative elements	No requirement	No requirement

The distinction between normal and large text matters enormously in practice. A ratio of 3.5:1 fails for body text but passes for a large heading — so the same color pair can be accessible in one context and inaccessible in another.

The Most Common Contrast Failures

Gray-on-White Body Text

This is the single most common accessibility failure on the web. Designers choose a mid-gray for body text because pure black feels harsh, but they often go too light.

Gray — Exactly 4.5:1 on White#767676 Gray — Only 2.85:1 on White (Fails AA)#949494

#767676 on white is the lightest gray that passes AA for normal text — at exactly 4.5:1. Anything lighter than that fails. #6B6B6B gives you more headroom at 5.74:1 and is a better default for body text.

Linear's design system handles this well — their secondary text uses carefully calibrated grays that maintain contrast while still differentiating from primary text. GitHub's interface is another reference point: their text hierarchy maintains accessible ratios across all levels.

Light Text on Light Backgrounds (Card UIs)

Card-based UIs often use a slightly tinted background (e.g., #F8F9FA) with gray text. The small luminance difference between the card background and default gray text is enough to fail.

Example failure: #6C757D (Bootstrap's secondary gray) on #F8F9FA = 3.9:1. Fails AA for normal text.

Fix: Darken the text to #495057 (7.0:1 on #F8F9FA) or switch to a dark neutral (#212529 = 15.8:1).

Colored Text on Colored Backgrounds

Brand color combinations that look good together often fail contrast. A common example: using a medium blue brand color for links on a light blue background.

Blue-500#3B82F6 Blue-50 Background#EFF6FF

#3B82F6 on #EFF6FF = 3.1:1. Fails for normal text, barely passes for large text. The fix is usually to darken the text color: #1D4ED8 (Blue-700) on #EFF6FF = 6.9:1, passing AA and nearly reaching AAA.

Placeholder Text

WCAG 1.4.3 applies to all text — including form placeholder text. Designers routinely set placeholders to 40-50% opacity or a very light gray, which almost always fails. Minimum ratio for placeholder text: 4.5:1 against its background.

Focus Indicators

WCAG 2.1 requires that focus indicators (the ring that appears when you tab to a focusable element) have a 3:1 contrast ratio against adjacent colors. Many design systems use a thin blue ring that fails this requirement.

How to Calculate Contrast Ratios

The relative luminance formula:

L = 0.2126 × R + 0.7152 × G + 0.0722 × B

Where R, G, B are linearized values:

• If sRGB value ≤ 0.03928: C / 12.92
• If sRGB value > 0.03928: ((C + 0.055) / 1.055) ^ 2.4

The contrast ratio is then: (L1 + 0.05) / (L2 + 0.05) where L1 is the lighter color.

In practice, you won't calculate this by hand. Use:

• Browser DevTools: Chrome and Firefox both show contrast ratios in the color picker
• Our generator's Accessibility Pairs panel: Every generated palette automatically checks all foreground/background pairs
• axe DevTools browser extension: Audits an entire page for WCAG failures
• WebAIM Contrast Checker: Quick manual checks at webaim.org/resources/contrastchecker

Fixing Failing Pairs Without Destroying Your Brand

The instinct when a color fails contrast is to swap it for black or white — but that's usually overkill and breaks your brand identity. Here's a surgical approach:

Darkening in OKLCH Space

Never darken colors in HSL. The perceptual uniformity of OKLCH means that when you lower the L value by a fixed amount, the resulting color looks consistently darker across all hues — which HSL doesn't guarantee (yellows and greens appear significantly brighter than blues at the same HSL lightness value).

A good rule of thumb: if your foreground color fails on a light background, reduce its OKLCH lightness until the ratio reaches your target (4.5:1 for AA, 7:1 for AAA). This preserves hue and chroma, just making it perceivably darker.

Using Separate Light/Dark Variants

The most robust pattern is defining two variants of your brand color:

:root {
  /* Use on light backgrounds */
  --brand-on-light: oklch(0.38 0.18 264);   /* Dark enough for 4.5:1 on white */

  /* Use on dark backgrounds */
  --brand-on-dark: oklch(0.78 0.14 264);    /* Light enough for 4.5:1 on #111 */
}

Figma's design system uses exactly this pattern — their purple brand color has separate "on light" and "on dark" tokens that always meet AA requirements. Stripe's Rainier design system takes it further with explicit contrast-safe tokens for every usage context.

Separating Color from Contrast

For UI components like icon buttons, badges, and chips that use background colors, the text/icon on top needs to pass 4.5:1 (for text) or 3:1 (for icons). The easiest fix: always use white or very dark text on colored backgrounds, and calculate whether your brand color is dark enough to support white text.

White text needs a minimum background luminance that produces 4.5:1. Pure white has luminance 1.0, so: (L_bg + 0.05) / (1.0 + 0.05) ≥ 1/4.5, which gives L_bg ≤ 0.178. Any background with luminance above 0.178 fails for white text — and most mid-range brand colors fall above this threshold.

Quick test: If your brand color hex has individual RGB values mostly above 180, white text probably fails on it. Check with a tool.

WCAG 2.1 AA Compliance Checklist

Run through this for every new palette before shipping:

• All body text (under 18pt/14pt bold) achieves 4.5:1 on its background
• All heading text (18pt+ / 14pt+ bold) achieves at least 3:1
• All interactive UI components (buttons, inputs, checkboxes) achieve 3:1 for borders/backgrounds
• Placeholder text achieves 4.5:1 on its background
• Error states and validation messages achieve 4.5:1
• Focus rings achieve 3:1 against adjacent colors
• Disabled state text — WCAG 1.4.3 explicitly exempts disabled components, so this is optional
• Decorative images and elements — exempt, no requirement

WCAG 3.0 and APCA: What's Coming

WCAG 3.0 introduces the Accessible Perceptual Contrast Algorithm (APCA), which addresses known limitations of the 2.1 contrast formula. APCA is font-weight and font-size aware — the same ratio requirement doesn't apply to all text sizes. It also handles dark-mode combinations more accurately.

APCA is not yet a legal requirement anywhere, and WCAG 3.0 does not have a final release date as of early 2026. For now: implement WCAG 2.1 AA. When APCA becomes a standard, the changes for most well-designed systems will be relatively minor.

Building Accessibility Into Your Palette From the Start

The cheapest time to fix a contrast problem is before you ship the design. When you're generating a palette, start with your intended text/background pairs and calculate their ratios before choosing secondary and accent colors.

Our generator's Accessibility Pairs panel shows every foreground/background combination in your generated palette and flags failing ratios automatically. For palettes used in product UIs, treat any failing pair as a build-blocking issue — not a nice-to-have.

For inspiration on accessible color systems that still look beautiful, browse corporate palettes (which tend toward high-contrast by convention) and minimalist palettes (which rely on contrast rather than decoration for hierarchy). Also see our guide on dark mode color systems for contrast requirements specific to dark-theme UIs.

Key takeaways:

• WCAG 2.1 AA is the legal standard in most jurisdictions — 4.5:1 for normal text, 3:1 for large text and UI components
• The most common failure is mid-gray body text on white: #767676 is the absolute minimum
• Fix contrast by darkening in OKLCH, not by swapping to black/white
• Use separate "on-light" and "on-dark" brand color tokens
• Run audits before shipping — retrofitting accessible contrast is always more expensive than building it in