WCAG 2.1 thresholds — three contexts, two levels
WCAG 2.1 ties the required contrast ratio to two variables: how large the text is and what tier of conformance you target. AA is the level most regulations (EAA, Section 508, JIS X 8341) actually require; AAA is a stricter ideal that pure-text content can hit but interface chrome rarely does. UI components and non-text visual indicators have a single AA floor of 3 : 1 and no AAA tier — the spec explicitly leaves that bar open.
| Context | When it applies | AA min | AAA min |
|---|
| Normal text | Under 18 pt regular or 14 pt bold — the default for body copy. | 4.5 : 1 | 7 : 1 |
| Large text | 18 pt regular or 14 pt bold and above — headings, call-outs. | 3 : 1 | 4.5 : 1 |
| UI components, graphics | Form borders, focus rings, chart strokes — anything that conveys state visually. | 3 : 1 | — |
How the contrast ratio is calculated
Contrast in WCAG 2.x is calculated from two colors' relative luminance — a perceptual approximation of brightness on a 0 to 1 scale. For each color, the sRGB channel values are divided by 255, then gamma-decoded (a piecewise function around 0.03928), then combined with the channel weights 0.2126 (R), 0.7152 (G), and 0.0722 (B) that reflect human eye sensitivity. The weight on green is highest because green-sensitive cones contribute most to perceived brightness.
The ratio itself is (L1 + 0.05) / (L2 + 0.05) where L1 is the brighter luminance. The 0.05 term is the spec's constant for ambient screen reflection — without it, a pure-black background against any non-black foreground would compute as an infinite ratio. Output ranges from 1 : 1 (identical) to about 21 : 1 (pure white against pure black on an idealized display). Anything in between is what the tool above prints.
Color vision deficiencies and what they mean for design
About 8% of men and 0.5% of women of European descent have some form of color vision deficiency, and the population breakdown varies by ancestry. The most common types and what they affect:
| Type | What changes | Frequency |
|---|
| Protanopia (red-blind) | L-cone missing — red appears dark; red/green and orange/yellow confuse. | ~1% male |
| Deuteranopia (green-blind) | M-cone missing — the most common type. Red/green confusion at normal brightness. | ~6% male |
| Tritanopia (blue-blind) | S-cone missing — rare; blue/yellow confusion. | ~0.01% |
| Monochromacy | No functional cones — perceives only luminance, no hue at all. | ~0.003% |
High contrast helps everyone but does not fix every issue. Two colors with identical luminance — "isoluminant" — produce a contrast ratio of 1 : 1 and are invisible to monochromacy entirely; for red-green deficiencies, certain red/green pairs at the same luminance look nearly identical. The lesson: hitting AA on a contrast ratio is necessary but not sufficient. Color choice and pairing matter on top.
Designing past the threshold: color is never alone
The strongest pattern is "color plus shape" — never encode information in color alone. A status badge that is "green for OK, red for error" should also carry an icon or a word. A required field should not just be red — it should be marked with an asterisk and described by an aria-required attribute. A chart line that is only distinguished by hue needs a label, a stroke pattern, or a direct annotation. These changes also help everyone reading on a black-and-white printout, in bright sunlight, or with a failing display backlight.
For interactive elements, contrast on the focus ring matters as much as contrast on the text inside. A button with great text contrast but a 1 : 1 focus ring is broken for keyboard users. Most design systems get this right for primary buttons and miss it on secondary or ghost variants — worth checking explicitly.
WCAG 3 and APCA — what is coming after 4.5 : 1
WCAG 2's contrast formula is widely criticized as a poor perceptual model — in particular, it overstates the readability of mid-grey body text on white and understates the cost of very light backgrounds. WCAG 3 (in working-draft status since 2021) proposes a replacement called APCA (Advanced Perceptual Contrast Algorithm) that produces a polarity-sensitive Lc value, not a symmetric ratio. The output ranges from about -108 to +106, with positive values for dark-on-light and negative for light-on-dark.
APCA is not yet a normative standard. For now AA/AAA on the WCAG 2.1 ratio remains the bar most regulations enforce, and this tool computes that ratio. When WCAG 3 finalizes, the recommended floors will be expressed as Lc values (e.g. Lc 75 for body text), and the relationship between the two systems will require designers to test both during the transition. Keep an eye on the WCAG working drafts and the apcacontrast.com reference if you want to track this.
How to use
Pick foreground and background colors (HEX or RGB), and the contrast ratio computes instantly per WCAG 2.1 relative-luminance formula. The result is a single number between 1.0 (no contrast — same color on same color) and 21.0 (black on white) with pass / fail badges against five thresholds: 3:1 (large text AA, UI components), 4.5:1 (normal text AA, large text AAA), 7:1 (normal text AAA). A live preview of sample text in both colors lets you see the rendered result alongside the math.
Reach for this when reviewing a design before handoff, picking a brand color that pairs with white or a dark background, debugging an accessibility audit finding ("foreground color does not have sufficient contrast"), or building a design system where every color combination has a defined readability tier. Designs that look "fine" on a calibrated display routinely fail WCAG on a sunny coffee shop laptop screen, which is exactly the situation accessibility standards are designed to handle. The tool runs in the browser using the WCAG 2.1 contrast formula; nothing is uploaded.
Examples
Brand teal on white — body text AAA
Input
foreground: #06B6A4
background: #FFFFFF
Output
Contrast: 2.51 : 1
Normal text AA (4.5): ✗ fail
Large text AA (3.0): ✗ fail
UI component (3.0): ✗ fail
A common teal brand color fails as body text on white — the saturation gives the *perception* of a strong color but the luminance is high (lots of green plus a bit of blue, both luminous). Designers reach for a teal because it feels "fresh" but a body-text use needs to be darkened to something like `#055F58` to reach AA. Keep the original teal for accents (icons, brand mark) where contrast rules are more permissive.
White on dark teal — body text AAA
Input
foreground: #FFFFFF
background: #055F58
Output
Contrast: 7.51 : 1
Normal text AA (4.5): ✓ pass
Normal text AAA (7): ✓ pass
UI component (3.0): ✓ pass
The inverse pairing — white text on a dark teal — comfortably clears AAA. Dark-on-light and light-on-dark are *symmetric* in WCAG (the ratio is the same regardless of which is foreground), which is why the same brand can have a complementary dark variant for hero sections and light banners.
Muted gray placeholder — fails everywhere
Input
foreground: #B0B0B0
background: #FFFFFF
Output
Contrast: 2.30 : 1
Normal text AA (4.5): ✗ fail
Large text AA (3.0): ✗ fail
A very common pattern: light-gray placeholder text on white. It *looks* like "soft, gentle" UI but is unreadable for users with low vision, low-end displays, or bright ambient light. WCAG 2.1 SC 1.4.3 requires placeholder text to meet 4.5:1 just like body text — many sites fail this. Use a darker gray like `#666666` (4.6:1) or `#595959` (7:1, AAA).
FAQ
What is "large text" in WCAG terms?
14pt (≈18.66px) bold or 18pt (≈24px) regular and above. The relaxed 3:1 ratio applies because larger glyphs are inherently more readable — strokes are thicker, anti-aliasing is less critical. Note this is the *rendered* size in CSS pixels, not the design pixel; users zooming in are already past the threshold. The exact threshold differs slightly across WCAG documents; the safest interpretation is the spec's "18pt or 14pt bold" wording.
AA vs AAA — which should my product target?
AA is the practical legal floor in most jurisdictions (EU EAA, US Section 508, UK PSBAR, Korea KWAA). AAA is "go above and beyond" and meant for content explicitly aimed at users with disabilities (government accessibility portals, healthcare info, civic services). Aim for AA on production UI; treat AAA as the bar for body text in long-form reading apps, accessibility-focused features, and any pattern that recurs site-wide. Going AAA everywhere often forces dull color palettes — the trade-off is real.
What about WCAG 3 / APCA?
WCAG 3 is in draft and will replace the 2.x ratio with APCA (Accessible Perceptual Contrast Algorithm), a perceptually-tuned formula. APCA scores correlate much better with actual readability across hues; the 2.x formula notoriously over-rates blue / black pairs and under-rates light yellow / white. WCAG 3 has been "in draft" since 2021 with no formal release date as of 2026, and the legal bar in every jurisdiction is still WCAG 2.1 or 2.2. Use this tool for the legal check; experiment with APCA via dedicated tools (apca-w3.com, apca-on-glasses extensions) for forward-looking design system work.
Does the contrast check handle color blindness?
Not directly — contrast measures luminance, which color-blind users perceive normally. The pairing that fails for color-blind users is **information conveyed by hue alone** (red error / green success badges with the same luminance). WCAG SC 1.4.1 ("Use of Color") covers that requirement separately; this tool does not flag it. Combine the contrast check with a color-blindness simulator (Chrome DevTools → Rendering → Emulate vision deficiencies, or sim.colourblindawareness.org) to cover both axes.
How does the formula actually work?
WCAG 2.1 defines **relative luminance** for each color: linearize each sRGB channel (gamma-correct from gamma-encoded to linear light), then weight `L = 0.2126·R + 0.7152·G + 0.0722·B` (the green coefficient is largest because the human eye is most sensitive to green). The **contrast ratio** is `(L_lighter + 0.05) / (L_darker + 0.05)`. The `+ 0.05` constant is empirical, approximating the effect of ambient light reflecting off the screen. The ratio is always ≥ 1.0 and ≤ 21.0. Black on white = 21.0, white on white = 1.0, identical colors = 1.0.
Why does the WCAG ratio sometimes contradict what I see?
Three reasons. **The formula is luminance-only** — it does not account for hue or saturation differences that the eye uses for legibility, so a blue / black pair can pass WCAG while looking muddy. **APCA solves this** (see WCAG 3 question above). **Display gamma varies** — a phone, a laptop, and a wall-mounted office monitor render the same hex differently. **Surround effect** — dark text on light surrounded by mostly-light page reads differently than the same pair surrounded by dark. WCAG approximates all of this with one constant. Use the number as a strict floor, then judge in the actual context.
Related concepts
WCAG (Web Content Accessibility Guidelines, W3C) is the international standard for web accessibility. WCAG 2.0 (2008) introduced the four POUR principles — Perceivable, Operable, Understandable, Robust — and the AA / AAA conformance levels. WCAG 2.1 (2018) added mobile and low-vision criteria; WCAG 2.2 (October 2023) added focus appearance, dragging movements, accessible authentication. The contrast requirement (SC 1.4.3 Contrast Minimum, SC 1.4.6 Contrast Enhanced) is one of about 50 success criteria, but the most cited because it is purely measurable.
The **contrast ratio formula** runs in three steps. (1) Linearize each sRGB channel — sRGB is gamma-encoded (the value 128 represents about 21.6% of full linear light, not 50%) so the channels are inverted through the sRGB transfer function. (2) Compute relative luminance with the weights `0.2126·R + 0.7152·G + 0.0722·B`, derived from CIE 1931 observer data and reflecting that human cones are most sensitive to green light. (3) Compute the ratio `(L1 + 0.05) / (L2 + 0.05)` with the lighter color on top. The constant `0.05` approximates ambient screen reflection. The output is bounded by 1.0 (no contrast) and 21.0 (theoretical black on white).
Three adjacent ideas frame accessibility work. **WCAG 3 / APCA** (draft, ongoing) will replace the 2.x ratio with a perceptual-contrast score. **Color-blind safety** is a separate axis — contrast measures luminance and color-blind users perceive luminance normally; what they miss is information conveyed by hue alone (covered by WCAG SC 1.4.1). **Focus visibility** (SC 2.4.7, 2.4.11) requires a focus indicator to have its own contrast against adjacent backgrounds — often missed because the focus state is checked in isolation, not against the actual rendered surround. Together these cover the visible-output side of accessibility; assistive-tech axes (screen readers, voice control, switch input) need separate attention.
