Check text contrast over a gradient the way WCAG actually applies: at the weakest point the text touches, not the average. The checker samples 21 points along the gradient, reports the worst ratio and where it occurs, and suggests fixes when any point fails.
Settings
Generated locally in your browser — your settings and results never leave this page.
Contrast on a moving target
Text over a gradient has no single background — it has a background per letter. WCAG’s logic is unambiguous about such cases: the requirement applies where contrast is worst, because users read the hardest spot, not the average. Eyeballing gradients systematically fails at this (the worst point is often mid-blend, precisely where attention is not), so this checker makes it mechanical: sample the gradient densely, measure text contrast at each point, report the minimum and its location.
Why middles betray
The counterintuitive failures cluster mid-gradient. Interpolation in sRGB between two saturated, passing endpoints can sag through washed-out mid-tones several contrast steps below either end — white text happy on both vivid ends of a blue-to-pink blend hits a pale lavender middle at 3:1. The interpolation-space selector matters for the same reason: in oklab gradients travel different paths than sRGB ones, so the worst point moves. Check the gradient you actually ship, in the space you actually declare.
The remediation ladder
Fixes in order of reliability: a scrim — the semi-opaque layer between gradient and text that hero sections converged on industry-wide, because it manufactures a measurable, compliant background; constraining text to the passing region the checker identifies (viable when layout cooperates); narrowing the gradient’s lightness range so no point strays; or upgrading the text itself to large/bold, lowering the bar to 3:1. Text shadows sit off the ladder — perceptually helpful, unmeasurable in audits, best treated as garnish.
Adjacent problems, adjacent tools
Buttons and badges with gradient fills obey the same worst-point rule at smaller scale — centered labels sit exactly where blends sag, so check with real endpoint values. Image backgrounds generalize the problem beyond parameterization: extract the lightest and darkest under-text regions via the Palette Extractor and check both, or accept the scrim as destiny. The plain-pair case, meanwhile, stays with the WCAG Contrast Checker — this tool exists precisely for backgrounds that refuse to hold still.
How to use the Gradient Accessibility Checker
- Set the gradient endpoints and the text color that sits on it.
- Pick the interpolation space to match your CSS.
- Read the worst-point ratio and where it occurs.
Frequently asked questions
How does WCAG apply to text over a gradient?
At the worst spot: contrast must hold everywhere the text sits, so the minimum ratio along the gradient is the number that counts – a gradient that passes at both ends can fail in the middle. This checker samples 21 points and reports the minimum and its location.
Why would the middle of a gradient fail when the ends pass?
Interpolation can pass through lightness the endpoints do not have – especially sRGB blends between saturated hues, which sag toward muddy mid-tones. White text happy on both vivid ends can hit a washed-out middle at 3:1. The per-point sampling catches exactly this.
Does the interpolation space change the verdict?
It can: the same endpoints produce different intermediate colors in srgb versus oklab, so the worst point moves and its ratio changes. Match the checker's space to what your CSS actually declares (in oklab etc.) – checking a different gradient than you ship helps no one.
What are my options when the check fails?
In effectiveness order: add a scrim (semi-opaque layer between gradient and text – the industry standard for hero images); constrain text to the passing region the tool identifies; narrow the gradient's lightness range; or thicken type (larger/bolder text lowers the requirement to 3:1).
Does a text-shadow fix failing contrast?
It helps perception but WCAG measurement does not credit shadows cleanly – auditors measure text against background. A solid scrim yields a measurable, defensible background; treat shadows as decoration, not compliance.
What about gradients on button or badge backgrounds?
Same rule, smaller canvas: the label must pass at its worst point on the gradient fill. Buttons hide the trap well because labels are centered where gradients are mid-blend – check with your real endpoint colors, not the design-tool approximation.
Can I check image backgrounds with this?
Images are not parameterized gradients, but the principle transfers: find the lightest and darkest regions under text (the Palette Extractor pulls them from a screenshot) and check text against both – or skip straight to a scrim, which is where image-over-text always ends anyway.
