Why does my translucent overlay text look fine in the design file but fail in the browser?
Design tools frequently report contrast against the raw swatch color, ignoring alpha. But browsers composite the layers, so the color a user actually reads is the blended result. The correct way to check it: effective color = foreground × alpha + background × (1 − alpha), applied per channel, then run the standard relative-luminance formula on that composited value.
A checker that parses rgba(), hsla(), and 8-digit hex (like #ffffffcc) directly can composite this automatically instead of forcing you to do the blend math by hand for every overlay variant.
Does switching to dark mode automatically fix low contrast?
A common dark-mode habit is taking a light theme's exact color tokens, flipping the background to near-black, and assuming the existing text/accent colors "will obviously be fine now." In practice, each pair needs its own independent check. A saturated brand color that was legible as body text on white (dark, low luminance, high contrast against a bright background) can become one of the weakest pairs in the whole theme once the background itself turns dark, because both colors now sit closer together on the luminance scale.
When does APCA disagree with the plain WCAG ratio, and why does it matter for dark mode?
WCAG 2's ratio is symmetric: swap the two colors and the number doesn't change. Real human perception isn't symmetric that way, especially for lighter-weight fonts on dark backgrounds, which is part of why some teams see a pair pass the classic 4.5:1 check and still get flagged as "hard to read" in dark mode by actual users. Checking the APCA Lc score alongside the WCAG ratio surfaces that gap instead of leaving it as an anecdotal complaint from your design team.
| Content type | Approx. minimum Lc |
|---|---|
| Body text | ~75 |
| Larger content text | ~60 |
| Large headings | ~45 |
A quick workflow for auditing a dark theme or glass UI
- List every real pair. Don't just check body text — separately check nav links, button labels, disabled-but-still-informative text, and icon-on-background pairs, since dark themes often forget the smaller elements.
- Enter alpha values as-is. If a token is defined as
rgba()or an 8-digit hex, paste it exactly rather than "simplifying" it to an opaque color first — the alpha is part of what makes it fail or pass. - Check both WCAG ratio and APCA. Treat a WCAG pass with a low APCA score as a signal to bump contrast a little further, not as a false alarm to ignore.
- Re-test after any lightness tweak. A single-step lightness shift to fix one pair can quietly break a different pair that shares the same token.
Paste rgba/hsla/8-digit hex colors directly, see the composited WCAG ratio and the APCA Lc score side by side, and preview the pair live — free, no signup.
Try the free Color Contrast Checker →Frequently asked questions
Why does my overlay text pass contrast in Figma but fail in the browser?
Design tools often show the flat swatch color, not what actually renders once a semi-transparent layer sits on top of a background. A translucent white overlay at 70% opacity over a photo does not have a single fixed contrast value — its effective color changes with whatever is behind it, so the same overlay can pass on a dark photo and fail on a light one.
How do I calculate the real contrast of a semi-transparent color?
Composite the translucent color over its background first: effective color = foreground × alpha + background × (1 − alpha), applied per RGB channel, then run the standard WCAG relative luminance formula on that composited result. This is what a color contrast checker with alpha (rgba/hsla/8-digit hex) support does automatically instead of making you calculate it by hand.
Does dark mode automatically fix contrast problems?
No. Flipping a light theme's colors to dark does not guarantee the new pair passes the same threshold, because contrast ratio is not simply inverted — a light gray that was borderline-compliant on white can become clearly non-compliant on near-black, or vice versa. Each dark-mode color pair needs its own independent check, not an assumption based on the light-mode result.
When should I use APCA instead of the WCAG 2 ratio for dark mode?
APCA is especially useful for dark mode because it accounts for polarity — light text on a dark background is scored differently than dark text on a light background, even at the same numeric WCAG ratio, which better matches how people actually perceive dark-mode readability. Checking both scores side by side catches cases where a pair technically clears the WCAG ratio but still reads as low-contrast in APCA's perceptual model.
What's a common dark-mode contrast mistake in real interfaces?
A frequent pattern (illustrative, not a universal rule) is reusing a brand accent color for both link text and button fills without re-checking it against the dark background — a saturated brand purple that reads clearly on white can turn muddy and low-contrast against near-black, especially for smaller link text, because its relative luminance sits much closer to the dark background's luminance than to white's.