Alternative contrast ratio calculation

[alexkrolick]

The WCAG 2.x contrast ratio calculation is unfortunately not a very accurate metric for text accessibility, especially for non-grayscale backgrounds. It would be great if this tool could bake in some of the calculations proposed for the next version of the standard and let you know if you are hitting the mark in either/both the 2.1 and proposed 3.0 specs.

See discussion here w3c/wcag3#192

[NateBaldwinDesign]

The SAPC algorithm discussed in this thread are not actively used as part of the standard, and are indicated as of this point in time to be used in research only. I believe this may be an experiential enhancement worth investigating. Use of the SAPC algorithm may produce better generated colors, especially in the area of lighter color over dark backgrounds. This is especially important as in real-world use of Leonardo includes a need for curve modeling for target contrast ratios in order to account for perceptual differences when colors are used on varying lightnesses of backgrounds. SAPC may be able to solve this need, as it's not a desirable solution to create custom curves per-product implementation in order to correct a suboptimal formula for contrast.

I do want to note, however, that until SAPC (or some other formula/variation of SAPC) becomes standardized, Leonardo should not support it as the primary method of calculating contrast. If it is incorporated into Leonardo prior to standardization, it should be combined with a sort of fail-safe in order to ensure WCAG standard contrasts are not lost or are at least referenced in the process. For example, generated colors should still have the post-generation checks done using WCAG standard as it's imperative that the tool aid in conforming to standards.

[NateBaldwinDesign]

For reference, research project for SAPC or other such formulas for an enhanced standard on contrast can be seen here: https://www.researchgate.net/project/An-Accurate-Programatic-Perceptual-Contrast-Assessment-for-Website-Color-Schemes

See Status Updates.

[NateBaldwinDesign]

Also: https://www.myndex.com/WEB/WCAG_CE17polarity

[NateBaldwinDesign]

One interesting item to note -- it appears the researcher also proposes a simpler method of determining contrast by subtracting the two color's L* value (CIELAB L value). See "LAB Difference" further down this page https://www.myndex.com/WEB/LuminanceContrast

Some mention in the W3C thread mentions possible use of more perceptually optimized colorspaces such as CIECAM02, which Leonardo currently supports, making this type of contrast generation feasible (w3c/wcag3#192)

[NateBaldwinDesign]

Hi Andrew! I would love to learn more about the research and possible solutions for an update to the WCAG standard. I agree this endeavor is not fully possible to measure effectively. So many factors play into perception of color and contrast that are beyond digital products’ ability to accurately measure (ie screen brightness, color calibration, ambient light, etc). Not to mention size of areas of color and proximity, as you touch on in the w3c thread. However, any advancement from the current relative luminosity measurement is better! I am particularly interested in your short mention of using CIELAB lightness value as opposed to relative luminosity (in particular your mention of CIECAM02, as it’s a perceptual improvement upon. CIELAB). Does SAPC approximate LAB lightness values in RGB? How closely do they relate? Also, HSLuv appears (to my artistic but not mathematical/research based eye) to have the most accurate unity of lightness values across hues. Has this model been considered, or so you have any thoughts/insight there? By the way thank you so much for reaching out!

On Mon, Dec 23, 2019 at 10:02 AM Andrew Somers ***@***.***> wrote: HI @NateBaldwinDesign <https://github.com/NateBaldwinDesign> and @alexkrolick <https://github.com/alexkrolick> I am the principle researcher on color and the inventor of SAPC, I cam across this thread as it is linked to the 695 thread on WCAG. Just popping in here to answer questions of any. GENERAL COMMENTS Predicting how we see contrast is hard because: - Color is not real, it is only a perception. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#20?email_source=notifications&email_token=ADKTFZSNWHUXQVUDA5INDCDQ2DVL3A5CNFSM4JYX6PQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHRQUFY#issuecomment-568527383>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKTFZW7KTTW7RP4ZEPQDBLQ2DVL3ANCNFSM4JYX6PQA> .

-- Thank you, - Nate [image: Nate Baldwin] email | natebaldwindesign@gmail.com web | natebaldw.in phone | (720)345-1656

[Myndex]

HI @NateBaldwinDesign and @alexkrolick

I am the principle researcher on color/contrast for some upcoming standards and the inventor of SAPC, I came across this thread as it is linked to the 695 thread on WCAG. Just popping in here to add some comments and answer questions if any.

GENERAL COMMENTS

Predicting how we see contrast is hard because:

• Color is not real, it is only a perception.
• Contrast is also not real, it is only a perception.
• Contrast and color perceptions are context dependant.
• The eye responds differently in different conditions of light
  • The eye's "cone" photoreceptors only work in daylight (photopic)
  • The eye's "rod" photoreceptors only work in very low light (scotopic)
  • There is a crossover where they both are active (mesopic)

Contrast and color are processed in the visual cortex in multiple areas and over multiple pathways, being filtered/redirected at each step (gross oversimplification). Luminance contrast is processed in V1, the first stage of the cortex, and the resultant perception is very strongly context dependant, and very strongly dependant on spatial frequency.

See this page for a practical demonstration of the spatial frequency aspect: https://www.myndex.com/WEB/WCAG_CE14weight

As such, a pair of colors in isolation to their context cannot accurately predict contrast perception. In fact, knowing a particular CSS value cannot (in isolation) predict exactly how a color will look. My favorite demonstration of these factors is this image:

Both yellow dots are the same CSS value, as is the grey square they are on.. But the context of each dot is different, and are thus processed and perceived differently by our brain. Some people call this an optical illusion, but there is nothing "optical" about it. It is a neurological illusion, the result of how our brain processes visual stimuli.

CONTRAST

Factors for Predicting Contrast on Computer Monitors

Psychophysical:

• Spatial frequency (font weight, stroke width, font size, letter and line spacing)
• Color Difference (luminance difference is three times stronger than hue difference)
• Light adaptation (where the eye is adapted - both total ambient light, and local to the stimuli)
• Individual variation (age, acuity, contrast sensitivity, cognitive, neurological...)

Technical:

• Rasterizer (rendering effects such as anti aliasing, font smoothing, etc)
• Monitor design and colorspace. (wavelength of color primaries).

SO NOW WHAT ?!

If we make some assumptions at the start, we can narrow down what is the obviously very wide range of perception. Let's assume a monitor in the sRGB colorspace with sRGB primaries, so then assume a black level of 1 to 2 cd/m^2, and a max white at 100 to 200 cd/m^2, and an ambient light that results in a surround of 20% of that max white level (20 to 40 cd/m^2).

That gives us a reasonable "standard observer" from which to estimate certain perceptions like color and contrast. The next set of assumptions is context within the design: Font weight, stroke width, size, spacing, padding, overall page lightness, adjacent elements, etc. etc. And a final set of considerations are the psychophysical aspects of critical contrast and critical size for best readability, not to mention the technical aspects of rasterizers and font smoothing.

SAPC and SLAB

"APC" is "Advanced Perceptual Contrast"

SAPC is a set of algorithms that are intended to provide designers and accessibility testers with a workable means to predict contrast for best readability. The companion SLAB is an L*a*b* type color space specifically tailored for modeling sRGB monitors and modeling visual impairments & related accessibility needs.

SAPC is intended to provide a perceptually uniform prediction of contrast for a pair or group of sRGB colors between w3c/wcag#222 and #FFF. In this context, "perceptually uniform" means that 60% contrast will look/feel the same and have the same readability regardless of how dark or bright the brightest color of the pair is.

SAPC is not intended as a "complete" image assessment model like Fairchild's iCAM, or Hunt's very elaborate model of vision. CIECAM02 is also a more complicated appearance model, but could certainly be used. SAPC is specifically about predicting contrast and readability, so it's mission takes us down a slightly different path.

One interesting item to note -- it appears the researcher also proposes a simpler method of determining contrast by subtracting the two color's L* value (CIELAB L value).

∆L* does give a useful result in general, in part because it is easily scaled to the confines of an sRGB monitor. But while CIELAB is still used and very useful, there are better modern methods such as CIECAM02 as you mentioned. While ∆L* is pretty good at indicating lightness difference, as I imply above, contrast is a perception that is not just about the difference. Nevertheless, ∆L* was key to the evolution of SAPC.

Among other things, I wanted the new method to be as simple and easy to implement as possible, and by extension easy to use for designers and accessibility testers. For instance CIELAB has a piecewise linearization near black. For our purposes we can dispense with that as for the narrow context of sRGB contrast, it's actually more useful to clamp or clip the black levels.

Also, while CIELAB uses a single exponent for the luminance power curve, for perceived contrast we find we can attain more accurate results using multiple context-determined exponents for the power curves. Fairchild's R-LAB and some other models do this relating to adaptation for instance. And there is even the question of if log (Weber) or power curve (Stevens) is the best model, but power curves (Stevens) seem to be the winner as they are easy to implement, invertible, and easy to adjust, important as the exponent of that curve varies dependent on adaptation and the spatial qualities of the stimuli.

I discuss this more on the CE17polarity page that you linked above. If you have a data set of color pairs that are perceived as the same relative contrast, the curves that you can fit to that data will have different exponents for the lighter and darker color — BUT ALSO dependant on which was the background, which was the stimulus, and the spatial frequency of that stimulus.

TL;DR

SAPC is a contrast prediction model that is intended to be simpler than a full CAM but still perceptually uniform regarding the narrower scope of perceived contrast & readability on self-illuminated displays.

The most basic implementation simply tests a pair of colors and returns a contrast value and will be part of the first working draft of Silver (the code name for the next generation WCAG) due out February 2020, and expected to become the standard in 2023.

---

Please feel free to ask questions, I do try to answer when I see a notification.

For a good free resource that covers some of the underlying theories, I suggest Dr. Poynton's thesis, available here: http://poynton.ca/PDFs/Poynton-2018-PhD.pdf

Cheers,

Andrew Somers
Color Perception Researcher
aka User "Myndex" on GitHub, StackExch, etc.

[Myndex]

Hi Andrew! I would love to learn more about the research and possible solutions for an update to the WCAG standard. I agree this endeavor is not fully possible to measure effectively. So many factors play into perception of color and contrast that are beyond digital products’ ability to accurately measure (ie screen brightness, color calibration, ambient light, etc).

Hi @NateBaldwinDesign I see you responded to my abrupt accidental post (I had not finished writing it, and finger-mashed the key combo to post ugh!)

I think I answered most of your questions in the actual intended post, but let me know if you have more.

As to:

Also, HSLuv appears (to my artistic but not mathematical/research based eye) to have the most accurate unity of lightness values across hues. Has this model been considered, or so you have any thoughts/insight there? By the way thank you so much for reaching out!

CIELAB is intended more for reflected colors. CIELUV is intended more for self-illuminated colors.

As such, SLAB may be better named SLUV if that seems appropriate. At the moment, the principal goal has been to predict luminance contrast, which by definition means first converting an sRGB into the spectrally weighted Y, then to L^* which is the same for LAB and LUV. (lightness is denoted L^s for SLAB/SAPC to differentiate the different math).

However, SAPC has modules for color, mainly to offset for color vision deficiencies and color related impairments. For example, Protanopia sees red as darker. And blue is a problem for people with some impairments, as chromatic aberration and disability glare can interfere due to the blue component.

The idea with SLAB is a perceptually uniform cartesian space that specifically models sRGB and certain visual impairments — i.e. it's a space for accessibility purposes. But the approach used to Luv may be better than Lab for this purpose, I'm some ways from saying one way or another on that, but I say LAB because that is what most are familiar with.

As I mention in the complete post above, SAPC is not intended as an all encompassing CAM, but specific for the task of assisting accessibility with accurate predictions of contrast and related perceptions, none of which can be truly "measured".

Please let me know of any additional questions,

Thank You!

Andy

[Myndex]

Hi @NateBaldwinDesign Hey Nate, just released the very beta SAPC, there is a javascript implementation here:

Work In Progress SAPC Contrast Tool: https://www.myndex.com/SAPC/

Thought you'd be interested, comments/questions welcome.

Andy

[NateBaldwinDesign]

Thank you so much I will check this out!

[NateBaldwinDesign]

@Myndex Also I'm unclear what "& ATOM", "& IcyATOMsizedgap", or "& T" stand for within the table

[Myndex]

@Myndex are the tables on that page a reflection of updated contrast minimums (ie, font size X with font weight Y needs to meet L80)?

Yes, essentially — but these are interim and not final. Probably will be able to relax them a bit after the color module is integrated.

Eventually, the idea is to have the algorithm spit out results that include the minimum size or weight. In the meantime, those rows provide an example of various combinations of size/weight. Do note that they do not change in this tool: the sizes/weights are static, only the colors change.

Also I'm also unclear what "& ATOM", "& IcyATOMsizedgap", or "& T" stand for within the table

& IcyATOMsizedgap

Just sample text. This is nothing but a shorthand set of characters to evaluate the look/feel of a font. I find it more useful than "a quick red fox jumped over the lazy brown dog". ATOMsizedgap has all the characters needed to evaluate font design, size, weight, and aspect ratio easily, and it's easy to remember (think of the London Tube and "mind the gap", LOL).

Capital A and T make cap height and stroke width/variation clear. O an M are important for aspect ratio reasons. Lowercase s i e d g a hold important design characteristics, and z is essentially the same as x height, but easier to see the effects of vertical antialiasing.. Icy adds a little more info, and I like the ampersand, as the ampersand is the one character that often has the most flourish, particularly for serif fonts.

[NateBaldwinDesign]

Thank you for the clarification. As I'm playing around with the tool I'm noticing some large jumps between when colors have contrast vs. show as 0%. For example, #e6e6e6 registers as having 15% contrast (with white), whereas #e7e7e7 registers at 0% (with white). The difference between these colors is barely perceivable, making me wonder why SAPC shows such a very different contrast value?

Example of #e6e6e6 and #e7e7e7 side by side

[Myndex]

As I'm playing around with the tool I'm noticing some large jumps between when colors have contrast vs. show as 0%. For example, #e6e6e6 registers as having 15% contrast (with white), whereas #e7e7e7 registers at 0% (with white). The difference between these colors is barely perceivable, making me wonder why SAPC shows such a very different contrast value?

Hi @NateBaldwinDesign

Ah hah! I explained why in the comments in the javascript, but LOL me I didn't put the explanation on the page. I will fix. (Doh!)

Everything under 15% is clamped to 0. Doing so makes the math much simpler. Instead of 0 I suppose I could have used the text "too low," but I was afraid that would imply that 15% is okay, and it is not. Maybe instead of "0" just "invalid" or "under range"....

Also, to be clear, the actual values are subject to change slightly, BUT:

25% is the level under which many people will find "invisible". Sure, normal vision of 20 to 30 year olds can see 25% well. but it can be non-visible for many, and under many environments. I.e. 25% may be very visible in a dark room but try it in a brighter environment.

Setting the clamp at 15% places it below reasonable visibility for a large percentage of users, but allows designers to see how far away they are from 25%.

25% is just an advisory, that being "designers should be cautioned that values under 25% will be invisible to many users". The actual minimums for non-text and very large headlines starts at 40%. Again, these values (as scaled) subject to change moving forward.

So 15% is a reasonable cut off point to eliminate certain math anomalies that occur at very low contrasts. Those could be fixed with a more complicated set of curves, but again this is not a "complete image model" we are concerned with readability, so the math is simplified where appropriate, and accuracy is centered around certain critical levels such as 40%, 60%.

Nevertheless, I'm happy to open a conversation regarding more complete contrast prediction — but as you drop down closer to threshold things get MUCH more individualized, and much harder to generalize for a guideline.

Please let me know if that answers your question, or if you have a followup.

Thank you
Andy

[NateBaldwinDesign]

Thank you for that explanation! That clears up what's going on in the tool.

For Leonardo we are trying to support and advocate for a certain use-case that we use for Adobe's color system, which this clamping immediately breaks. By allowing for numeric representation of contrast values for all colors (down to actual zeroes ie white-on-white), designers can create systems of color that are all based on contrast, including non-text elements.

Why would we do this?
Seeing as though people have unique individual needs, and considering that environmental factors also affect the perception of contrast on an interface, we want to fully support and implement a set of controls for users to increase overall contrast of the entire UI. In reading more into the draft documentation for the WCAG contrast updates (Silver), the focus on "personalization" stood out to me as it correlates with this implementation.

Take the example in GitHub here. The borders around each comment may not need to meet 3:1 for contrast minimums, however there are certainly people in the world that have a hard time seeing those borders. Having them more visible may help with the cognitive load of scanning through the page to identify "chunks" of content.

If this page were implemented with Leonardo, the gray you see would be generated by a target contrast. By the SAPC formula, this may be in the ballpark 10% or so. We could integrate controls to allow users to increase the target contrast value as needed. However this is not possible if lower contrast colors register as 0 in SAPC.

Sometimes it's easier to visualize this concept, which is why we've put together this demo page. Every single color in this demo is generated based on target contrast ratio (using existing WCAG formula), including the gray tones that are lower contrast (such as the background color of the calendar, which has a negative contrast of around -1.2:1)

We see Leonardo as a possible solution for designers and engineers to meet the future requirements in a much more meaningful way (ie, not just meeting minimums, but rather advocating inclusive design and personalization of products). In order to do this, we need a full spectrum of contrast available.