The WCAG color contrast ratio is a numeric value between 1:1 and 21:1 that measures the luminance difference between two colors, calculated as (L1 + 0.05) / (L2 + 0.05), where L1 is the lighter color's relative luminance and L2 is the darker one's. To check color contrast on website designs, designers and developers compare the foreground text color against its background color and verify that the resulting ratio meets the published Web Content Accessibility Guidelines thresholds. Level AA requires at least 4.5:1 for normal text and 3:1 for large text, while Level AAA raises the bar to 7:1 for normal text and 4.5:1 for large text. The math runs the same way regardless of whether you are auditing a marketing landing page, a SaaS dashboard, or a blog template, because the formula measures the color pair itself, not the document type. What changes between contexts is which color combinations matter most: brand-primary buttons, body copy, error states, placeholder text, and form labels each have their own role in a site's overall readability score.
What the WCAG Contrast Ratio Actually Measures
The contrast ratio is a property of the color pair, not of which color is text and which is background. Swapping foreground and background gives the exact same number, because the formula always divides the lighter color's luminance by the darker one's. This symmetry matters when designers reuse a single palette across buttons, alerts, and tooltips in either direction.
Behind that single number sits a fixed chain of conversions. Each sRGB channel is converted from gamma-encoded bytes (0-255) into linear light using the WCAG-specified piecewise function: if the channel value divided by 255 is at or below 0.04045, the linear value is that ratio divided by 12.92, otherwise it is raised to a power of 2.4 after a small offset. The linear channels are then weighted by 0.2126 for red, 0.7152 for green, and 0.0722 for blue to produce relative luminance. The two luminance values, plus a 0.05 constant added to each side to prevent division by zero, produce the final ratio.
Ratios always land between 1:1, meaning identical colors, and 21:1, meaning pure black (#000000) on pure white (#ffffff). A worked example walks through the formula end to end. White (#ffffff) has sRGB channels of 255 each, which linearize to 1.0 and yield L = 0.2126 + 0.7152 + 0.0722 = 1.000. The hex #111111 has sRGB channels of 17 each; dividing by 255 gives 0.0667, which is above the 0.04045 cutoff, so the linear value is ((0.0667 + 0.055) / 1.055) raised to 2.4, approximately 0.1153 to the 2.4 power, or about 0.00562. With both channels equal, L = 0.00562. The ratio is then (1.000 + 0.05) / (0.00562 + 0.05) = 1.05 / 0.05562, which works out to roughly 18.88:1. That clears every WCAG threshold by a wide margin.
Because the math depends only on the two colors, the same calculation runs anywhere a designer needs it: in a design system token file, a production stylesheet, or a quick spot-check in the browser. The Color Contrast Checker applies this exact formula and shows the resulting ratio alongside pass or fail badges for every threshold at once.
WCAG AA and AAA Thresholds at a Glance
The Web Content Accessibility Guidelines sort color combinations into tiers based on the ratio they hit. AA is the legal floor in most jurisdictions, AAA is the recommended target for body content where it can be achieved without harming the design.
| Conformance level | Normal text | Large text | UI components and graphics |
|---|---|---|---|
| WCAG AA | 4.5:1 or higher | 3:1 or higher | 3:1 or higher |
| WCAG AAA | 7:1 or higher | 4.5:1 or higher | Not specified; AA applies |
Large text in this table means at least 18 point (about 24 CSS pixels) for regular weight, or at least 14 point (about 18.66 pixels) when bold, per the W3C definition in WCAG 2.1 Contrast (Minimum). Thicker, larger letterforms are easier to read at lower contrast, which is why they get a more generous threshold.
UI components and graphics cover button borders, form field outlines, focus indicators, icons, and chart elements that need to be perceivable against adjacent colors but are not text. The 3:1 ratio applies even when the component is interactive, not just decorative. Charts that encode data with color, infographics, and any custom control fall under this rule.
How to Check Color Contrast on a Website
The fastest workflow combines the colors already in a stylesheet with a browser-based tool that runs the WCAG formula on demand. The Color Contrast Checker accepts two hex values and returns every threshold in a single view.
- Pick the foreground (text) color from the design system. Use the color picker or type the hex directly, for example #111111.
- Pick the background color the same way, for example #ffffff.
- Read the resulting contrast ratio plus the AA and AAA pass or fail badges for normal text, large text, and UI components.
- Adjust either color if a badge fails, then re-check until the level you need clears.
- Record the final pair in your design tokens or component spec so future updates do not regress the ratio.
For teams that live inside CSS, the same workflow runs against any token file. Reading the rendered pair straight from the browser dev tools preserves the exact color values, including alpha, that production users will see. Designers working in code editors often copy a hex from the stylesheet and paste it into the tool while iterating on a button color, which is the approach covered in the CSS-focused guide for passing WCAG ratios.
Color Combinations Worth Testing on Any Website
Most websites run on a small palette of color pairs. A handful of pairs cover the majority of pages, and they are the ones worth checking first.
- Body text on the page background. The single most-used pair on any site. Black on white and very dark gray on white are common defaults, but light-gray body copy on white is a frequent failure point.
- Primary and secondary buttons. White text on a brand-primary fill, plus the hover and disabled states, need separate checks because the fill often lightens or desaturates on hover.
- Form labels and helper text. Placeholder text is a notorious failure spot because designers often drop it to a light gray that fails AA on white.
- Link colors. Underlined links gain a separate signal and tolerate lower contrast, but inline text-only links rely on color alone and need the full threshold.
- Error and success states. Red error text and green success text often fail on white or pale backgrounds because those hues are inherently low in luminance.
Checking these pairs once and recording the result prevents the slow drift that happens when a brand color is tweaked by a few percent in a quarterly refresh. Capturing the verified hex values inside a design token file means future code changes can be diffed against a known-good baseline.
Where Contrast Falls Short: Pairs to Double-Check
The contrast ratio measures luminance, not hue. Two colors with very different hues but similar brightness can still fail: classic red on green is the textbook example, where the colors look distinct to many viewers but the ratio sits below 4.5:1. That is also why the guidelines warn against using color alone to convey meaning; pair it with text labels, icons, or underlines so the information survives when contrast is borderline.
Gradients, semi-transparent overlays, and text placed on images are trickier than solid backgrounds because the effective background changes across the element. A safe workflow is to test the pair against the lightest and darkest points a letter could sit on, then accept the worst case as the binding threshold. Skipping this step is one of the most common pitfalls outlined in guides on avoiding contrast mistakes.
Placeholder text, disabled button states, and thin decorative fonts are other common failure spots. Designers often reduce placeholder text to a low-contrast gray to match the empty-field feel of native inputs, but those same grays frequently fail AA on white. Disabled buttons often use a desaturated brand fill that reads as decorative rather than functional, and the underlying text drops below the threshold.
The contrast ratio is not the whole accessibility story. It covers readability for users with low vision or in bright sunlight, and it helps users with color vision deficiencies by ensuring enough luminance difference, but it does not check semantic HTML, focus order, keyboard handling, or screen-reader behavior. A complete audit pairs the contrast check with structured markup and ARIA where appropriate, and it runs the same pair through every state the component actually appears in.