Why your light grey text fails

The pale grey caption is the classic failure

Somewhere in almost every design there is a caption, a timestamp, or a helper line set in a grey that looked elegant on a bright laptop in a dark room. Put it on a phone in daylight, or in front of a fifty-year-old, and it stops being readable text and becomes texture.

This is not a matter of taste, and it is not unmeasurable. Contrast between two colours is a single number, and the levels that count as readable were settled years ago. Most teams fail not because the rules are vague but because nobody checked.

The rules come from WCAG, the Web Content Accessibility Guidelines. They matter beyond good manners: accessibility law in the UK, the EU and the US leans on them directly, so a failing grey is a legal exposure as well as a usability one.

What the ratio actually measures

Contrast ratio compares the relative luminance of two colours: how much light each one emits or reflects, calculated from the red, green and blue channels in sRGB with a heavy weighting toward green, because that is where human vision is most sensitive.

The scale runs from 1:1, meaning two identical colours, to 21:1, which is pure black on pure white and nothing else. There is no higher value available, so if a checker reports 21:1 you are looking at #000000 and #FFFFFF.

The important consequence is that hue is irrelevant. Two colours can be wildly different to look at, a mid red and a mid green for instance, and still sit at nearly the same luminance, which means their contrast ratio is close to 1:1 and text in one on the other is genuinely hard to read. Converting a pair to a lightness-based space with a hex to HSL converter or a hex to OKLCH converter makes this obvious quickly, because you can see the lightness values are the same even when the colours are not.

Order does not matter either. Dark text on a light background scores the same as the reverse. What changes is perceived comfort, which the ratio does not capture at all.

The thresholds, precisely

There are two conformance levels in common use. AA is the practical standard almost every organisation targets and the one most regulations reference. AAA is stricter and is generally treated as an aspiration rather than a blanket requirement.

Large text gets a lower bar because bigger, thicker strokes carry more light to the eye. WCAG defines large as 18pt, which is 24px at default settings, or 14pt, about 18.66px, when the weight is bold. Note that this is a size threshold, not a heading threshold: a 20px heading is not large text.

WCAG 2.1 added the rule that most teams still miss. Non-text content needs 3:1 as well. That covers the border of an input field, the outline of a button, a toggle in its off state, a focus ring, and the lines and segments of a chart when they are the only way to read it.

The traps that pass on paper

Placeholder text and disabled controls are the biggest one. The guidelines exempt disabled elements, and placeholders are frequently argued into the same bucket, so a checker will not complain. Users still will. A placeholder is often the only label a field has, and a disabled button that nobody can read is a dead end rather than a helpful state. Keep both above 3:1 even though nothing forces you to.

Text over photographs is the second. The ratio is calculated between two flat colours, but a photograph is thousands of colours, and your caption can pass over the dark half of an image and fail completely over the sky. Sample the lightest pixel behind the text, not the average. If that fails, add a scrim, a gradient, or a solid panel rather than nudging the text colour.

Thin weights are the third. A 300-weight typeface at 4.5:1 technically passes and still reads worse than a 400-weight at 4.5:1, because there is simply less ink on the screen. Contrast ratio is blind to stroke width. If your brand font is light, treat the threshold as a floor and push higher.

And then there is the opposite failure. Pure black on pure white, 21:1, is uncomfortable for extended reading and is reported as a trigger for visual strain by many people, particularly readers with dyslexia or light sensitivity. Softening to something like #1A1A1A on #FAFAFA still lands around 17:1, comfortably beyond every requirement, and is noticeably easier to sit with.

Colour is never the only signal

The most familiar accessibility mistake in interfaces is the red and green error state: a field turns red when wrong and green when right, with no other change. Roughly one man in twelve has some form of colour vision deficiency, most commonly a difficulty separating red from green, so for that reader the field simply changed shade.

The fix is cheap. Add an icon, a text label, a border weight change, or a pattern, so the meaning survives without colour. The same applies to chart series, required-field markers, status pills, and links that are distinguished from body text by colour alone. Underline them.

You can check this in a few seconds with a colour blindness simulator, which reproduces the common deficiencies, and desaturating a screenshot with a grayscale converter is a blunt but effective second test: if the screen still makes sense in grey, colour was carrying meaning it did not have to.

Practical starting values

On a white or near-white background, body text at #595959 hits exactly 7:1 and is about as light as grey can honestly go for paragraphs. #767676 lands at roughly 4.5:1 and is the true AA floor: anything lighter fails. If you have been using #999999, that is about 2.8:1 and it fails everywhere, including as large text.

For secondary text, muted labels and metadata, pick something in the 4.5:1 to 5.5:1 band rather than treating it as decorative. For borders and icons, 3:1 is the requirement, which in practice rules out the very faint hairline greys around #E5E5E5 for anything functional. A decorative divider can stay faint. A control outline cannot.

Dark mode needs its own pass rather than an inversion. The same hues behave differently against dark surfaces, and a saturated blue that reads well on white is often too dim on near-black. Build the ramps deliberately with a colour shades generator and pick the step that clears the bar, and use a colour converter when you need the same value expressed for different parts of your stack.

Test every real pairing rather than the brand palette in the abstract, using a contrast checker. Text on cards, text on the brand colour, hover states, and both themes. That is usually a dozen pairs, not a hundred.

A note on what comes next

You will hear about APCA, a newer perceptual contrast model designed to fix exactly the weaknesses described above: it accounts for font size and weight, treats light and dark polarity differently, and handles very dark backgrounds far more sensibly than a plain luminance ratio.

It is worth knowing about, and it is not the requirement. APCA has been explored as candidate work for a future version of the guidelines, but the standard in force is still WCAG 2.1 and 2.2 with the ratios in the table above. Design to those numbers, and treat APCA as a useful second opinion when a pairing passes the maths but still looks wrong.

Which is the honest summary of the whole subject. The ratio is a floor, not a verdict. Clear it every time, then use your eyes.