Why 4.5:1 Contrast Means Less in Dark Mode

If you have ever shipped a dark theme, passed every contrast check, and still had someone tell you the small grey text was hard to read, you were not imagining the conflict. The checker was right about the number and your reader was right about the page.

The reason is built into the formula. WCAG's contrast ratio has no idea which of your two colours is the background, so it cannot tell a light theme from a dark one. Everything below is about what that costs you and what to do instead, and none of it requires you to stop meeting 4.5:1.

The formula throws polarity away on purpose

Success criterion 1.4.3 in WCAG 2.2 asks for "a contrast ratio of at least 4.5:1" for normal text, dropping to 3:1 for large text, which it defines as "at least 18 point or 14 point bold". The enhanced version, 1.4.6, asks for 7:1.

To get the ratio, each colour is reduced to a single relative luminance number, then the two go into (lighter + 0.05) / (darker + 0.05). Note the word lighter. The formula sorts your two colours by brightness before it divides, so which one you meant as the text never enters the calculation.

That is why black on white and white on black both come out at exactly 21:1 in our color contrast checker, and why swapping any pair leaves the number untouched. The effect at the pass or fail boundary is sharper than most people expect. The lightest neutral grey that still clears 4.5:1 against white is #767676, at 4.54:1. The darkest neutral grey that still clears 4.5:1 against black is #757575. One hex step apart, mirror-image situations, and the standard draws its line in essentially the same place for both.

Where 4.5:1 came from

The number has a traceable origin, and W3C spells out the arithmetic itself. Its explanation of the criterion says "a contrast ratio of 3:1 is the minimum level recommended by [ISO-9241-3] and [ANSI-HFES-100-1988] for standard text and vision", then explains that "the 4.5:1 ratio was chosen for level AA because it compensated for the loss in contrast sensitivity usually experienced by users with vision loss equivalent to approximately 20/40 vision".

It even shows the arithmetic. A 20/40 viewer is taken to have "a contrast sensitivity loss of roughly 1.5", so "3 * 1.5 = 4.5 to 1". W3C adds that "20/40 is commonly reported as typical visual acuity of elders at roughly age 80".

So 4.5:1 is a 3:1 baseline borrowed from two display ergonomics standards, one of them dated 1988, multiplied by a single compensation factor for one reference level of acuity. That is a defensible way to set a floor. It is not a model of reading, and it was never meant to rank two pages that both clear it.

What happens when you actually test the two directions

The best evidence here comes from a set of proofreading experiments run at Heinrich Heine University in Düsseldorf, published by Cosima Piepenbrock, Susanne Mayr and Axel Buchner and collected in full in Piepenbrock's open-access dissertation.

The first study, which ran in Human Factors, put 160 people in front of either black text on white or white text on black and had them hunt for errors in real passages. Both arrangements score 21:1. Reading them is not the same job.

Error detection was better with dark text on light across every size tested, F(1, 158) = 9.34, p = .003. More useful for anyone picking a type scale: the texts came in 8, 10, 12 and 14 pt, and the advantage of dark-on-light grew linearly as the characters got smaller, F(1, 158) = 8.92, p = .003. The authors' own closing advice is blunt. "Especially with small font sizes, negative polarity displays should be avoided."

A follow-up in Ergonomics tested whether that reverses with age, which would be the obvious guess given that WCAG's own 4.5:1 rationale is pinned to an 80-year-old's acuity. It compared 85 adults aged 60 to 85 against 84 aged 18 to 33. Dark text on light won on measured visual acuity, F(1, 163) = 69.31, p < .01, and on proofreading accuracy, F(1, 165) = 9.92, p < .01. Both age groups showed the advantage, and on proofreading accuracy its size did not differ between them, F(1, 165) = 0.60, p = .44. Older readers got no dark-mode bonus.

That study is also the place to notice what did not move. Reading speed came out the same in both polarities and for both age groups, F(1, 165) = 0.16, p = .69, so the effect it found sits in accuracy and acuity rather than in how fast anyone got through the text.

The honest version of why

This is the part most "WCAG contrast is broken" posts skip, and it is the part that tells you what to change.

The mechanism the researchers landed on is not that the ratio is miscalculated. It is total light. A page of dark text on white is a mostly-white page, so it throws a lot of light at you, your pupil constricts, and a smaller pupil gives a sharper retinal image with more depth of field. Flip to a dark theme and the bright colour now covers almost none of the screen.

The clinching test is one the Ergonomics paper describes from earlier work by Buchner, Mayr and Brandt in 2009. They held display contrast constant and equalised overall display luminance between the two polarities. The advantage vanished: "There was no advantage of positive polarity in a proofreading task when comparing positive and negative polarity displays of equal overall luminance. Instead, display luminance affected the results, with better performance for the brighter displays."

Read that carefully, because it cuts both ways. Dark mode is not inherently worse for your eyes, and the research does not say that. What it says is that a dark page delivers less light, and less light costs you fine detail. That is a cost you can pay down with size and weight, which is exactly what a contrast ratio cannot see.

Worth naming the limit of the inference too. These experiments compared the extremes, black against white in both directions, not two different pairs that both land on 4.5:1. They establish that an identical ratio does not buy identical reading performance. They do not give you a conversion factor for how much to add in dark mode.

W3C already agrees something is missing

You do not have to take a critic's word for it. The WCAG 3.0 working draft, dated 10 September 2026, still has its text contrast requirement unresolved, and the note explaining why is the interesting part: "The contrast algorithm used in WCAG 3 is yet to be determined. For this draft, the requirement assumes the algorithm will include a size/weight factor."

That is the working group writing down that the next measure needs to know how big and how heavy the text is. The leading candidate is APCA, the perceptual contrast algorithm from Andrew Somers at Myndex. Its introduction states plainly that "unlike WCAG 2.x, APCA reports different values when you switch text color and background color", and its thresholds are a table rather than one number: Lc 75 is the minimum for body text above 18px, Lc 60 for medium text above 24px, Lc 45 for large fluent text above 36px.

Somers is blunter elsewhere, writing in Why APCA that WCAG 2 "far overstates contrast for dark colors to the point that 4.5:1 can be functionally unreadable when a color is near black" and "cannot be used for guidance designing 'dark mode'". Treat that as the author of the replacement making his case, not as a settled finding. The WCAG 3 draft does not name any algorithm yet, so 4.5:1 is still the number you will be audited against.

What to do with your dark theme on Monday

None of this is a reason to drop below 4.5:1 anywhere. It is a reason to stop treating a bare pass as the finish line when the background is dark.

Leave yourself headroom instead of landing on the floor. If a grey clears AA at 4.52:1 on a near-black surface, it has nothing left for a reader on a dim phone at arm's length. Our checker will show you where a candidate actually sits, and it marks 7:1 as well, which is a practical target for small text in a dark theme even when you are only contractually bound to 4.5:1.

Spend the slack on size and weight rather than on more contrast. The Düsseldorf result says the penalty concentrates in small characters, so 16px at weight 500 is doing more for a dark-theme reader than the same text at 14px with a brighter grey. If a label has to be 12px, that is where the extra contrast belongs.

Stop short of pure white on pure black. Google's own dark theme guidance builds on "a dark gray with the hex value #121212" rather than black, and keeps high-priority text off pure white because, in its words, #FFFFFF "would visually 'vibrate' against our dark backgrounds". It adds that "pure #FFFFFF text against a dark background can harm legibility since the light from that text appears to bleed or blur against the dark background". Its emphasis tiers put high-emphasis text at 87% opacity, medium at 60%, disabled at 38%.

Be careful with saturated accents too. The same guidance notes that "more saturated colors tend to visually 'vibrate' against darker backgrounds, making them harder to read", which is a failure mode the ratio reports as fine because saturation barely moves relative luminance.

And check both themes as separate designs. A palette that passes once is not a palette that passes twice. Our checker scores every colour against every other in both directions, so you can paste in the light and dark surfaces together and see which pairs only survive in one of them.

The short version: 4.5:1 is a floor derived from one acuity assumption and a 1988 display standard, it is deliberately blind to which colour is behind the text, and the reading research says that blindness costs you most on small type in a dark theme. Keep clearing it. Just do not read a pass as a verdict on how the page reads.