When you look at this entry about CSScolor-contrast() function, there is a reference to CIE Luminance being used in WCAG's formula(Yl + 0.05) / (Yd + 0.05). This seems to be the right direction, but what confuses me is that I was under the impression that WCAG did not use CIELAB at all and that APCA solves for that instead. What am I not getting?

https://www.w3.org/TR/css-color-5/#colorcontrast

Yes, definitely helps clarify between CIE Luminance, CIELAB, CIELUV and SAPC with the latter being a mixture of curves.

@Myndex – at your leisure, I would appreciate having the numbers provided in OP. Fails and passes is good, but I also want to see how close each sample gets. An APCA pass/fail is also not an unambiguous term for me (at this moment in time).

Relatedly, and maybe this should be its own discussion, I would like to understand better the statement thatL^c 60 is sort of like 4.5:1.

Thelookup table for 12pt/16px normal weight has75 which I agree with. Currently, I do notfeel like L^c 75 for body text is aspirational — Ifeel like that is the minimum! But I also think I need to work harder to align my gut intuitions to a more clinical analysis.

Hi Bruce@bruce-usab

Sorry for the delay, to answer your question of what the values were for the pass fail tests. I made them small below just for reference.

In reference to the below values, In the worst case when WCAG_2 is incorrectly passing colors it should fail, APCA is failing them by about Lc30 or so which is about half the contrast needed to properly pass.

For the colors WCAG_2 is failing but should reasonably pass, APCA is passing them by about Lc15 or so. This is with the full APCA. With Bridge-PCA, the false failings are the same (must be for backwards compatibility). This also means that Bridge-PCA fails the false passes by more like Lc45.

If we convert this to ratios similar to WCAG_2, then that means for dark colors that WCAG_2 rates as 4.5:1 are actually about 1.8:1, and colors light colors (white text on a color) that WCAG_2 rates as failig 3:1 should be about 4.5:1, and 4.5:1 should be about 6:1

Examples of WCAG 2 incorrect passes of unreadable content

In these examples with black text

• the left color panels pass WCAG_2 at 4.5:1, but fails APCA at a low Lc33
• the right color panels pass WCAG_2 at 3:1, but fails APCA at a very low Lc21

Examples of WCAG 2 incorrect fails of okay content

In these examples with white text

• the left color panels fail WCAG_2 as less than 4.5:1, but pass APCA at ~ Lc76
• the right color panels fail WCAG_2 at 3:1, but pass APCA at ~ Lc61

Hey Bruce,@bruce-usab

I created this chart that really lays out the differences incrementally.

In the top half of the chart, each row has the same TEXT color, in the bottom half of the chart, each row has the same BG color. I think this does the best job of demonstrating how the different key levels compare. The blank light-red areas indicate where the end of the visible range was reached for the given contrast level.

Edit to update: all sample fonts are at 400 weight, sizes changed per APCA. Columns extended a bit as well, with cells that don't quite hit the target, that cell's LC value is listed in the pink area.

DISCUSSION

On the far left column, the text is obviously bolder, as required under APCA guidelines per the current APCA tool, for that font size and weight.

While WCAG_2 degenerates to an unreadably-low-contrast as colors get darker, APCA maintains readability across the visible range, and you may notice a slight increase in contrast for darker colors to address the cases of display flare and misadjusted black levels in monitors, and particularly the psychophysical phenomenon relating to colors in the mesopic range of vision where rod-intrusion impacts contrast perception (Rudd et al 2007).

Thank you!

Andy

Hi Bruce@bruce-usab

Thelookup table for 12pt/16px normal weight has75 which I agree with. Currently, I do notfeel like Lc 75 for body text is aspirational — Ifeel like that is the minimum! But I also think I need to work harder to align my gut intuitions to a more clinical analysis.

I want to address this one further:

As you know one of the things I have tried to balance is that of not failing existing sites that are generally well designed, and a desire to have a "certain amount" of alignment with WCAG 2 and 1.4.3. This led to some of these values. Among the issues that are not as well resolved (though "stuff is in the works") are that of x-height, and uniform font weight properties, and some issues relating to how different browsers rasterize fonts, etc etc...

The pressing question has been, what is too much, what is not enough — too much degrades design flexibility, and too little does not achieve the desired results of accessibility and readability.

WCAG 2 has both of these problems. At times, demanding more than reasonably needed causes "false fails" and the more serious problem on the other end allowing false passes.

The false fails annoy designers and clients who want to know why something perfectly readable is being rejected. Meanwhile skilled designers get no benefit from the false passes, as they would not choose color pairs so unreadable in the first place. The fact that anyone can see that something is unreadable even when WCAG_2 passes it led to the current climate of confirmation bias as in "oh it works".

But it doesn't, it onlyseems to work because people manually toss out the false passes. But CSS is planning an automatic color contrast property which will won't be particularly useful without someone to intervene and toss out the bad colors manually, which is demonstrated in the comparison Idiscuss in this article on TangledWeb. (written in a different style that I write here fwiw.)

No ifs ands or LUTS

That said, I've been working with the LUT, rebalanced a bit again, moving Lc 75 to apply to 18px, and moving 16px to Lc 80, and considering bumping the entire 16px row up another Lc 5 so that 16px normal weight is Lc 85, and keeping 14px as the hard minimum for body text at Lc 90. At the same time, fonts larger than 32px were getting a bit more than needed.

If you look at the chart, the central "body text zone" has the most movement, Lc 60 for 24px rapidly climbing to Lc 90 for 14px. This is in keeping with well established contrast sensitivity/spatial frequency curves. 24px normal was chosen as the pivot on Lc60 for alignment with WCAG_2. That and in working with Bridge-PCA, I see two ways to handle conformance.

1. The lookup table method for greatest flexibility and accuracy.

2. The"basic levels method", for a simpler and more WCAG 2 like approach.

For#2, basic levels with no lookup needed, the levels each indicate useful minimum sizes.

These general levels are appropriate for use without reference to the lookup table.

• 90 • Preferred level for fluent text and columns of body text with a font no smaller than 14px, or non-body text with a font no smaller than 12px. Also a recommended minimum for extremely thin fonts (light weight). Lc 90 is a suggested maximum for very large and bold fonts (greater than 36px bold), and large areas of color. This level is similar to ISO 10:1.
• 75 • The minimum level for columns of body text with a font no smaller than 18px, or non-body text with a font no smaller than 14px. Also, should be used for any text where readability is important. This level is functionally similar to 6:1 ~ 7:1 relative to WCAG2.
• 60 • The minimum level recommended for readable content text, that is, text you want people to read, and no smaller than 16px, and not used as body text. This level is functionally similar to the old 4.5:1 in WCAG2.
• 45 • The minimum for larger text (larger than 24px normal weight or 19px bold) such as headlines, and large text that should be fluently readable. This is also the minimum for pictograms with fine details, or smaller outline icons. This level is functionally similar to the old 3:1 in WCAG2.
• 30 • The absolute minimum for any text regardless of size or weight, including text for spot reading such as placeholder text, disabled element text, copyright, etc. Also the minimum for "understandable" or "uniquely identifiable" non-text elements such as "mostly solid" icons or bold pictograms, and controls or focus with a minimum dimension of 4px on the shortest area. This is the minimum for controls such as radio buttons or checkboxes,provided they are of sufficient size and thickness.
• 15 • The absolute minimum for any non-text that needs to be discernible and differentiable, such as dividers, and in some cases form outlines, but intended more for disabled elements, such as a disabled submit button — and this applies to the buttonshape and not the text (text of a disabled element is Lc30). Designers should treat anything below this level as invisible, as it will not be visible for many users. This minimum level should be avoided for items important to the use or interaction of the site. The range from Lc15 to Lc30 should be approached carefully and never used for elements that are critical to a task, such as a checkbox or radio button, except when they are in a "disabled" state.

The Revised Lookup Table

Same guidance as before except to add:

• Cells marked with^B may be used for body text. If the indicated contrast is lower that Lc 75, then add lc 15 to this minimum, OR increase up to Lc 75.

As I mentioned, considering bumping the entire 16px row up 5px, and also extending the body text range up to 28px or 34px. And in these cases, the key is if the indicated value is less than Lc 75, then add Lc15 to it.

NOTES ON FONT SIZE

Font sizes listed above assume an x-height ratio of at least 0.52. Font weight is based on highly standardized reference fonts such as Helvetica or Arial. "px" means the CSS reference px not device pixels. The reference px is defined as 1.278 arc minutes of visual angle.

All for now, thank you for reading!

Andy

Hey Bruce@bruce-usab

Venn-Type Diagrams

Let me know if this answers your questions as far as Venn diagrams-type charts are concerned. Except for Lc30 and Lc45 against 3:1, I just did two are a time to make things most clear. WCAG is cyan, and APCA is magenta, and transparent so you can see the overlays.

These charts use the data that created thegreyscale chart above, with some adds. Like the greyscale chart, the first set of these charts all have a common text color (hence the straight line/triangle). The second set is for a common background. The white area in the middle is "contrast' — the larger the vertical distance between the top and bottom colors is more contrast. You'll notice that WCAG_2 vertical distance decreases as color get darker, the opposite of what needs to happen for readability contrast.

This is the current "G series" constants which haven't changed since February 2021. These are also for dark text on a light background. Reverse polarity would beslightly different.

WCAG 2 & APCA Common Colors as per Key Levels

This is a test of the WCAG 3:1, 4.5:1, and 7:1 levels relative to the closest APCA levels, Lc 30, Lc 45, Lc 60, Lc 75, and LC 90.

A discussion of how to read the charts after.

COMMON TEXT COLOR

COMMON BACKGROUND COLOR

EDIT TO ADD: How to read the charts

More Descriptive Description

The Y axis is the RGB value ofboth colors as an integer (0-255). The X axis is the HEX value (00 - ff) of theshared text (or the shared background) value. "shared" means that both WCAG and APCA are using the same color. For the first charts, both are using the sametext color, but the BG color is different, and vice versa for the last set of charts.

An rgb value of 123 meansrgb(123,123,123) and a hex value of aa means#aaaaaa

The white are is where both WCAG and APCA say the contrast ininsufficient for the given level.

Chart Legend

• WHITE: Insufficient contrast for both WCAG and APCA
• CYAN: WCAG passes
• MAGENTA: APCA passes
• PURPLE: Both APCA and WCAG pass

This means any background color in the colored area above passes when matched to a text color in the colored area that is directly below per a vertical straight line, at at least the indicated ratio or Lc value.

Colors to be compared with those directly below/above.

Some of the charts have sharp vertical lines. Where are these coming from?

If a text color is at 000, then that defines the last background color possible. Similarly if the background hits 255, then that defines the last text color available. The vertical line in the shared color indicates the point that APCA hits that end wall before WCAG does.

DISCUSSION

As can be seen, and we already knew this, for certain key levels APCA provides just a few additional colors at the very high-end when colors are lighter. However WCAG passes a very large quantity of colors in the dark area. And what's worse, is that at some levels WCAG actually reduces the sRGB color distance as colors get darker!! That's the opposite of what we would want to see for readability.

Note on "number of colors"

Looking at these charts, it's probably obvious that APCA presents fewer colors than WCAG. However, that's for fluent text, AND the APCA colors are all useable, whereas the "extra" colors of WCAG are by and large not useable. The magenta areas are where APCA has more colors than WCAG, and these ARE usable per the APCA guidelines.

BUT ALSO: APCA has additional use cases that permit Lc 30 for some non-text items like large buttons ormap areas(I still need to answer your post on that), and some ancillary text like placeholder and disabled items and copyright, which expands the useable colors to exceed WCAG. See the first and seventh chart, the light lavender area defines this extended zone. (And even then, as you can see Lc30 isSTILL stricter than WCAG in the dark areas).

The upshot:

YES, APCA demands higher contrast forTEXT than WCAG, especially for body text.BUT APCA extended use cases improves design flexibility by relaxing contrast in accordance with human perception of low spatial frequency elements.

Please le me know if you have any questions!

Andy

And what's worse, is that at some levels WCAG actually reduces the sRGB color distance as colors get darker!!

@Myndex can you explain this a little more?

Hi Bruce@bruce-usab (Also@danhollick this post more clearly answers your question)

These are fantastic@Myndex ! I think this is exactly the sort of thing which makes compelling cases.

Thank you! Based on your suggestion last year, I've been trying to"show" as opposed to "write unwieldy long essays on the minutiae of photons impacting retinal cells and stimulating neurological responses"

Do you have Excel or OpenOffice Calc versions you would be willing to share?

There is an openOffice spreadsheet with the basic APCA math in the "PORTED" folder. BUT that does not have these charts... let me clean up the file and I'll email it. Remind me if I forget LOL.

Sorry, but I am not entirely clear what you are these are illustrating! (Yet, go figure, that does not temper my enthusiasm!) Please be patient with me...

Thank you for being patient with ME. One of the more painful discoveries is my communications deficit, and on that there is a recent study that was like a "oh, that" where things suddenly fell into place.THE STUDY.

More Descriptive Description

What is the Y axis? I read "Text Value (INT)".
I do not understand what you mean by "shared background".

My bad for labeling it that way.

The Y axis is the RGB value ofboth colors as an integer (0-255). The X axis is the HEX value (00 - ff) of theshared text (or the shared background) value. "shared" means that both WCAG and APCA are using the same color. For the first charts, both are using the sametext color, but the BG color is different, and vice versa for the last set of charts.

An rgb value of 123 meansrgb(123,123,123) and a hex value of aa means#aaaaaa

Please go into more detail for just one chart. What is white? Is that where both the 2.0 ratio and Lc agree that the contrast is sufficient?

Insufficient

I was expecting to see areas where both 2.0 ratio and Lc agree that the contrast is not sufficient. I am not finding that, so am I missing something rather fundamental about what you are illustrating?

Doh to me for not being clear. The white are is where both WCAG and APCA say the contrast ininsufficient for the given level.

I was expecting to see illustrations of areas where 2.0 ratio passes while Lc fails — and vice versa. I think you have that, but I am not understanding which areas are what.

Here is what I should have written:

Chart Legend

• WHITE: Insufficient contrast for both WCAG and APCA
• CYAN: WCAG passes
• MAGENTA: APCA passes
• PURPLE: Both APCA and WCAG pass

This means any background color in the colored area above passes when matched to a text color in the colored area that is directly below per a vertical straight line, at at least the indicated ratio or Lc value.

Colors to be compared with those directly below/above.

Some of the charts have sharp vertical lines. Where are these coming from?

If a text color is at 000, then that defines the last background color possible. Similarly if the background hits 255, then that defines the last text color available. The vertical line in the shared color indicates the point that APCA hits that end wall before WCAG does.

Note on "number of colors"

Looking at these charts, it's probably obvious that APCA presents fewer colors than WCAG. However, that's for fluent text, AND the APCA colors are all useable, whereas the "extra" colors of WCAG are by and large not useable. The magenta areas are where APCA has more colors than WCAG, and these ARE usable per the APCA guidelines.

BUT ALSO: APCA has additional use cases that permit Lc 30 for some non-text items like large buttons ormap areas(I still need to answer your post on that), and some ancillary text like placeholder and disabled items and copyright, which expands the useable colors to exceed WCAG. See the first and seventh chart, the light lavender area defines this extended zone. (And even then, as you can see Lc30 isSTILL stricter than WCAG in the dark areas).

The upshot:

YES, APCA demands higher contrast forTEXT than WCAG, especially for body text.BUT APCA extended use cases improves design flexibility by relaxing contrast in accordance with human perception of low spatial frequency elements.

Thanks again for all your hard work on this!

Thank you for asking! I would not have built this otherwise, as I'm scratching my head right now trying to figure out how to communicate what is a fairly abstract and densely complicated subject.

two quick questions from someone new to the space. understanding that these use cases demonstrate the superiority of the APCA standard (which appears to still be a work in progress):
(1) is there any research demonstrating what value wcag2 color contrast standard does have, e.g. is it better than no standard
(2) with respect to the use cases where apca is superior to wcag2, is there any measure of prevalence on the web for these use cases? i would love to understand if implementing wcag2 color contrast is better than nothing during the period in which APCA standard is finalized.

Hi@Myndex

• If you must follow WCAG 2.x levelAA, and are legally obligated to the absolute letter of the WCAG_2 spec, then it is safest to useBridge-PCA. Bridge-PCA maintains backwards compatibility with WCAG_2, but improves accessibility far beyond WCAG_2, expcially for "dark mode".

I'd like to learn more about BPCA and think of applying it as you suggested.

The first thing I noticed onBPCA calculator is that "WCAG compatible" ratio changes while swapping text and background colors. If my memory serves well, WCAG contrast ratio should remain the same in case of text/background color swapping.

Then I checked the default sample colors (#1234b0 on #e9e4d0). Its WCAG 2.1 contrast ratio should be 7.68:1 rather than 5.1:1 or 5.6:1.

Perhaps I misunderstand the meaning of "WCAG compatible" here?