What the $@!%& WCAG!?
Why WCAG 2.x color contrast sucks and how to make it better
What the $@!%& WCAG!?
Why WCAG 2.x color contrast sucks and how to make it better
Photo by Robert Katzki on Unsplash
For 16 years, WCAG color contrast has been the standard for color contrast accessibility. The problem is WCAG contrast has always been a terrible standard. In 2019, Color Scientist **Andrew Somers posted the issue on [#695 WCAG Github](https://github.com/w3c/wcag/issues/695)**.
“The W3C’s specification for determining sRGB contrast … is not perceptually uniform and as a result creates ‘contrast ratios’ that are not meaningful. The end result is incorrect contrast choices...“— Andrew Somers
Rather than waiting for WCAG to create a solution, Andrew built the **Accessible Perceptual Contrast Algorithm, or [APCA](https://git.apcacontrast.com/documentation/WhyAPCA), to be included in WCAG 3.0 (currently in working draft). Andrew Somers provided the [APCA Color Contrast Calculator](https://www.myndex.com/APCA/)** so you can try it for yourself.
Disclaimer
This article does not describe APCA or how it should be used but illustrates why WCAG is insufficient and how APCA shows us a better way.
Andrew Somers is a color scientist whereas I’m a ‘color mechanic’, meaning I have practical experience in the science of color using ICC Color Management to create reliable color solutions in production. As a photo retoucher, I used spectrophotometers, colorimeters, and profiling software to create custom ICC Color Profiles for monitors, scanners, and printers.
This article describes a sympathetic solution that APCA provides but is different because it is still approached from the perspective of density, much like WCAG does today. Tier 2 tokens (semantic, contextual) are responsible for behavior in dark mode and reference Tier 1 tokens of known densities that most closely align with APCA standards.
Density as Contrast
I was glad to discover (or **re-discover) in 2022 the connection between WCAG ratios and L density as described by the device-independent color model called Lab, created by the ***International Commission on Illumination*, or CIE for short. The CIE Lab and Lch color models express density in the L* channel on a scale of 0 to 100 where 50 is the mid-tone value.
Simply put, on white, WCAG determines pass/fail on two main mid-tone values. WCAG 3:1 = L60 and WCAG 4.5:1 = L50. This is true of every color hue, not just neutrals. As an aside, the WCAG 7:1 is closer to a 3/4 tone at L*35, which severely limits the creation of a visual hierarchy with density, so I typically recommend avoiding 7:1.
Though CIE L density is more intuitive (I use **OKLab**, which is a newer solution), it doesn’t address the core problems of WCAG which APCA solves. A curious anomaly of WCAG is white text on an L50 background passes a 4.5:1 ratio using both white and black.

From a pure WCAG 2.x perspective, both treatments pass with flying colors but the right button is barely readable. At smaller sizes, the text on the right button would virtually disappear for normal-sighted users.
By introducing the concept of polarity in APCA, (recognizing the difference of dark text on a light background and vice versa), Andrew Somers' calculations more closely align with true human perception.
However, if we consider this use case from a designer’s perspective, we see the problem is already solved. When a designer is given a choice of either white or black text that passes for WCAG color contrast, designers choose the white text treatment. Because humans create designs, this is a ‘problem’ that doesn’t need a solution, though I’m happy APCA provides one anyway and indicates a fail.
Nevertheless, this ‘bug’ WCAG introduces has far more serious consequences when supporting dark mode where mid-tone values are presented on black backgrounds.

All elements pass WCAG 2.x for dark and light modes, but notice the back button and the hyperlink text are barely legible on black backgrounds. This issue persists in iOS mobile platforms today, but we can enhance readability by increasing the L* density distance (contrast) in dark mode.

A noticeable improvement! The color for the text is lightened but still gives the impression that color is maintained. The text is far more legible in dark mode. Though we use L* density rather than the more precise APCA methodologies, the result closely matches APCA recommendations (but not exactly).
Note the back button and header in dark mode are the same color (though lighter than the light mode treatment) but the hypertext link is much lighter. Yet, in light mode, all are the same color. This tells us Tier 2 tokens can appear the same in light mode but present different values in dark mode.

Two contextual tokens for ink/system (soft and normal) are inherited from palette tokens and applied to a dark mode design.
Tier 2 tokens shown above use a Warhol naming convention described in my article **What if Warhol created design tokens in Figma?** which describes STATE in musical dynamic notation. The symbol ‘~’ means normal whereas ‘p’ indicates softer and ‘f’ (not shown) indicates louder, or contrast that is greater than normal.
Quarter-tone values
APCA also allows a greater dynamic range by including 1/4 tone values, not allowed in WCAG. For instance, background values at L*65 density would pass WCAG with black text only, but with APCA, white text is an acceptable (and more desirable) treatment.

This solves the problematic WCAG requirement of using black text on orange backgrounds to pass accessibility.
Improvements
This article uses Tier 1 token densities created by the **Genome Color Tool** and Genome Optimization but that optimization was built with WCAG color contrast in mind. I suspect a new density optimization for APCA can provide a more reliable pass. Even so, the misses (notably ink/system/p) were barely perceivable as an expression of DeltaE, so this seems encouraging.
Andrews's algorithm includes polarity but also appears to be weighing on chroma and saturation as well, which **Genome Color Tool** does not provide, but it gives me a few ideas. I’ll need to dive deeper into the source code APCA provides to see about a better solution.
Conclusion
WCAG 2.x color contrast has always been a terrible standard, but it’s the only one we’ve had for 16 years. Using color science, Andrew Somers built APCA to solve glaring perceptual issues WCAG introduced.
Design Systems need to incorporate better solutions into scalable and intuitive systems, and I believe this demonstrates a good first step that needs more research for better integration.
Personal Note
I’ve found WCAG color contrast something of a double-edged sword.
I recognize the need and value of commissions/authorities creating standards, but those standards need to work reliably. When using dark mode, WCAG color contrast failed to solve the needs of not only color-blind and contrast-diminished users but normal-sighted users as well.
The rise of A11y as a dedicated profession has elevated WCAG standards into the realm of sacred literature, unchallengeable and infallible – a holy text only heretics would dare question. If you are a scientist, mechanic, or a creator and something doesn’t make sense, then heresy is the only rational response.
Moving forward, the WCAG organization needs better transparency behind its decision-making process and ensures conclusions are scientifically supported by qualitative and quantitative data.
Shout out
Special thanks to Henrik Ståhl for reaching out to me on LinkedIn and encouraging me to write this article. I appreciate it!
Orange You Accessible? A Mini Case Study on Color Ratio. Ericka O’Connor (2019)
APCA: the new algorithm for accessible colour contrast. Juan Ruitina (2022)
메타데이터
- post_id
- 9f33d22211db
- slug
- what-the-wcag-9f33d22211db
- url
- https://uxdesign.cc/what-the-wcag-9f33d22211db
- canonical_url
- https://uxdesign.cc/what-the-wcag-9f33d22211db
- author_url
- https://medium.com/@caoimghgin
- status
- ok
- fetched_at
- 2026-06-28 10:39:35