WCAG Color Contrast Checker

WCAG Color Contrast Checker

Low contrast fails accessibility guidelines and users with low vision.

WCAG 2.1 sets specific minimum contrast ratios between text and its background: 4.5:1 for normal text at AA level, 3:1 for large text or UI components, and 7:1 for AAA compliance.¹ These thresholds exist because users with conditions like cataracts, low vision, or color deficiency depend on sufficient contrast to read text reliably. Checking contrast before committing a color pair to production code prevents the accessibility rework that follows an audit or user complaint.

How WCAG contrast is calculated

The WCAG relative luminance formula first linearizes each sRGB channel by reversing the gamma curve, then computes luminance as Y = 0.2126 × R + 0.7152 × G + 0.0722 × B. The contrast ratio between two luminances L1 and L2 is (L1 + 0.05) / (L2 + 0.05) where L1 is the higher value.¹ The 0.05 offset prevents division by zero at black and compresses the ratio at the ends. Consequently, black on white produces the maximum ratio of 21:1, while identical colors produce 1:1, representing zero contrast. Engineers working with the formula directly benefit from memorizing these three anchor points because every real-world contrast value falls somewhere between them.

Reading the WCAG levels

The tool shows contrast ratios for black text and white text placed on your selected color. WCAG defines three thresholds: AA requires 4.5:1 for normal text (below 18pt or 14pt bold) and 3:1 for large text or UI components. AAA requires 7:1 for normal text and 4.5:1 for large text.² The labels in the contrast panel follow this structure: "AAA" means both thresholds pass; "AA" means normal-text AA passes; "AA LG" means only the large-text 3:1 threshold is met; "Fail" means no threshold is reached. Building on this, the panel with the higher contrast ratio is the better text color choice for the selected background.

Beyond the ratio: practical contrast guidance

A passing contrast ratio is necessary but not sufficient. Very thin fonts need higher contrast than the WCAG minimum to remain readable at small sizes. Pure black on pure white passes AAA at 21:1 but can cause visual fatigue for some users, so off-white backgrounds pairing (#f5f5f5) at 17:1 are often more comfortable with no loss of accessibility. WCAG 2.1 contrast applies to text and meaningful images of text, while decorative elements and disabled UI components are explicitly exempt. Check contrast in the context of the actual rendering environment because ambient light, screen brightness, and font choice all shift the perceived ratio away from the abstract number.

WCAG 2.2 and the new target size criterion

WCAG 2.2 adds Success Criterion 2.5.8 (Target Size) which requires interactive targets to be at least 24 by 24 CSS pixels, with some exceptions for inline links and user-agent controls.² While this criterion does not directly affect color contrast, it interacts with it in practice: a button that passes contrast at its default size may fail when the touch target is enlarged with padding, because the padding area may have a different background color. Check contrast for the entire interactive area, not just the visible label.

Contrast requirements for focus indicators

WCAG 2.2 also strengthens requirements for focus indicators. A focus ring or outline must have a contrast ratio of at least 3:1 against the adjacent colors on both sides of the boundary.³ This means a blue focus ring on a white background needs to be dark enough to pass 3:1 against white, while the same ring on a dark background needs to be light enough to pass 3:1 against the dark color. Using oklch() to define focus indicator colors lets you set the L channel to a value that guarantees the 3:1 threshold against both your light and dark theme backgrounds.

The 3:1 rule applies to the outline itself, so a thin focus ring drawn in a mid-grey can quietly fail even when the surrounding button passes. Reading the indicator off the adjacent background on both sides is the part teams forget, because a ring that looks fine on the white card may vanish against the colored button it wraps. Setting the ring color from an OKLCH L value keeps the math explicit and lets a single token satisfy light and dark themes at once.

Testing contrast in OKLCH space before converting to HEX

You can estimate WCAG contrast directly from OKLCH L values before converting to HEX. The relative luminance formula in WCAG is a weighted sum of linearized RGB channels, and the OKLab L channel is already a perceptual lightness measure that correlates strongly with WCAG relative luminance.³ A quick check: if the L difference between two OKLCH colors is at least 0.4, the contrast ratio will likely pass AA for normal text. This is an approximation, not a substitute for the full WCAG calculation, but it is useful during design exploration when you are adjusting OKLCH coordinates and want immediate feedback.

Defining accessible token pairs in OKLCH

Defining accessible token pairs in OKLCH means choosing L values that guarantee the required contrast ratio before you commit the tokens to your design system. For AA normal text (4.5:1), ensure the foreground-background L difference is at least 0.4. For AAA (7:1), aim for at least 0.55. Store these as paired tokens: --color-text-primary at L=0.20 paired with --color-bg-primary at L=0.95 gives a contrast ratio above 15:1, well exceeding AAA. When you need to create a dark mode variant, swap the L values: --color-text-primary at L=0.90 over --color-bg-primary at L=0.12 preserves the same L difference and the same contrast ratio.

Common contrast mistakes with saturated accent colors

Saturated accent colors are the most common source of WCAG failures. A vivid lime like #c8ff00 has a relative luminance near 0.92, which means it passes contrast against black (1.6:1 against white, but 12.5:1 against black) but fails against white. Developers often choose accent colors for their visual impact without checking the contrast ratio against the background they will actually appear on. The fix is not to avoid saturated colors but to pair them with the correct background: use high-chroma colors on dark backgrounds and low-chroma, high-L colors on light backgrounds.

Using oklch() to find accessible variants of a brand color

When your brand color fails contrast on your target background, adjust its OKLCH L channel until the contrast passes. Reducing L from 0.96 to 0.75 on a lime green moves it from failing to passing AA against a white background, while keeping the same H and C preserves the brand hue identity. This approach is more reliable than adjusting HSL lightness because OKLCH L directly correlates with perceived brightness: a 0.1 L reduction produces a consistent perceived darkening regardless of the starting hue.⁴

When to use this

Use this when choosing foreground and background color pairs for text, buttons, form fields, or any UI element where accessibility compliance is required, so you can check a color pair against WCAG contrast before committing to production CSS.

Examples

#1a1a2e (text) on #f8f9fa (background)

14.5:1 — passes AAA for normal text

#c8ff00 (text) on #ffffff (background)

1.6:1 — fails all WCAG levels