Color and contrast that actually works

Color gets treated like a taste question: pick something that "feels right" and move on. WCAG turned it into a measurement instead. The moment you pick two colors, they have a specific, calculable contrast ratio, and that ratio either clears a defined line or it does not. This guide covers what a contrast ratio actually is, the exact WCAG 2.2 minimums for text, UI parts, and color-only meaning, worked pass and fail examples with real hex values, how to build a palette by role instead of by hue, the common dark-mode traps, and an honest look at what might eventually replace this math.

What a contrast ratio actually measures

A contrast ratio is not a measure of how different two colors look to you. It is a ratio of relative luminance: a formula-derived number for how much light a color effectively reflects, weighted for how the human eye responds differently to red, green, and blue. Every color converts to a luminance value between 0 (black) and 1 (white). The WCAG formula is (L1 + 0.05) / (L2 + 0.05), where L1 is the lighter color's luminance and L2 is the darker one's.

The result always lands between 1:1 and 21:1. Two colors with the same luminance sit near 1:1 no matter how different their hues look on paper: a saturated blue and a saturated red can land at almost the same luminance and read as nearly no contrast at all once brightness is the only thing separating them, which is close to what some forms of color vision deficiency actually experience. Pure black text on pure white is the maximum, 21:1. Every design choice you make lives somewhere on that scale, and the WCAG success criteria draw specific lines across it.

The WCAG 2.2 minimums

1.4.3 Contrast (Minimum) covers text. At Level AA it requires "a contrast ratio of at least 4.5:1" for normal text and at least 3:1 for large text.² "Large" has an exact definition, not a feeling: 18 point (about 24px) or larger, or 14 point (about 18.7px) bold or larger.² Below that size, text needs the stricter 4.5:1, because thin strokes at small sizes get harder to read at low contrast faster than thick ones do.

1.4.11 Non-text Contrast extends the same idea to things that are not text: user interface components, such as button borders, input outlines, and toggle states, and graphical objects, such as icon strokes and chart segments needed to understand the content, need at least 3:1 against whatever sits next to them.³ The reading is strict: the criterion's guidance notes that "computed values should not be rounded," so a 2.99:1 pair fails, full stop.³

Decorative text, inactive controls, and logos sit outside 1.4.3 and 1.4.11 by definition. That exemption is easy to lean on too hard, so treat it narrowly: if a "disabled" button is still legible enough that people try to click it, the interface needs more than a lower contrast ratio to say "not now," such as a lock icon or a visible reason in a tooltip.

Two pairs, worked out

Numbers are easier to trust once you see them applied to real hex values instead of abstract percentages. Here are four pairs, each computed with the standard WCAG relative-luminance formula above.

The first two rows are a clean pass and a clean fail. The last two are the ones people actually get wrong in practice: a ratio is not "good" or "bad" on its own, it is good or bad relative to the job the color is doing. #8A8A8A at 3.45:1 makes a perfectly fine input border. Set that exact gray as paragraph text and it fails, because text carries a stricter 4.5:1 bar than a border does. The blue link is fine as a large heading and fails as a small inline link, for the same reason: size changes which threshold applies, not whether the hex code itself is "accessible."

Never rely on color alone

1.4.1 Use of Color is a separate rule from the ratio criteria, and it trips up designs that pass every contrast check and still fail. It requires that "color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element."⁴ A form field outlined in red for "error," with no icon, no message, and no other change, fails this even if that red clears 3:1 against the background.

This matters because color vision deficiency is common, not rare. About 1 in 12 men have some form of color vision deficiency, most often trouble telling red from green, according to the National Eye Institute.⁵ Add grayscale or low-quality displays, glare, and ordinary situational cases like bad lighting or aging eyes, and "just make it red" stops being a reliable signal for a meaningful share of any real audience.

The fix is cheap: pair the color with a second, non-color cue. An error state gets a red border, an icon, and a text message, not just a red border. A required field gets an asterisk or the word "required," not only a tinted background. A chart gets patterns or direct labels in addition to a color legend. None of this asks you to give up color. It asks you not to make color carry the entire message by itself.

Build the palette by role, not by hue

The fastest way to end up with a palette that fails half its own contrast checks is to pick colors because they look good together, then try to fix accessibility after the fact. Build it in the other order: decide the role each color plays first, then choose the hue that satisfies that role's requirement.

• Background: the base surface color. Usually the least saturated choice on the page; every other color is measured against it.
• Text: body copy, headings, labels. Must clear 4.5:1 (or 3:1 at large sizes) against every background it actually sits on, not just the main one.
• Accent: buttons, links, active states, the one or two colors that mean "interact here." Needs 3:1 against the background where it functions as a UI component, and the full 4.5:1 where it also doubles as text.

A simple discipline keeps this from sprawling into a dozen shades: the 60-30-10 balance, borrowed from interior design and applied to interfaces. Roughly 60% of the screen is the dominant background and surface color, 30% is a secondary color (cards, panels, secondary text), and 10% is the accent, reserved for the handful of things that should draw the eye first, like a primary button or an active state. Because the accent covers a small minority of the screen, it can afford to be your boldest, least background-like color without dominating the page or turning into noise.

Dark-mode contrast pitfalls

Dark mode looks like a simple swap: invert the palette and ship it. In practice it breaks contrast in ways a light-mode design never surfaces.

• Pure white on pure black overshoots. #FFFFFF on #000000 measures 21:1, the maximum possible ratio, and large blocks of it at that extreme can cause halation and eye strain for some readers. Many dark-mode systems deliberately dial the "white" down to an off-white and the "black" up to a near-black, which still clears every AA and AAA threshold with plenty of room to spare.
• Translucent text quietly fails. A common pattern is a white foreground at partial opacity for secondary text. The rendered color depends on whatever sits underneath it, so the same CSS value can pass on one background and fail on a slightly different one right next to it. Measure the flattened, on-screen result, not the opacity value in isolation.
• One accent rarely survives both themes. A saturated accent that clears 4.5:1 on white often falls short on a dark surface, or the reverse. Treat light and dark as two separate palettes carrying the same roles, not one palette with an automatic filter applied on top.
• Borders and dividers go invisible first. A line that was barely legal on a light background often drops under 3:1 once the surrounding luminance flips, and nobody notices until someone reports it.