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 https://github.com/w3c/wcag/issues/695

[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 (https://github.com/w3c/wcag/issues/695#issuecomment-483805436)

[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 notifications@github.com 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 https://github.com/adobe/leonardo/issues/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 #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.

[Myndex]

Hi @NateBaldwinDesign

Well as I said this is not at all the standard yet, and these sorts of questions are why I'm out doing some demonstrations. I had initially set the clamp at 10%, but some tests indicated to me that 15% was more appropriate.

Do please keep in mind that perceived contrast has much more to do with the spatial frequency of the stimuli than an arbitrary pair of colors, especially at very low contrast values.

Individualization/customization for user needs is the ultimate goal of the research I am doing, so I think we're on the same page. I'll take into consideration tracking/predicting lower contrast levels below the level that would generally be considered useable... or at least providing an extension to the basic methods.

Thank you!

Andy

[NateBaldwinDesign]

I really appreciate that, thank you! 😄 and thanks for providing all these details. I’m glad to be able to provide some feedback. I am very excited about the future updates, and grateful for all the research you have been putting into this!

[NateBaldwinDesign]

FYI: Beta script https://github.com/Myndex/SAPC/blob/master/JS/SAPCsRGB.js

[Myndex]

Hey @NateBaldwinDesign Nate!

As You may know, the first public draft of the new WCAG 3 is soon to publish. Along with the new text, I've also been updating the SAPC tool.

One of the things you asked about was a "full range" down to very low (1%) contrasts. I have a separate link for a version that goes down to under 1%. This is not any sort of official version, it is experimental — but I'd love to hear your feedback. (Especially in terms of tracking consistency).

The link is separate from the main tool that's mentioned in the FWD:

SAPC/APCA Tool, Full Range Version:

https://www.myndex.com/SAPC/FullRange?BG=7a8aaa&txt=828499

It also has a number of other features to make a few things more clear, including a draft lookup table that associates font weight and contrast.

Thank you!

Andy A Guy Obsessed with Color.

[NateBaldwinDesign]

Thank you so much @Myndex ! I took a brief look at the tool and it seems to be exactly what I would hope for. The values below 1% are incredibly valuable to see. I am not sure that I'm seeing any consistency issues, however that would all be based on my own perception, which is highly subjective.

So long as this is available in some form / version of the SAPC formula, I would be ecstatic. The work would be on my part downstream to find how the new formula affects concepts in Leonardo such as "increasing contrast" (eg, linear scaling may not behave as expected, etc), however those would be Leonardo-related issues; not SAPC. I would have to take a much deeper dive into implementing SAPC into Leonardo until making any other conclusions, however I believe that this gives us what we need.

I'm thrilled to start looking into how we can adapt Leonardo in order to support the spirit and objectives of the new SAPC formula. The table that you display is also very helpful, as now the requirements for a color are not entirely based on a desired contrast ratio, but rather they are based on specific font metrics. For designers, this means entering the font size, and weight and then use those as parameters for calculating what contrast ratio Leonardo would need to return. Very exciting!

Thank you again for heeding my pleas and the use-cases and objectives we have for Leonardo and for Adobe's design system, Spectrum.

[NateBaldwinDesign]

One thing I have noticed, however, is that contrast percentage is higher for dark color pairs, even when they appear to have just as low of contrast as a lighter color pair

Example URLs: https://www.myndex.com/SAPC/FullRange?BG=364f81&txt=3d448f https://www.myndex.com/SAPC/FullRange?BG=ffffff&txt=fafafa

[NateBaldwinDesign]

And the darker end of the spectrum shows as 0% when it appears close to the other examples: https://www.myndex.com/SAPC/FullRange?BG=020a45&txt=000000

[Myndex]

Hi @NateBaldwinDesign

Did you just take those? I ask because this morning I've been working on the code — and then I had to get on a conference call...

As a result some of the offsets were turned off... If you happen to see the "Experiments In Progress" sign, that means that a dev version like this is being tweaked, and may exhibit unusual behavior. To be honest I thought I'd be done before the call, DOH!.

THAT SAID: One of the things I am working on, and a reason I was just clamping at 10% before, is the far extremities have minor inconsistencies (typically less that a few percent). This is in part because again the purpose of this method is readability, so the critical areas to be most accurate are 40% to 80%, and definitely not threshold. Nevertheless, I'm working to smooth out the near threshold levels.

It may not be possible directly, and I may need to create a new method — I was trying to do this with a mod to SAPC which is licensed to W3, so available (MIT License IIR).

I have been also trying to adjust the 1% level close to visibility, as 1% is the normal vision visibility threshold for a contrast chart at the eye doctor. Less than 1% is literally invisible.

But might not be directly possible as the method was designed to be simple and focus on readability critical contrast.

[Myndex]

Also, your monitor calibration and ambient room lighting will affect your results as far as what you see.

On my monitor, the first post comparing 364f81 3d448f and ffffff fafafa looks fairly correct. The 364f81 3d448f has clearly more contrast than ffffff fafafa The ampersand is clearly visible on 364f81 but nothing is visible for ffffff, at least on THIS monitor. It'll be a bit before i can get to the studio and check on the reference monitors, though this one is hardware calibrated so I expect similar results...

As for the third example, there is a soft black clip that I've been working with/adjusting this morning. It's purpose is to compensate in part for real-world ambient lighting in uncontrolled conditions causing screen flare, and other issues. It affects colors near black, as in less than about 0.6Y or so.

[Myndex]

Just FYI I wrote a different lo-contrast module... I think it works more smoothly ... I added to the main tool with a cap at 2%, but I'll leave the fullrange page up for you with no cap, if you want to play around with it.

A

[Myndex]

Hey Nate @NateBaldwinDesign

Just wanted to let you know that I've promoted the FullRange version to stable beta, and moved the dev version to another location.

ALSO: in reference to your above examples: I should mention SAPC right now is only doing luminance contrast.

If you compare hue or saturation, even if they have the same luminance, the hue or saturation are perceived as separate contrasts. In the visual cortex, luminance contrast is filtered by v1, but color hue and saturation by v4 and v8.. There is a color module in development, but won't be part of the Silver first draft.

Here are some examples:

Unsaturated

1% luminance, unsaturated it is essentially invisible: https://www.myndex.com/SAPC/FullRange?BG=dddddd&txt=d6d6d6

Saturated

But if one of the colors is very saturated: it makes it very apparent, even thought the luminance is identical. https://www.myndex.com/SAPC/FullRange?BG=dddddd&txt=dddd39

Saturated and Equal Luminance

And here's one: absolute zero luminance contrast: luminance is the same 72.83 Y on both, but one is saturated and therefore contrasting: https://www.myndex.com/SAPC/FullRange?BG=dddddd&txt=22fbb8

Something to mention: Luminance contrast is three times stronger than hue/saturation contrast. And luminance holds more detail, while hue/sat is lower in apparent resolution. This is one reason that it is critical to have luminance contrast first and foremost.

Remember: there is no such thing as contrast in a "real" sense, it's only a perception that happens in your brain. I have a bunch of this discussed at our Visual Contrast Wiki: https://www.w3.org/WAI/GL/task-forces/silver/wiki/Visual_Contrast_of_Text_Subgroup

[Myndex]

Hey Nate! @NateBaldwinDesign and also hello Alex! @alexkrolick

I wanted to let you know that the "new improved" SAPC and APCA are now live to play with. There have been some substantial changes and I'm excited to share:

What and Where

The basic simple version is the APCA page, it includes the new scaling and the dynamic font matrix.

The development version is the SAPC page, and this version includes the new RESEARCH MODE, which has some different tools you can activate to investigate the nature of a color or colors, including a simplified version of the middle contrast experiment - on the SAPC app it's called "split contrast mode".

The New SAPC at a Glance

• Now substantially more accurate in terms of perceptual uniformity — twice as accurate to perception as the APCA I released last year.
• For the majority of the range, doubling or halving the L^c contrast number equates to a doubling or halving of the perceived contrast. (Based on the empirical data from the 2020 "Middle Contrast" experiments.)
• If you have been working with the code, it has changed, and there is a whole new set of constants.
• This new version sets the levels a little differently, so what was 80 is now about 60, and so on.
• Rescaled lookup tables — to adjust to the newly scaled output.
• Full range is now standard and via a new method that brings in the uniformity (doubling/halving).
• And by full range, I mean all the way to zero, including a smooth crossing over zero.
• While 8 bit monitors are too low in rez for actual clinical accuracy, we are now measuring down to clinical threshold values. There may be some more tweaking here... I would be interested to hear your feedback regarding this.
• Some of the changes have "improved" the accuracy of saturated colors, particularly red and blue, at least in terms of readability guidelines.

APCA is not specifically addressing the Helmholtz–Kohlrausch effect, as the focus for APCA is on readability, and chroma contrast does not help readability (in some cases it hinders it) — luminance contrast is the key for readability. I do have a separate color module, but not releasing it at the moment as it is more about aesthetics, not readability, and solving the readability issue was the key goal, which I believe is achieved.

Comments welcome of course. The GitHub repo is https://github.com/Myndex/SAPC-APCA

Thank you!

Andy

Andrew Somers W3 Invited Expert Myndex Color Science Researcher Inventor of SAPC and APCA

[aaronadamsCA]

This looks like it could be a real improvement when generating the best accessible tones. I'd love to be able to ask Leonardo for APCA 15, 30, 45, 60, 75, 90 colors.