More to white text than meets the eye

[Myndex]

Modified from another thread, this discusses the issues of light text vs dark text, and the related issues of font weight, rasterizing, and comparisons with the older contrast standard.

Some general comments:

1. WCAG 3 APCA is a paradigm shift in how visual contrast is predicted and how those predictions apply to design guidelines.
   • WCAG 3 does not compare directly to WCAG2 in terms of results or how it's used.
   • Font size and font weight are part of the key parameters to consider.
2. WCAG 2 contrast is known to be wrong in a number of areas, which is why I've been developing APCA.
   • WCAG 2 is not perceptually accurate, it does not follow human perception.
   • It's only a reasonably useful contrast value when both of the following are true:
     • The text is darker than the background AND
     • The background is lighter than #A0A0A0
3. Per the examples in this thread, the concerns raised don't appear to be due to APCA
4. The total APCA L^c contrast scale from black to white is a little more than 100.
   • It is perceptually uniform, so cutting the L^c in half results in an apparent halving of contrast.
   • The distance between the middle and white or black is around L^c 51 to L^c 54
   • The minimum recommended for fluent content text is L^c60 to 75
   • The minimum recommended for large text is L^c45 to 60

Specifics

Luminance vs Lightness for Readability Contrast

The older WCAG 2 method was created in the very early days of the web; today, there has been substantial advancement in vision science, and we can now see that WCAG 2 (14.3) contrast does not follow human perception of suprathreshold contrast, which is critical for readability. APCA does also use luminance, but it goes much farther, weighting the luminances per a perception model to achieve uniformity that follows our perception of text on a screen.

APCA is rapidly being adopted and added on to design tools across the web. I was surprised by the interest and the large number of early adopters. I was not expecting the interest and acceptance, I'm a tad embarrassed that some of the early code was a little less stable. The current version (0.98G-4g) has been going since February, and is stable, further adjustments are expected to be minor.

In terms of transitioning, there are some developers that are doing both WCAG 2 and 3 at once with success, however you lose the APCA flexibility and some of the areas that APCA has opened up to designers. But it's a good choice if you are in a situation where you must abide by the older WCAG 2 for contrast.

One of the changes in APCA is the recognition of spatial frequency as a primary force driving contrast perception. For our purposes, spatial frequency means font size and weight.

Mid Contrast, and the W/B Switch Point

There are occasions where a developer might want the text color to switch from black to white depending on the background color. The question arises, where should that point be? Conventional wisdom would suggest exactly at middle grey, and middle grey is traditionally considered at 18% reflectance. This is also Ansel Adam's zone 5, and about middle density on a film negative.

So then it might seem correct to choose 18% luminance as the middle point on a monitor, which is around code #777777 for sRGB. However in practical situations this ends up being too dark for text. Another change with APCA is the definition of the "middle" of the contrast range on a display, that mid-point where either white or black text has the same apparent contrast and readability, which is exactly where to flip from black to white text.

The short answer is that if we are going to "auto flip" between black and white, we want to do so when relative luminance (Y) is between 0.32Y and 0.40Y, with 0.35Y - 0.36Y being about ideal for most colors.

This translates to a BG color of equivalent luminance to #999(0.32Y) to #aaa (0.4Y) with #a0a0a0 being a "nearly ideal" 0.351. However, that does not mean that any size font can be used. The APCA contrast for black or white text against #a0a0a0 is not much more than L^c50, and the minimum recommended font is about 32px to 36px for normal weight.

In the example below, just the top two lines qualify, bottom row is a fail for fluent readability:

These colors are from an earlier discussion, and points to why font weight and size are critical parts of the APCA contrast method and the WCAG 3 contrast guidelines.

The font is fairly thin, and perhaps font-smoothing is set to the faux antialias? While the black font is indeed near black, the white font is no where near white, it's only at 48% the luminance of white, so perceptually is about 63% lightness when we'd want it to be ~95% lightness.

This has nothing to do with the APCA algorithm, it's a function of the font weight and size, and the way the rasterizer is antialiasing, reducing contrast. One of the stipulations in WCAG 3 is to not use faux antialiasing, and leave "webkit font smoothing" at auto, which allows the device to do subpixel anti-aliasing. Counterintuitively, the anti-alias setting in Webkit-font-smoothing is actually a blending that reduces resolution and contrast.

---

Responding to Questions about Consistencey with WCAG 2

We have on occasion heard the comment "APCA produces less contrast" — this is not true, though I see how some might come to that conclusion, it does not consider the totality of the new guidelines.

APCA does not produce contrast. APCA does nothing to the colors, it only predicts how a human will perceive them, and their effect on readability. And yes, if you try to compare APCA to the WCAG2 math it might appear that APCA allows lower contrast in some specific cases where one color is white or very bright, but across the entire range APCA clearly, consistently, and correctly predicts contrast, while WCAG2 more often than not allows lower contrasts that have even been shown to be unreadable, even with normal vision.

Here's an example:

WCAG reports this as a "fail" at 2.97:1. APCA reports the contrast as readable at Lc61 if you use the appropriate font sizes. Let me ask you if that seems like less than 3:1 contrast? Perhaps it's not fair without a comparison. Take a look at this sample below to compare, which one has better contrast? The one above or this one below?

After thinking about this for a moment, click the spoiler for the answer:

**Spoiler: Which is better contrast? Click for Answer**

Okay, so the first example is the Orange Example I am running on the APCA site. The "orange problem" brought WCAG 2.x to my attention and is part of why the design community loathes WCAG 2 contrast, and why WCAG 2 contrast is not widely adopted except when required by force of law.

In the first example, APCA correctly reports the contrast as readable at Lc61 for the appropriate font sizes. WCAG reports a fail at 2.97:1. Yet the white on orange is clearly readable, in fact it is even more readable for individuals with color vision deficiency.

Okay, and on the second, darker, sample, APCA reports a total fail and actually prohibits any readable text at this level (a low Lc31, half the contrast needed for readable content).

But... WCAG reports the second one as a PASS at 4.5:1 (!!)

Should this second one be a pass? Should it be called 4.5:1? The colors are #797979 and #110402. APCA fails it for all text, but WCAG 2 says it's 4.5:1 and fine even for body text. Here's a body text sample with those same colors:

WCAG 2 says this is fine and passes AA. Do you agree? I don't, and neither does APCA.

FACT: When the brightest color is darker than #a0a0a0, WCAG 2 degrades until it is no longer providing useful results.

FACT: While WCAG2 might have been okay 15 years ago when there were only web fonts, today's CSS designs and freely available fonts like Google Fonts demands a more accurate contrast method.

Grand Central Problem

And here is a main issue: the numbers generated by WCAG 2's contrast math are not relative to human perception of supra-threshold contrast, which is the contrast needed for best readability. APCA very specifically is perceptually accurate, and predicts constant contrast across the entire visible range. WCAG values are artificially inflated over part of the range to try and make up for these shortcomings, but APCA does not need any such "brute force", and instead accurately predicts contrast which allows for a more flexible and larger set of colors for designers to use.

APCA guidelines are much more aligned to use cases and element spatial frequency (i.e. size and weight). Body text has a higher contrast requirement than WCAG2, as it should. Body text has a high spatial frequency and requires the highest contrast. But what about when you have a third element like a button? WCAG 2 forces the same contrasts making the designer's job difficult. But in APCA, as it is perceptually accurate, we can point out that a large element like a button works well with a much lower contrast, such as Lc45, even as low as Lc30. This gives the designer greater flexibility while also improving readability.

Since APCA is perceptually uniform, one correct Lc value works across the entire available range.

At the SAPC development site, we have a "Research Mode" you can click that reveals some interactive experiments that demonstrate some of the concepts.

And here are links to some brief articles (shorter than this post LOL) with loads of examples that more fully demonstrate this:

Comparison Article: The Lighter Side of Dark Backgrounds

Comparison Article: Orange You Wondering About Contrast?

Regarding consistency concerns between the old and new:

      It is not possible to create something that works correctly
      and also be consistent to something that is incorrect.

And that is the problem we face with APCA. There is no way to compare the two. WCAG 2's problems are well understood. APCA is superior in accuracy and useful predictions. Fortunately, there is enough overlap that a "transition" can be had, some of the tools developed by other developers have a "pass all" setting, to pass both WCAG 2 and WCAG 3 at once, though the trade off is a loss of the flexibility that APCA normally adds.

WCAG 2 and APCA Shootout

Here is the old WCAG 2 1.4.3 contrast guideline against the new WCAG 3 APCA contrast guideline. As the links above also show, this is not an isolated case. Using thousands of random colors, WCAG 2 incorrectly passed 49% colors it tested — colors that were too low in contrast to read.

(click image to view it ful size/full screen)

Also, APCA has an "escape level" called Score 1, it is the weakest passing score, and considered "poor" but placed there so as to allow sites to pass that are currently passing WCAG 2, while providing guidance to improve to the newer standard.

A Few Background Notes

In April 2019 I started thread #695. In that thread I explain how and why I ended up taking this on as a full time research project. I originally thought I'd be done in three months. LOL. I mean ROTFLMAO. Going into year three, I can say that we will have a new readable world!

The internet killed the print industry. Magazines are all but gone. I miss reading real paper, and I find it very difficult to read on a screen. In fact, I believe the reason that so few people actually read today is due to this issue. Consider the chilling effects of a populace that declines reading, as a civil rights author, I can find no better motivation that making the world a more readable place.

TL;DR (LOL)

APCA is demonstrably superior to the old method, but is also more involved than the distance between two colors, as spatial frequency is a key part of the prediction.

Feel free to discuss this or start a chat of your own with APCA questions here.

Thank you,

Andy

Andrew Somers
Invited Expert, AGWG, Silver, LVTF
Myndex Color Science Researcher
Inventor SAPC/APCA

THE REVOLUTION WILL BE READABLE™