Boundary values?

[clarfonthey]

So, one problem that I've found extremely interesting is the idea of algorithmically generating readable colour combinations -- for example, given a particular background colour, what text colour is a suitable choice to improve legibility?

The most naïve way of doing this for WCAG 2 is to notice that Y=0.179129 is a critical point where white and black have equal contrast, and that choosing white or black as a text colour depending on the side of this value you're on is a very crude way of choosing something legible.

Unfortunately, colours with this luminance are only at a contrast ratio of around 4.6, meaning that they lie in a range which is physically impossible to achieve the 7:1 goal.

In fact, if we solve for the range where we can actually achieve this goal, we get that colours with Y>0.1 and Y<0.3 are completely off-limits, since within that range the contrast is less than 7.

What I'm wondering is it what these boundaries look like for APCA -- if we set a particular colour for the text or background, do we run into a situation where we can't choose a suitable complement that ensures our contrast requirements? To what extent can we get around this by bolding the font or raising the font size?

Note that most of this line of thinking is just for fun, but one case I'd like to use it for is previewing colours on interfaces where we want to be able to force it to be legible, usually by swapping out the background/foreground to a suitable alternative. But there are some pesky colours that just suck when it comes to contrast, and in those cases it may be worth just giving up and showing it to the side of the text in a box with the contrasting pair as a border colour. I'm curious what those colours look like, and I'd imagine the range of "suboptimal" colours to be much larger.

[Myndex]

Hi Clar @clarfonthey Thank you for writing.

Interestingly, I've written some articles on this, and I have a CodePen you can play with that demonstrates the concepts. I put the links to article and codepen after I answer some of your inline questions.

AL GOES RHYTHMICALLY INTO THE NIGHTCLUB

So, one problem that I've found extremely interesting is the idea of algorithmically generating readable colour combinations -- for example, given a particular background colour, what text colour is a suitable choice to improve legibility?

Some of the early APCA adopters created tools like that, and there is a built-in "other color" gen in some of the early alphas, and will be in the packages soon.

A THING: This is easy to do effectively with APCA, or with a dedicated function. It is not so possible to do effectively with the WCAG_2 contrast math, and you may find yourself frustrated to madness.

Here's why: The WCAG_2 math is not perceptually uniform. As such, any given contrast ratio you feed it is not going to provide an expected useful color result. Moreover, the "middle contrast" point that emerges from the WCAG_2 contrast math is incorrect.

On the other hand, with SAPC / APCA (WCAG_3), any given Lc contrast value appears the same, and importantly has "equivalent readability," so long as the lightest color can be less than #fff and the darkest more than #000.

It is significantly more difficult to return one or more matching "theme colors" with useful hue/sat — auto black or white only needs a flip point. To do a contrasting color that considers hue, saturation, and lightness, you need to use a more complete Color Appearance Model (CAM), or at least a perceptually uniform color space, such as https://www.hsluv.org which is a modified CIELUV implemented for sRGB screens.

• SAPC™ is the parent S-Luv Accessible Polyluminant Color appearance model.
• APCA™ Advanced Perceptual Contrast Algorithm is a contrast model, tuned for accessible readability. (I'm toying with renaming to Accessibility Predictive Contrast Algorithm™).
• Bridge-PCA™ a new method, backwards compatible with WCAG_2 contrast, but using APCA technology.

did you know evian water is naive backwards

The most naïve way of doing this for WCAG 2 is to notice that Y=0.179129 is a critical point where white and black have equal contrast, and that choosing white or black as a text colour depending on the side of this value you're on is a very crude way of choosing something legible.

Except the middle contrast point is not Y=0.179129 (out of curiosity, where/how did you derive that particular number?)

HOME PAGE ON DA RANGE

Unfortunately, colours with this luminance are only at a contrast ratio of around 4.6, meaning that they lie in a range which is physically impossible to achieve the 7:1 goal.

There is not enough range in a typical sRGB monitor to have adequate contrast between small/medium black text and white text at the same time with a middle grey BG which would typically be between 0.32 Y and 0.42 Y, depending on the immediate surround characteristics, monitor setting, ambient lighting, and a partition in a linktree.🎶🎵

In fact, if we solve for the range where we can actually achieve this goal, we get that colours with Y>0.1 and Y<0.3 are completely off-limits, since within that range the contrast is less than 7.

Y > 0.1 and Y < 0.3 needs white text, and okay fine for a reasonable font. In the "Fancy Font Flipper" CodePen, in the middle range where the contrast goes down, the font size increases.

DEJA VU

What I'm wondering is it what these boundaries look like for APCA -- if we set a particular colour for the text or background, do we run into a situation where we can't choose a suitable complement that ensures our contrast requirements? To what extent can we get around this by bolding the font or raising the font size?

LOL, I wrote the previous sentence before I read this sentence of yours, so, yes, or

JUST FOR PUN

Note that most of this line of thinking is just for fun, but one case I'd like to use it for is previewing colours on interfaces where we want to be able to force it to be legible, usually by swapping out the background/foreground to a suitable alternative.

It's really not just for fun, there are mission critical use-cases where you need to change text from black to white, etc. For instance in some applications like a spreadsheet where you might have an auto background color based on an operation, and there was text in the cell to display the value of the operation, you might need to be able to force the font color to white if the background goes darker than 0.32 Y (ish).

PESKY

But there are some pesky colours that just suck when it comes to contrast, and in those cases it may be worth just giving up and showing it to the side of the text in a box with the contrasting pair as a border colour. I'm curious what those colours look like, and I'd imagine the range of "suboptimal" colours to be much larger.

If your design is flexible to use black or white text on demand, then there is no real display color in-between that can't have usable contrast with White or Black, PROVIDED that your font is large enough / heavy enough etc.

SLINKY LYNX
Here's an article on this subject, "Let's Flip For Color" with code samples and probably more bad puns.

And here's a CodePen that's setup with a black/white font-flip that also varies the font size:

Fancy Font Flipping

And finally, the APCA Tool.

[clarfonthey]

Except the middle contrast point is not Y=0.179129 (out of curiosity, where/how did you derive that particular number?)

I solved 1.05/(Y + 0.05) = (Y + 0.05)/0.05 -- in other words, the point where the contrast ratio between white and black is the same, per WCAG 2. If you flip around the sides you get 1.05 * 0.05 = (Y + 0.05)² or Y² + 0.1Y - 0.0525 = 0, and solving this gives approximately 0.179129. (for some reason I put an = instead of a ≈ there)

I thought this methodology was right (at least per WCAG 2) since I had seen it used in some places to determine whether you should use a white or black text for a given background, but also programmers are known for guessing things instead of using actual research. :p

[Myndex]

Hi @clarfonthey

....the contrast ratio between white and black is the same, per WCAG 2....and solving this gives approximately 0.179129.
Ah, that's what I thought, I just wanted to confirm... Yes, the WCAG 2 indicates that, but we've demonstrated that WCAG_2 contrast is functionally wrong, and it is definitely wrong in this use case.

I thought this methodology was right (at least per WCAG 2) since I had seen it used in some places to determine whether you should use a white or black text for a given background, but also programmers are known for guessing things instead of using actual research. :p

You are not alone. Color, contrast, digital imaging, vision... these are very challenging fields, and even the experts disagree on some things, and there is more ambiguity than one would want.

I wish I could tell you that there was even a "definitely always do..." for these kinds of questions... but if you play with the CodePen, I think you'll see that there is no bright line for where to flip..., there is a soft fuzzy faded wiggly line. 😁

[xi]

You can of course use the same approach with APCA. You just have to remember that APCA's luminance for black is (0.022**1.414).

For background:

Y**0.56 - (0.022**1.414)**0.57 = 1**0.62 - Y**0.65 => Y ~= 0.34

So the middle background grey in APCA is #a3a3a3 with a contrast to white/black text of 55.

For text:

1**0.56 - Y**0.57 = Y**0.62 - (0.022**1.414)**0.65 => Y ~= 0.33

So the middle text grey in APCA is #a0a0a0 with a contrast to white/black background of 51.

With normal font weight, you need a font size of at least 32px to use these colors according to the look up table.

[Myndex]

@xi You are on the right track Tobias, but your calculations are looking at this a bit incorrectly. You can not conflate the dark mode and light mode values. Dark mode and light mode have DIFFERENT contrast centers.

The far extents, BoW is 99 and WoB is B4, and in common color modes, common BG is about a0 and common text is about af.

Nevertheless for reasons of mathematical simplicity, and taking a conservative and more practical approach to the issue, center contrast for LIGHT MODE is 9e, and center contrast for DARK MODE is a5. Considerations in these settings relate to real world environmental issues, and issues relating to how browsers rasterize text.

[Myndex]

Just to add something that is part of a forthcoming paper:

While 18% is oft characterized as the "center, middle grey" between black and white, that also relates to low spatial frequency, i.e. large patches of solid color.

At high spatial frequencies, i.e. text, the center contrast point shifts significantly upwards. The exact center contrast for high spatial frequency stimuli is not terribly stable, either, and very subject to polarity and proximal field (i.e. adaptation level).

WCAG 2 landed at 18% center through the use of an inverted Weber and the addition of the 0.05 "flare" component. But this does not solve the problem of TEXT and the needed prediction of supra-threshold contrast.