The Contrast Formula, Its Known Flaws, and What Comes Next

Set the grey #767676 as text on white and the WCAG contrast ratio is 4.54 to 1. Set the same grey on black and it is 4.62 to 1. Both pass Success Criterion 1.4.3 at level AA for body text, and the formula says the second one is marginally the better of the two. Put them side by side on a screen and the second is obviously worse. Mid-grey on black is thin, smeary and hard work. Mid-grey on white is fine.

I computed both numbers myself using the published formula, which is the point. The formula is not being misapplied here. It is doing exactly what it was defined to do, and what it was defined to do does not include noticing which way round the polarity is.

What the formula actually is

The contrast requirement in WCAG 2.x rests on two definitions. Both are short, both are fully specified, and both are worth having in front of you rather than trusting a tool.

W3C technique G17 gives the relative luminance calculation as a weighted sum of linearised channel values, and the contrast ratio as a ratio of two luminances offset by a constant:

RELATIVE LUMINANCE (sRGB)

  for each channel C in {R, G, B}:
      Csrgb = C8bit / 255
      if Csrgb <= 0.03928:
          Clin = Csrgb / 12.92
      else:
          Clin = ((Csrgb + 0.055) / 1.055) ^ 2.4

  L = 0.2126 * Rlin + 0.7152 * Glin + 0.0722 * Blin

  L ranges from 0 (black) to 1 (white).

CONTRAST RATIO

  ratio = (L1 + 0.05) / (L2 + 0.05)

  L1 = relative luminance of the lighter colour
  L2 = relative luminance of the darker colour

  ratio ranges from 1:1 to 21:1

THRESHOLDS, SC 1.4.3 Contrast (Minimum), level AA

  body text          4.5 : 1
  large-scale text   3.0 : 1

  (large scale = at least 18 point, or 14 point bold,
   or the CJK equivalent)

RELATIVE LUMINANCE (sRGB)

  for each channel C in {R, G, B}:
      Csrgb = C8bit / 255
      if Csrgb <= 0.03928:
          Clin = Csrgb / 12.92
      else:
          Clin = ((Csrgb + 0.055) / 1.055) ^ 2.4

  L = 0.2126 * Rlin + 0.7152 * Glin + 0.0722 * Blin

  L ranges from 0 (black) to 1 (white).

CONTRAST RATIO

  ratio = (L1 + 0.05) / (L2 + 0.05)

  L1 = relative luminance of the lighter colour
  L2 = relative luminance of the darker colour

  ratio ranges from 1:1 to 21:1

THRESHOLDS, SC 1.4.3 Contrast (Minimum), level AA

  body text          4.5 : 1
  large-scale text   3.0 : 1

  (large scale = at least 18 point, or 14 point bold,
   or the CJK equivalent)

RELATIVE LUMINANCE (sRGB)

  for each channel C in {R, G, B}:
      Csrgb = C8bit / 255
      if Csrgb <= 0.03928:
          Clin = Csrgb / 12.92
      else:
          Clin = ((Csrgb + 0.055) / 1.055) ^ 2.4

  L = 0.2126 * Rlin + 0.7152 * Glin + 0.0722 * Blin

  L ranges from 0 (black) to 1 (white).

CONTRAST RATIO

  ratio = (L1 + 0.05) / (L2 + 0.05)

  L1 = relative luminance of the lighter colour
  L2 = relative luminance of the darker colour

  ratio ranges from 1:1 to 21:1

THRESHOLDS, SC 1.4.3 Contrast (Minimum), level AA

  body text          4.5 : 1
  large-scale text   3.0 : 1

  (large scale = at least 18 point, or 14 point bold,
   or the CJK equivalent)

The W3C's own Understanding document adds an instruction that automated tools frequently get wrong: "the computed values should not be rounded (e.g., 4.499:1 would not meet the 4.5:1 threshold)."

Where 4.5 comes from

The number is not arbitrary and it is not empirical in the way people assume. The Understanding document for 1.4.3 states its derivation openly: "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." The higher figure is that baseline multiplied by a correction: "A user with 20/40 would thus require a contrast ratio of 3 * 1.5 = 4.5 to 1", because 20/40 acuity is associated with "a contrast sensitivity loss of roughly 1.5".

So 4.5:1 is a 1980s ergonomics recommendation for cathode ray tube displays, multiplied by 1.5. That is a defensible piece of engineering. It is also the origin of most of the trouble.

Munsell hues at maximum chroma. Munsell built his system from perceptual judgements rather than arithmetic, which is exactly the objection raised against the contrast formula. Image by 8-leaf clover, CC BY-SA 4.0, via Wikimedia Commons.

Worked pairs

These are all computed with the formula above. The pass column refers to SC 1.4.3 level AA for ordinary body text, which is 4.5:1.

Rows three, four and six are the whole argument. The formula is a luminance ratio, so it is blind to polarity, nearly blind to hue as a readability factor, and completely blind to how the glyphs are drawn.

The documented problems

Polarity and dark mode

This is the most consequential, because dark interfaces became a default rather than an option and the metric did not follow. Andrew Somers, writing in Smashing Magazine on 6 September 2022, states that the WCAG 2 contrast guidelines "trace their origins to standards of the 1980s" and are "less than useful for dark mode", because they "do not predict the contrast of text in accordance with human perception, which is especially noticeable with dark color pairs". His APCA documentation puts it harder: 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 therefore "cannot be used for guidance designing 'dark mode'."

That claim is easy to check against the table above and it holds. The #767676 pair scores slightly better on black than on white while performing visibly worse.

Spatial frequency: thin type and small type

The formula takes two colours. It does not take a font, a size, a weight, or a rendering environment. Somers's central technical argument is that perceived contrast depends heavily on spatial frequency, which in typographic terms means stroke weight and size: small, thin text needs a much greater lightness difference than the same colours applied to a heavy display setting.

WCAG 2.x acknowledges this obliquely and then does nothing about it. Its only nod is the large-text exception, which relaxes the requirement to 3:1 above 18 point or 14 point bold, and a warning in the Understanding document that "Due to anti-aliasing, particularly thin or unusual fonts may be rendered by user agents with a much fainter color than the actual text color defined in the underlying CSS." That is a documented admission that the number on the page can differ from the number on the screen, with no adjustment mechanism offered.

Hue

Hue enters the calculation only through the luminance coefficients, 0.2126 for red, 0.7152 for green and 0.0722 for blue. Those weights describe how much each primary contributes to luminance. They do not describe anything about how readable a hue is at text size. Pure blue on white scores 8.59, comfortably above the AAA threshold of 7:1, even though blue text at body size is a well-known discomfort. Pure green on white scores 1.37 and fails outright.

The original complaint against the formula, filed by Somers under the handle Myndex on 14 April 2019 and still open, says the sRGB contrast specification "is not perceptually uniform and as a result creates 'contrast ratios' that are not meaningful", that the equation "does not accurately model an illuminated display in real world ambient conditions", and that it "fails badly in the midrange colors as it does not adjust for human nonlinear perception". The consequence he names is the practical one: "Websites that may comply with the W3C's math for contrast, but are otherwise difficult to read." The issue now lives in the w3c/wcag3 repository as issue 192, and carries a January 2023 note from the author himself clarifying that the original post represents early research notes rather than current guidance.

The threshold that is wrong and does not matter

Here is a correction to a claim I have seen repeated as though it were significant. The piecewise linearisation in WCAG uses 0.03928 as its breakpoint. That value comes from a superseded draft of the sRGB specification; the published value is 0.04045, or more precisely 12.92 times 0.0031308. This was reported to the working group by peteroupc on 8 December 2017 as w3c/wcag issue 308, which is now closed, and the W3C's own accessibility wiki records the error plainly: "The correct threshold for the piecewise equation is 0.04045 and not the 0.03928 that is listed below. Nevertheless for 8 bit color values the difference is not significant."

It is worth being precise about how insignificant. I enumerated all 256 eight-bit channel values and checked which of them fall between 0.03928 and 0.04045 once divided by 255. None do. For any colour expressed as ordinary eight-bit sRGB, the two thresholds select the same branch of the function for every possible input, so they produce identical results in every case. The error is real, it is documented, and for practically all web work it changes nothing. Treat it as a footnote, not as evidence that the formula is broken. The formula has much better problems than this one.

The most common mistake about WCAG contrast is not trusting the number too much. It is thinking the number is wrong when it is merely narrow.

APCA, and what its status actually is

This is where I want to be careful, because the design internet has been sloppy about it for years and the sloppiness runs in one direction.

APCA, the Accessible Perceptual Contrast Algorithm, is described by its own documentation as "a new method for calculating and predicting readability contrast", developed by Somers and copyright Myndex Perception Research. Its output is Lc, a lightness-darkness contrast value running from Lc 0 to Lc 105 and above, and it is designed to be perceptually uniform, so that a given Lc means roughly the same readability regardless of where in the tonal range the two colours sit. Its published guidance for body text is Lc 75 as "the minimum level for columns of body text" and Lc 90 as the "preferred level for fluent text and columns of body text". It also carries a ceiling, which the WCAG 2 model does not: Somers notes in the Smashing article that for fonts larger than 24 pixels the maximum recommended is Lc 90, and that "more is not always better".

Now the status, stated as precisely as I can establish it.

APCA is not normative anywhere. The current W3C Recommendation is WCAG 2.2, which reached Recommendation status on 5 October 2023 and was republished as a revised Recommendation on 12 December 2024. It uses the 2.x formula given above. Nothing in it references APCA.

WCAG 3.0 is a Working Draft, not a Recommendation. The draft current when I wrote this was published on 4 September 2025. I read it looking specifically for a contrast requirement and did not find one. Its sections on text appearance contain tables whose entries are explicitly marked as placeholders, with wording to the effect that the content is still to be determined and the present content is only an example. In other words, as of that draft, WCAG 3 does not specify a contrast algorithm at all. Anyone telling you that APCA "is" the WCAG 3 contrast method is describing an intention, not a published requirement.

APCA's own documentation is more careful than its advocates. It calls itself "the candidate contrast method for the future WCAG 3" and, in the Smashing article, "currently being evaluated as a public beta" and "usable as a public beta", with the explicit advice to check what your own compliance obligations actually require before adopting it. The author identifies himself as a W3C Invited Expert and attaches a disclaimer that personal opinions "may or may not reflect those of the W3 or AGWG".

The sticking point inside the working group is documented too. In an issue opened on 24 October 2023 to compile evidence of independent review, the position of the Contrast Subgroup is recorded as holding that APCA "requires extensive peer review from other researchers in color contrast before adoption", with the counter-argument in the same issue being that peer review is not part of the W3C charter and has not been demanded of other WCAG 3 subgroups. APCA's stable release entered public beta in February 2021. Several years later that disagreement had not resolved into a specified algorithm.

There is also a separate track. APCA is published independently of W3C as the APCA Readability Criterion, which is a Myndex document rather than a W3C one. That is a legitimate thing to exist. It is not the same thing as a standard, and conflating the two is how a designer ends up telling a client that their site meets a requirement that no regulator has heard of.

What to do in the meantime

The practical position I have settled on is unglamorous and has three parts.

Meet WCAG 2.x, because it is what conformance claims, procurement documents and law currently point at. That means 4.5:1 for body text, 3:1 for large text and for non-text elements under 1.4.11, computed without rounding.

Do not treat passing as sufficient, particularly in dark mode. If a dark-mode pair clears 4.5:1 by a small margin, check it by eye on an actual screen at actual size, because that is precisely the region where the formula is documented to overstate. Run APCA alongside as a second opinion, and treat a large disagreement between the two as a signal to look again rather than as a verdict.

Adjust for the thing the formula ignores. If the type is light in weight or small, buy more contrast than the threshold demands, because the anti-aliasing warning in the W3C's own documentation is telling you that the rendered result will be fainter than the specified colour.

And keep the two vocabularies separate in writing. A ratio is a WCAG 2.x number with regulatory weight behind it. An Lc value is a research tool that has not yet been adopted by anything. Saying so plainly costs nothing and is the difference between advising a client and misleading one.

Sources

• W3C, "G17: Ensuring that a contrast ratio of at least 7:1 exists between text (and images of text) and background behind the text", Techniques for WCAG 2.0. Source of the relative luminance and contrast ratio formulas, including the 0.2126 / 0.7152 / 0.0722 coefficients and the 0.03928 piecewise threshold. w3.org/TR/WCAG20-TECHS/G17.html

• W3C Web Accessibility Initiative, "Understanding Success Criterion 1.4.3: Contrast (Minimum)", Understanding WCAG 2.2. Source of the ISO-9241-3 and ANSI-HFES-100-1988 derivation, the 20/40 vision and 1.5 contrast-sensitivity multiplier, the large-scale text definition, the no-rounding instruction and the anti-aliasing note. w3.org/WAI/WCAG22/Understanding/contrast-minimum.html

• W3C, "Web Content Accessibility Guidelines (WCAG) 2.1", W3C Recommendation. Text of SC 1.4.3 and SC 1.4.11 and the definition of large scale text. w3.org/TR/WCAG21/

• W3C, "Web Content Accessibility Guidelines (WCAG) 2.2 publication history", W3C Standards. Recommendation 5 October 2023, revised Recommendation 12 December 2024. w3.org/standards/history/WCAG22/

• W3C Web Accessibility Initiative wiki, "Relative luminance". Records that the correct piecewise threshold is 0.04045 rather than 0.03928, and that for 8-bit colour values the difference is not significant. w3.org/WAI/GL/wiki/Relative_luminance

• peteroupc, "Outdated threshold for sRGB companding in the 'relative luminance' definition", w3c/wcag issue 308, opened 8 December 2017, closed. github.com/w3c/wcag/issues/308

• Myndex (Andrew Somers), "Contrast Ratio Math and Related Visual Issues", opened 14 April 2019, now w3c/wcag3 issue 192, open, with a January 2023 clarification by the author. github.com/w3c/wcag3/issues/192

• Andrew Somers, "The Realities And Myths Of Contrast And Color", Smashing Magazine, 6 September 2022. Dark mode and polarity, spatial frequency, the public beta status of APCA and the Lc 90 ceiling. smashingmagazine.com/2022/09/realities-myths-contrast-color/

• Myndex Perception Research, "APCA in a Nutshell", APCA documentation. Definition of Lc, the Lc 0 to 105+ range, the Lc 75 and Lc 90 body text levels, and the description of APCA as the candidate contrast method for a future WCAG 3. git.apcacontrast.com/documentation/APCA_in_a_Nutshell.html

• Myndex Perception Research, "Why APCA", APCA documentation. The claim that WCAG 2 overstates contrast for dark colours and cannot be used for dark-mode guidance, and the author's W3C Invited Expert disclaimer. git.apcacontrast.com/documentation/WhyAPCA.html

• W3C, "W3C Accessibility Guidelines (WCAG) 3.0", W3C Working Draft, 4 September 2025. Working Draft status and placeholder content in the text appearance tables. w3.org/TR/2025/WD-wcag-3.0-20250904/

• "Contrast Research: APCA Peer Reviews + Defining a Visual Contrast Guideline", w3c/wcag3 issue 29, opened 24 October 2023. The Contrast Subgroup's peer-review position and the February 2021 APCA public beta date. github.com/w3c/wcag3/issues/29

Related reading

• Barthes, the Death of the Author, and the Prompt

• Designing the Empty State

• Where the Eight Point Grid Came From

• Two Laws Designers Quote and Misuse

More from the Moc Mallen Studio journal