From LVTF: WCAG/APCA compare

[Myndex]

Responding to a post Originally posted by @alastc in w3c/low-vision-a11y-tf#131 (comment)

The earlier part of this thread is at the LVTF: w3c/low-vision-a11y-tf#131

Responding to @alastc and also adding in @bruce-usab and @sdw32 (and not sure if these pings will work??)

---

As I read through this thread, particularly one titled "shootout",

While I can't post there I can apparently edit, so I changed the name of the thread to "comparison" in view of our recent discussions.

there's two aspects I'm not getting that I hope someone can help with. These come from various experiences from usability testing, where I've seen quite a variety in which colour combinations cause issues for various people. I get uncomfortable when the visibility of a colour combination to people without an impairment is used as evidence for it's visibility from an accessibility point of view.

That is understandable — of course, I have impaired vision, with a different variety of impairments in each eye, and the test subjects thus far have all had impairments, including refractive, ocular age related, and even one individual with rod only achromatopsia and the related photophobia/low vison.

In my case, IOL implants in each eye that have functional issues, one with a UV filter and one without, detached retinas with a full vitrectomy OD, torn retinas OS, vitreal detachment and severe floaters occlusing the foveal central vision OS, and Humphrey scores of -22MD, and a little hypertension macular degeneration just to add a nifty cherry on top. 😳

I mentioned this early on, and I wonder that is the source of the rumor that I don't have impairments and impairments have not been involved in the studies??? This is one of the recent "baffling things."

---

When talking about percentages of colour combinations that aren't right with a particular model, is that out of the whole colour space of combinations, or some sub-set?? 2. Is it in comparison to a theoretical model, or the variety of human sight?

I won't speak for Sam's model — for one of the comparative studies I did in 2019, I used randomly generated colors from the entire available set of sRGB colors. The random distribution of background colors was weighted toward brighter to give the WCAG 2 math a better chance. This was done in view of the fact that designers normally do not choose bad colors.

The results in the 2019 study was WCAG did 49% false passes and 23% false fails relative to a perceptually correct baseline. This was using a much earlier model, SAPC-6, of which I tweeted a chart to you earlier today.

In the below from 2019, the ideal is a flat horizontal line. WCAG2 is the thick red line.

Click for Full:

For more modern charts, see this set I just did last week: these were per Bruce's request for charts that demonstrated how much overlap there is between WCAG 2 and APCA. In those charts, purple is 'both pass" white is "both reject the colors" and blue/cyan is WCAG 2 passes but APCA rejects, and the magenta/pink is APCA passes but WCAG 2 rejects.

---

I think I need to show my current mental modal about this. I am assuming that if you looked at a colour space of hues, and mapped which people (with no visual impairment) could read against white text, it might look something like this:

Okay, so first, no not really — for standard vision on the chart you just presented it would not be a straight line.

The chart you present is not equal luminance from left to right. So StandardVision would have a line that would be lower through blue and red and higher through Green and yellow. (to simplify).

But before I go any father let me just say that there are two separate issues when we're talking about colors and contrast, readability and discrimination (i.e. color coding). These tasks are neurologically separate.

READABILITY

• Readability is a function of luminance contrast (lightness/darkness) and hue/chroma plays little to no part in that, other than:

  • Foveal central vision is all L and M cones ("red" and "green") with no S (blue) cones.
  • S (blue) cones are sparsely scattered in the periphery.
    • Thus blue holds no details, and is not useful for readability.
    • But blue can cause glare and CA that can interfere with readability.
    • We are all "tritanopia" in our foveal vision.
    • The LACK of S cones and blue perception in the fovea AIDES readability.
    • Those with foveal damage that have to learn to read using the periphery haev added difficulty due to blue interference.
  • Some hues are much lower luminance than others. Blue for instance is 1/10th that of green.
  • The green primary in sRGB makes up about 71% of the total luminance.
    • The vast majority of cones are tuned to green.
    • Most cones are L cones, often thought of as the "red" cone but in fact its peak response is a yellowish GREEN.
    • The M cone peaks in a slightly more bluish green.
    • The L cone overlaps the M cone, but the M cone does not overlap the L cone in the red area.
      • Thus the L cone is responsible for the sensation of red.
      • But both the L and M cones are mostly sensitive to green.
    • The L and M cones are responsible for luminance.
    • Blue can actually have a subtractive effect on luminance.
  • Some colors may interfere with each other, blur/red in particular.
  • There are some unique effects regarding self-illuminated monitors.

• Color Vision Impairments (CVD) and Readability

  • Those with CVD have otherwise normal luminance contrast sensitivity.
    • So for readability, there is the matter of hue interference, which is varies across ALL vision types and is not isolated to CVD.
  • EXCEPT
    • Protanopia sees red darker. (missing the L cones)
      • for the sRGB red primary, they see about half the luminance as standard vision. P3 is similar.
        • The red primary of sRGB crosses into the M cone response is why.
      • The new UHD rec2020/2100 they will not see the red primary at all.
        • the UHD red primary is on the spectral locus, and farther from the M cone response
        • For the protanopia, I'd predict they would not see it at all, as if off (black)
        • To be sure, I have not tested a protan in front of a Rec2020 monitor (which I don't have) so this is a math prediction based on well known characteristics of protan response sensitivity.
        • The upshot is that the protan sees colors like reds and oranges substantially darker
        • Red is already very low luminance (21%) so red should never be the lightest of a color pair where readability is concerned.
          • I.e. red on black or black on red is bad for readability.
          • red or orange are best paired with white, other things being equal.
          • Orange is less critical because it contains some green.
          • Also true for purples (blue/red) as blue has minimal luminance and minimal resolution.
    • The deuteranopia (missing M) may see bluer greens slightly darker (about 10%) but functionally do not have a contrast sensitivity deficit (barring other impairments of course).
    • The tritanopia (no S blue cones) does not have an appreciable luminance deficit
      • Blue is low resolution and not useful for readability, and can interfere.
      • We are all tritan in our fovea (if you look at tritan in the CVD sim, it looks close to normal)

TL;DR

• The line would not be straight for anybody, regardless of impairment.
• Of the three main CVD types, only the protan and red is a concern as it pertains to readability.
  • And that one concern is red against black.
  • For red & white, the protan has an advantage.
  • Since they see red darker, with red, orange, or purple against WHITE, the protan has improved contrast.
• Achromats have more serious co-morbid impairments that essentially require AT and personalization.

Okay, that's READABILITY, now color coded information:

DISCRIMINATION

• Discriminating between colors, such as needed for color coded information, is a completely separate function from readability.
  • A different part of the brain is used for discriminating bettween objects and colors, than is used for lexical processing.
  • Color as in hue and chroma/saturation (colorfulness), is processed separately from luminance (lightness/darkness).
  • Color (hue/chroma) contrast is a separate function in the visual cortex than luminance contrast.
    • They are not additive (Legge)
    • Hue/Chroma is a third the resolution and third the contrast strength of luminance.
      • The contrast sensitivity of hue/chroma fall off rapidly at high spatial frequencies, and well before luminance.
      • I.e. big objects have better hue/chroma contrast than luminance, but smaller stimuli requires good luminance contrast.
  • There are a number of techniques for addressing color insensitive vision, namely not relying on hue alone for coding information.
  • Discrimination of colors is not necessarrly related to luminance contrast, though good luminance contrast helps all discrimination tasks.

Here's an example.

People associate deutan and protan as "red green color insensitive" and make the assumption they can not distinguish red from green. The reality is more nuanced. Looking at this chart:

One thing to notice is that the deutan and especially protan DO distinguish red and green due to the massively different luminance. But they have a real problem with green and YELLOW, as yellow is a color that normally stimulates both the M and L cones.

---

Where anything under the line didn't have enough contrast against a white background......Then, if someone had low-vision with less acuity, presumably that line needs to move up?

For readability:

Acuity is best helped with increased size, and increasing size does increase contrast because contrast is mostly affected by spatial frequency for fonts smaller than about 32px (ish - consider a 4px square as an important nexus point).

Because green is the major part of luminance, green on white only works when the green is very dark. The other primary hues should eb the darkest color, and protan sees red darker and tritan sees blue darker, so in those cases white text results in HIGHER contrast for them. Black text degrades contrast for them.

Then, if we accounted for various colour deficiencies (e.g. protanopia) you'd need to adjust that line in various ways depending on the hue used.

For readability and color vision deficiency, mainly the protan is a concern, which relates to red, orange, or purple becoming darker, so for the protan those colors should typically be paired with white.

Let's mention the achromat

• Monochromacy
  • The very rare achromat — there is limited information due to rarity and few studies.
  • Blue cone or rod only monochromacy have serious other impairments such as photophobia and low vision.
  • M cone only face similar problems as the protan.
  • L cone only might be expected to have near normal contrast sensitivity, as does deutan.
    • I have never come across any studies for M or L monochromacy (there must me some, somewhere).

ALL THAT SAID

APCA is using the research of Legge and Bailey/Lovie-Kitchin for determining reasonable and useful thresholds for readability.

The model itself traces to Fairchild's RLab, Hunt's complete model, CIECAM02, CIELAB, CIELUV, Barten, Stevens, C.Poynton, M.Stone, L. Ahrens, and FAA and NASA research, and of course the studies and experiments conducted here for validation.

---

Then, to produce an overall model that accounted for both you'd want to be failing anything under either line:
I'm also assuming that the WCAG 2 formula is similar to the straight line, and the formula behind APCA is more bendy (apologies for the technical language ;-) ) to better match (non-impaired?) perception.

More curvy in the third dimension, not seen in these charts.

It occurs to me that an article by Roger Attrill demonstrates this using color chart software he developed, and he did a compare of WCAG 2 vs APCA, you might like the article especially as I didn't write it LOL.

https://medium.com/@think_ui/why-color-contrast-is-not-as-black-and-white-as-it-seems-94197a72b005

He demonstrates what you are saying.

However, when talking about percentages, what is it if you include all the colours that would fail both? Because (from my mental model above) there are a ton of combinations that are terrible and should fail both, so a ~50% incorrect rate just doesn't sound right.

So I demonstrated that with nice charts here: #30 (comment)

And here's one for a preview:

AND TO BE CLEAR: The current APCA that is public facing handles sRGB red (if fails red on black where WCAG 2 passes it) but there is other unreleased color-related technology we can discuss in a not-public setting, but will need to be for the future rec2020 colorspace.

The PRIMARY focus for APCA is fixing readability, and that is luminance contrast and spatial frequency together, irrespective of hue.

Hue is a factor where hues cause interference, or a loss of luminance for a given impairment (i.e. protan).

Thank you, and please let me know of further questions...

Andy

[bruce-usab]

Yes, got the ping, thanks!

WRT to chart at end, as I now understand it, @Myndex please correct:

1. white == both methods fail this combination of text (x axis hex value) on background color (y axis decimal)
2. purple == both pass
3. cyan == false positive from current metric as APCA fails but WCAG passes
4. magenta == false negative as APAC passes but WCAG fails

Unfortunately, I am not clear on:
  5. how the text/background colors can be represented with only 8 bits on the x/y axis
  6. the meaning of the magenta color in the lower right quadrant -- which @Myndex did try to explain once to me.

I would very much appreciate having some of these graphs, especially the three new ones, as spreadsheets. (But only so much as can be shared publicly.) I trust the results, I just want the option to noodle with formatting.

[Myndex]

Hi @bruce-usab

_1. white == both methods fail this combination of text (x axis hex value) on background color (y axis decimal)

2. purple == both pass
3. cyan == false positive from current metric as APCA fails but WCAG passes
4. magenta == false negative as APAC passes but WCAG fails_

Yes. "The white area is the "minimum contrast" for one or both, depending on the vertically adjacent color edge." so... suffice it that the white area is the "fail" zone.

Unfortunately, I am not clear on:  
5. how the text/background colors can be represented with only 8 bits on the x/y axis

Okay, so both WCAG2 and APCA reduce the RGB color to a luminance as a first processing stage. So for practical purposes the equivalent achromatic color can be represented by a single 8 bit value. FF is white #FFFFFF as is 255 rgb(255,255,255) I.e. just take a single 8 bit value and make it a tuple.

NOTE: APCA converts to luminance in a slightly different way than WCAG2, and allows a simple math trick that helps make sure red on black fails, whereas it passed in WCAG2. That said, I do have unreleased technology that is more active and more direct in processing hue/chroma. Considering the pushback of "it's too complicated" from YatiI and friends, I'm hesitant to show anything beyond what I have thus far.

6. the meaning of the magenta color in the lower right quadrant -- which @Myndex did try to explain once to me.

So any color PAIR is two points that are at the same position on the X axis, and only differ in the Y axis.

Blue means no APCA colors for the target level, and magenta means no WCAG2 colors for the target level.

I would very much appreciate having some of these graphs, especially the three new ones, as spreadsheets. (But only so much as can be shared publicly.) I trust the results, I just want the option to noodle with formatting.

Well those three "new ones" were from a 2019 study, specifically the study where I decided my best efforts should be toward fully exploring and developing SAPC (now called SARCAM) and the derived APCA and related guidelines. Those charts are using some very early model, and much has changed - for instance that was back when 80 = 4.5. But since you asked, I revised the model to include the current APCA, and re-did the charts.

So here are "new" ones, from the setup as the ones from 2019, where perceptually uniform is a flat horizontal line.

Click to enlarge

Regarding the old spreadsheets:

Yes, I need to clean up one of these to send to you... The thing is these are old models, and most of the newer models are built in Octave, JS, or PHP... But I jiggered this one around, so just need to clean it up for you...

Thank You!

[alastc]

Hi @Myndex,

A couple of follow ups:

On the first set of graphs, what is the X axis? It almost looks like CSS codes, but not quite, I'm familiar with needing 3 characters for a hex colour.

Actually, never mind that, the new ones are more interesting!

I was trying to understand the other set as well, which are clearer in the what they are showing, but I'm still not sure what the Y axis actually means in terms of colour? The X-axis on the newer ones appears to be black to light grey in partial hex codes, but is the 00 up to 250 an RGB value? If so, which colour, or doesn't it matter?

Ah, I found the "More Descriptive Description", but I don't understand what this means: "RGB value of both colors as an integer (0-255)", how can it be of both colours? E.g. if the text colour is #555, and the background is 123/#aaa... Both text and background color? Another two colours?! I'm confused.

Questions aside, I think the purple/white charts are what was I was requesting in order to see the overlap and differences, thank you.

The chart you present is not equal luminance from left to right. So StandardVision would have a line that would be lower through blue and red and higher through Green and yellow. (to simplify).

Yep, I did mention it was probably a wavy line, I just thought that there would be a (wavy) line for regular vision, a higher version of that line for low-vision, and different dips for different types of colour deficiency.

Foveal central vision is all L and M cones ("red" and "green") with no S (blue) cones.

Interesting, an old friend used a command line with mid to dark blue text on a black background, which I couldn't read, but he (red-green colour blind) thought was great.
Also, err, the blue links of the web... presumably blue is ok on white, but not on a dark background? (For most people.)

there are two separate issues when we're talking about colors and contrast, readability and discrimination

Yep, and I'd like to keep the focus on readability, the colour-alone SC is separate.

Acuity is best helped with increased size, and increasing size does increase contrast because contrast is mostly affected by spatial frequency for fonts smaller than about 32px

Understood, but in the context of comparison to WCAG2, can we focus on the colour-contrast aspect and assume a given text size, font and weight?

That would certainly help in setting up an experiment to compare them both to user-ratings of various colour combos.

[Myndex]

Hi @alastc

Old Charts

On the first set of graphs, what is the X axis? It almost looks like CSS codes, but not quite, I'm familiar with needing 3 characters for a hex colour.

On the old charts, the X axis lists the text and background color at that point in the chart. Because the goal is looking at luminance contrast, some of these early studies were done irrespective of hue, so the shorthand for what the particular color was is just a two digit hex value. So A3 would be #A3A3A3, and the code 59 : e8 means text is #595959 and the background is #E8E8E8. Below that is an arrow and the estimated luminance of the background.

On those charts, the Y axis is contrast value.

New Charts

Actually, never mind that, the new ones are more interesting!

And the new ones are more useful for show and tell I think — the old beige ones were just for my use or for using in a paper. That November 2019 study was where I realized that there just wasn't any really solid contrast guidelines or math/methods for the narrow scope of readability contrast on self-illuminated monitors, and thus I focused on making one.

...are clearer in the what they are showing, but I'm still not sure what the Y axis actually means in terms of colour? The X-axis on the newer ones appears to be black to light grey in partial hex codes, but is the 00 up to 250 an RGB value? If so, which colour, or doesn't it matter?

The X axis on the purple charts is whatever the "common" color is between the two methods (on the chart that's the straight line triangle).

Both WCAG2 and APCA reduce the RGB color to a luminance as a first processing stage. So for practical purposes the equivalent achromatic color can be represented by a single 8 bit value. FF is white #FFFFFF as is 255 rgb(255,255,255) I.e. just take a single 8 bit value and make it a tuple.

NOTE: APCA converts to luminance in a slightly different way than WCAG2, and allows a simple math trick that helps make sure red on black fails, whereas it passed in WCAG2. That said, I do have unreleased technology that is more active and more direct in processing hue/chroma, though in light of the pushback of "it's too complicated" and what not from Yati and friends, I'm reluctant to present any of that, I figured it best to focus on the most basic version only, as far as public facing material.

Plain Language... or not

Ah, I found the "More Descriptive Description", but I don't understand what this means: "RGB value of both colors as an integer (0-255)", how can it be of both colours? E.g. if the text colour is #555, and the background is 123/#aaa... Both text and background color? Another two colours?! I'm confused.

If I have gained anything from this experience it's that I learned the hard way that I have communication deficits I never knew about. It makes me think that back in the day, no one in any of my corporate work ever actually read my reports: they just skimmed the conclusion and then weighed them, as in literally with a scale, and then "well this is a pound of paper, so it must be good" or something. 😳😎

(that paragraph by the way is my idea of humor, I re-read it twice because it makes me laugh).

Back to 'splaining: for the purple charts, they are all based on dark text on a light background. The background color and text color share a straight vertical line on the Y axis, and are t the same position on the X axis. That was what I was trying to convey with this:

The lower dots are the text color's lightness, and the upper dot is the background color's lightness. So the double arrows point to a color pair.

Infographics FTW

Questions aside, I think the purple/white charts are what was I was requesting in order to see the overlap and differences, thank you.

No, thank you and Bruce 😊, it was Bruce's idea, he asked me to create charts that showed the overlap "like venn diagram".

I have been increasingly concerned that I have not described and explained what is going on here with APCA, and there is substantial misinformation out on the net, not just regarding APCA or WCAG 3, but misinformation about contrast and vision in general, and much of it seems to have expanded in the last year or two, but that may be simply because I'm looking for it.

I think I'm going to end up with a book about contrast well before I finish my book on modern color theory. In both cases I'm going to focus on infographics I think... LOL...

If there are other infographics that you want, or perhaps I should ask, "what are some key things not being understood right now" in the community, so I can create some infographics for that purpose??

Luminance is king...

Yep, I did mention it was probably a wavy line, I just thought that there would be a (wavy) line for regular vision, a higher version of that line for low-vision, and different dips for different types of colour deficiency.

Those charts present hue and saturation, without regard to luminance. For readability, it is luminance, not hue and saturation, that is the primary "color" factor — except for hues that cause interfereance, red for protan, and things like glare related (blue is a big part of that).

All of the scientific literature discusses that CVD have otherwise typical/standard vision and contrast sensitivity (baring co-morbid impairments). Protan sees red dark or not at all so they lose the luminance with that band of light.

The elderly have reduced blue due to yellowing of the ocular media and/or cataracts. Before I had my cataract surgeries, the word was dark, brownish, and blurry.

Here's an example, in 2016 when I was getting my surgeries, I made this for an example to reference. I had a sign with the word Action on it with one foot (30cm) letters on it, and stood 10 feet away to make these examples.

One foot letters at ten feet is close to 6 degrees visual angle, which is an x-height of ~350px or a font size of about 700px.Put another way, it would be a capital E on an eye-chart at a 20/1200 line (if there was one, normally not, the standard chart stops at 20/200 or 6/60).

The reason I bring this up, and the reason I made it at the time, was my interest in how dramatic the color shift was due to the cataract lens. A total darkening, plus the acuity loss, and then obvious a loss of blue — fortunately blue is not needed for reading, but not relevant as the OD acuity pre-surgery made the eye useless otherwise.

Foveal central vision is all L and M cones ("red" and "green") with no S (blue) cones.

Interesting, an old friend used a command line with mid to dark blue text on a black background, which I couldn't read, but he (red-green colour blind) thought was great.

If you are still in touch with him, I have questions... do you know if he was protanopia? or blue cone monochromat? In either case, I'd love to have him as a participant in the study.

Also, err, the blue links of the web... presumably blue is ok on white, but not on a dark background? (For most people.)

If it is just the blue primary of the typical monitor, with no green, then yes — the sRGB blue does cross into the M and L cones a little, but the contribution to luminance is minimal.

Luminance is what is needed for reading. Here's an example:

Standard vision left, Deutan right:

Tritan left, Protan right:

Read? A Billy Tea

....I'd like to keep the focus on readability, the colour-alone SC is separate.

Okay good, the basic APCA (the only version that I've made public facing) is specifically about readability and semantic understandability (object recognition, i.e. understanding that a pictogram is a house or a car, etc).

Coding by color — such as a map or an air traffic control display — IS part of the larger SAPC/SARCAM model, but APCA is simplified to just non-text and readability contrast, as perceived due to spatial frequency and luminance.

...in the context of comparison to WCAG2, can we focus on the colour-contrast aspect and assume a given text size, font and weight? That would certainly help in setting up an experiment to compare them both to user-ratings of various colour combos.

Okay, BUT: spatial frequency (text weight and text size) is inextricably intertwined with the lightness/darkness (luminance) contrast.

WCAG 2 has essentially one single breakpoint for font size: large or small. And "non text" is just thrown in with "large".

Part of the comparison to WCAG 2 is NOT just the color math, but the full APCA guidelines which include color(luminance), but emphasizes font size and weight, because that is the real driver of perceived contrast (for stimuli less than 4px X 4px), and non-text-size and purposes, and use cases, which places the strictest contrast on body text, next then fluent text, then headlines, and large bold elements, then "trash" elements like placeholder text, disabled elements....

I think you've seen this infographic before, but for review, click to see full size, and notice the difference in perceived contrast between the much bigger headline letters and the body text blocks, even though all of them are the exact same colour:

Click to Enlarge

Experiments?

So, one challenge is that WCAG 2 and APCA are two different paradigms.

• WCAG 2 math is a simple contrast ratio that does not follow human perception of stimuli on self illuminated monitors.
- it was originally designed for determining a 7:1 contrast ratio, on relatively dim (80 nit) crt screens, in an environment of webfonts that were available in normal or bold, and at a time when the print industry still flourished with magazines and newspapers.
- Unfortunately the math develops significant issues when it is used on lower ratios, and when one of the colors is darker than the equivalent of #aaa

• APCA uses compound power curves that are fit to empirical data collected through contrast matching experiments.
- The APCA guidelines are focused on the effect of spatial frequency as the primary driver of contrast for things smaller than about 4px.
- Larger things are more affected by the luminance contrast (here, perceived lightness/darkness difference).
- We see for normal weight fonts: at 36px and larger, Lc45 is fine, But from 36px to 14px, we need to increase to Lc 90.
- The preferred is actually Lc90 for 18px, especially if body text.
- Notice that 36px is twice the size of 18px. Notice also that Lc90 is twice the value of Lc45. This is by design.

Conformance

We've now developed more than three separate conformance models. But the three that are of interest right now are:

• Bridge PCA: this is a new drop in replacement for WCAG 2 contrast. It is fully backwards compatible with WCAG 2 contrast, and has bonus enhanced AA and AAA levels. But otherwise, it works just like WCAG 2 contrast — except in the new charts, all the "blue" goes away. SEE: https://github.com/Myndex/bridge-pca#bridge-pca-for-wcag_2

• APCA Simple: this does not use the look-up table, instead it just uses a series of levels, with a minimum font indicated in each, and in that way it's fairly similar to WCHG to contrast conformance.

• The main levels are 30 45 60 75 and 90. There's a more complete description here:

• https://myndex.github.io/SAPC-APCA/WEBTOOLS/APCA/index.htm#accessible-contrast

• APCA with Lookup Table: on the same link as above — using the lookup table obviates adherence to the "basic levels" and allows more accuracy which translates to greater design flexibility.

  • The demo tools, and the tools third parties are building, are all taking the lookup table into account, so determining a font size is a simple and automated task in most tools.

I hope I answered all your questions, please let me know if there are more.

Thank you!