WCAG Contrast Ratio for Text

Stripe keeps brand blue away from long-form body copy. Their product pages use vivid blue (#635BFF) for accents and actions, but paragraph text sits at #3C4257 on white — a 10.0:1 ratio. That split keeps the brand recognizable without forcing blue to do a reading job it was not designed for.

Amazon uses orange as an action signal, not as paragraph text. Orange buttons (#FF9900 text on dark) can work because they are large, bold, and surrounded by neutral surfaces. The same hue at 14px on white scores only 2.1:1 — a hard fail. Amazon's body text uses #0F1111 on white (18.9:1).

Spotify dark surfaces need lighter text than designers expect. A dark UI can look premium, but gray-on-black labels fall apart fast. In a 12-swatch audit I ran for music-app style screens, labels below 60% OKLCH lightness failed more often than brand accents. Spotify uses #FFFFFF on #121212 (18.7:1) for primary text and #B3B3B3 on #121212 (8.9:1) for secondary — both passing comfortably.

Linear uses only three text shades. Their design system restricts text tokens to high (14.7:1), medium (7.2:1), and subtle (4.8:1). No text token falls below AA. By limiting the palette to three tiers instead of letting designers pick arbitrary grays, every combination is pre-validated.

GitHub Primer publishes its token hexes, so you can verify them yourself. Their fg.default (#1F2328 on white) computes to 15.8:1. Their fg.muted (#59636E) computes to 6.1:1. The lesson is the headroom: even the token explicitly named "muted" in a mature design system sits well above the 4.5:1 line, not on it. If your muted token measures 4.6:1, you have no margin for a tinted card background — see the surface drift section below for why that matters.

The readability budget I use before shipping:

Brand color audit — popular SaaS text contrast scores:

Every top-performing SaaS uses near-black body text. Nobody ships brand-colored paragraph copy. The brand lives in accents, icons, and interactive elements — never in reading text.

APCA vs WCAG 2 — font-weight-aware contrast (preparing for WCAG 3.0):

WCAG 2 treats all text the same regardless of weight. A 300-weight caption and a 700-weight heading at the same size get the same 4.5:1 requirement. APCA (Accessible Perceptual Contrast Algorithm), the contrast model for the upcoming WCAG 3.0, fixes this by accounting for font weight, size, and polarity (light-on-dark vs dark-on-light).

Here is how the same color pair performs under both models:

Key insight: WCAG 2 lets #6B7280 pass at 4.6:1 for body text, but APCA flags it as unreadable at normal weight. Teams that target APCA Lc 75+ for body copy today will not need emergency fixes when WCAG 3.0 becomes enforceable.

Practical font-weight contrast budget (use now, future-proof for WCAG 3.0):

Apply these now as internal design-system guardrails. When WCAG 3.0 finalizes, your tokens will already comply.

Two failure modes account for most of the muted-text and link problems I find in audits. Neither shows up when you test a token against white, which is why both survive design review. Every number in this section is computed from the WCAG 2.x relative-luminance formula and is regenerated by npm run verify:contrast on each build.

Finding 1: surface drift is a fixed divisor, not a per-token effect

When you move dark text from white onto a tinted surface, the ratio does not drop by some unpredictable amount. For any text darker than both surfaces, the new ratio is exactly the white ratio divided by the surface's own contrast against white:

ratio(text, surface) = ratio(text, #FFFFFF) / ratio(#FFFFFF, surface)

I verified this across 7 text tokens × 9 surfaces. Maximum deviation was 3.6e-15 — floating-point noise. The identity holds because the +0.05 flare constant cancels when both terms share the white reference.

That gives you a single divisor per surface, and a threshold you can memorize instead of re-measuring:

The practical rule: a muted token needs 5.6:1 on white to be safe everywhere in a Tailwind-style neutral system. Not 4.5:1. The 4.5:1 token is only legal on the one surface you tested it against.

Here is what that does to the default Tailwind gray ramp. Every gray loses the same 19% of its ratio moving from white to gray-200, but only one of them crosses the AA line on the way:

gray-500 on white is the single most common muted-text token in modern web UI, and it is 0.33 above the line. One tinted card is enough to break it. Swap muted text to gray-600 (#4B5563) and the entire problem disappears with no visible design cost.

Semantic tokens have the same trap, because alert text usually sits on its own tint:

The -600 step of each semantic hue fails on its own tinted background. Use the -700 step for text inside alerts and keep -600 for icons and borders, which only need 3:1 under SC 1.4.11.

Finding 2: for most body-text colors, no color-only link is mathematically possible

SC 1.4.1 says a link inside a paragraph must be distinguishable by something other than color alone — or, if you rely on color, it needs 3:1 against the surrounding text. SC 1.4.3 separately requires the link to hit 4.5:1 against the background. Teams treat these as two checkboxes. They are actually a constraint system, and it is often unsatisfiable.

A link darker than the body text is out immediately: with body at #374151, a link 3:1 darker would need negative luminance. So the link must be lighter than the body copy. Set it exactly at the 3:1 separation threshold and its best possible ratio against white is:

Solving 1.05 / (3 × (L_body + 0.05)) ≥ 4.5 gives the exact cutoff: body text must measure at least 13.5:1 against white for any color-only link to exist. That is roughly #2E2E2E. Any body color lighter than that, including the very popular gray-700 (#374151), makes the requirement unsatisfiable regardless of which hue you pick.

Running the full Tailwind blue ramp against a #111827 body confirms how narrow the window is even when it does exist:

Exactly one shade out of the ramp works, and only against near-black body text. Move the body to #374151 and every single blue fails.

So stop trying to solve this with color. Underline your in-paragraph links. The underline satisfies SC 1.4.1 through a non-color cue, which frees the link color to be chosen purely for the 4.5:1 background requirement. This is why every publication that takes reading seriously underlines body links: it is the only approach that is provably compliant across the full range of body-text colors.

Keep text-decoration: underline on links inside prose. Reserve color-only link styling for navigation, cards, and button-like elements, where the link is not embedded in a run of text and SC 1.4.1 does not apply the same way.

Validate your own token pairs with the Contrast Checker. For the same drift problem on dark surfaces, where the divisor works in the opposite direction, see WCAG Contrast Checker for Dark Mode. For alert and validation tokens specifically, see Form Validation Color Accessibility. For the full picture across forms, charts, and palettes, start at the Color Accessibility Hub.

Hero text sitting on a photo is the one case where contrast cannot be read off a token table. The background is thousands of different pixels, so the ratio changes per letter. WCAG still applies: SC 1.4.3 is measured against the actual backdrop behind the glyphs, which means the worst-case pixel decides whether you pass.

I recalculated every number in this section with the WCAG relative-luminance formula, compositing the overlay onto the image the way a browser does (source-over on sRGB values). The results contradict the most common design-system default.

White text over a black scrim — measured ratios by overlay opacity

The columns are the image pixel underneath the scrim. #FFFFFF is the worst case (blown-out sky, snow, a white product shot); #808080 is mid-gray.

The finding that matters: rgba(0,0,0,0.4) is the most common hero scrim in the wild, and it fails. At 40% over a bright pixel, white body text lands at 2.85:1 — below the 3:1 large-text floor and well below the 4.5:1 body-text requirement. Even 50%, the other popular default, only reaches 3.98:1 over white. It still fails AA for normal-size text.

Minimum black-scrim opacity to actually pass, by worst-case pixel:

Round up, do not round down. Use 55% for large hero headlines and 60% for any body copy over an uncontrolled image. If that looks too heavy for the art direction, change the composition — do not thin the scrim.

Gradient scrims fail at the top, where the text usually starts

The linear-gradient(transparent, rgba(0,0,0,0.7)) pattern is popular because it looks refined. The problem is that the effective opacity only reaches the full 70% at the very bottom edge:

A caption whose first line sits in the upper half of that gradient is reading at 1.5–2.4:1. Measure a gradient scrim at the topmost text baseline, not at the bottom of the element. The fix is a two-stop gradient that starts at a non-zero alpha: linear-gradient(rgba(0,0,0,0.55), rgba(0,0,0,0.75)).

The inverse pattern: dark text on a white scrim

Over dark photography, a light scrim with near-black text often looks better and passes more easily. #111827 text over a white scrim on a dark photo measures 5.23:1 at 50% opacity, 6.99:1 at 60%, and 9.11:1 at 70%. A 60% white scrim clears AA for body text with headroom.

Things that do not count as contrast

text-shadow and -webkit-text-stroke improve perceived legibility, but no WCAG 2.x success criterion gives you credit for them — the ratio is still computed from the text color against the backdrop color. Treat them as a bonus on top of a compliant scrim, never as the mechanism that gets you to 4.5:1. Same for backdrop-filter: blur() — blurring a bright image leaves it bright, so the luminance barely moves. Pair blur with an opaque tint if you want it to do accessibility work.

Safe pattern: put the scrim on the text container, not the image

.hero { position: relative; }
.hero img { width: 100%; height: 100%; object-fit: cover; }

/* scrim sized to the copy, so opacity can be high without
   flattening the whole photograph */
.hero__copy {
  position: relative;
  background: linear-gradient(rgba(0,0,0,0.55), rgba(0,0,0,0.75));
  padding: 2rem;
  color: #fff;
}

/* video needs the same treatment, plus a paused-frame check:
   the worst-case pixel may only appear mid-playback */
@supports (backdrop-filter: blur(8px)) {
  .hero__copy { backdrop-filter: blur(8px); }
}

Audit workflow for text over media

Screenshot the rendered hero, then sample the lightest pixel that falls directly behind a glyph — not the average of the image. Paste that hex and your text color into the Contrast Checker and read the ratio. For video, pause at three or four frames and repeat, because a single bright frame is enough to fail the criterion. If the image is user-uploaded or CMS-driven, you cannot audit your way to safety: enforce a minimum scrim opacity in the component so an editor cannot ship an unreadable hero.

For the token-level version of this rule, see Accessible Color Token System. For the same problem in dark interfaces, see WCAG Contrast Checker for Dark Mode. For pairings that survive busy backdrops, see High Contrast Color Combinations.