Sam's article comparing contrast algorithms

[sdw32]

Hi, following multiple previous threads on similar subjects, I have now written this general interest article on contrast algorithms, comparing WCAG and APCA for the specific use case of colour backgrounds with black text, and white text. The latest draft of the article is here http://www.cedc.tools/article.html.

In the second paragraph of this article, I wanted to give a short indication (for a general audience), of the significance of the scope of the WCAG contrast ratio. I wrote this text

The WCAG contrast ratio also forms the basis of Section 508 compliance, which is legally binding, and has governed billions of dollars of ICT procurement contracts (for governments and other public agencies).

But I don't actually have any evidence to back this up. @bruce-usab (or anyone else) please do you have any feedback or alternative suggestions for text for this specific paragraph, or any evidence that I can use to support this paragraph if challenged?

I had previously wanted to avoid mentioning colour impairments in the article, but given the number of places on the Internet that claim things like ‘WCAG contrast ratio ensures sufficient legibility for people with colourblindness’, I eventually came to the conclusion that such a discussion could not be avoided, and cannot be considered trivially, so I have written a fairly lengthy text on this (Footnote 2), to describe my current position on this topic, and the rationale for it.

So, I would be very grateful for any feedback on the introductory paragraphs and Footnote 2 in particular, but any other feedback on the article would also be gladly received. I'm planning on promoting this article on LinkedIn from Monday 11th April, so would be deeply grateful for any feedback before then

[mraccess77]

I'm not so sure the impact on 508 related to contract dollars is so bad- that is:

• Somethings that should fail pass (this may be a wasted opportunity but not a barrier to sell)
• Somethings that should pass fail (this requires folks go above what is needed - but any procuring organization can have requirements that go beyond what is needed). For example, gray text that is 4.6:1 can be used and I can't read it - so going beyond isn't bad for some users -- understanding that too high of contrast can be - but I don't think this is saying use 21:1 The level is still reasonable.

It is a good point though in terms of how we transition to a more accurate model - that is indeed the challenge and future regulations should perhaps allow for the newer model to be used instead. The US government isn't the only one using the contrast ratio - it's in EN 301 549 as well.

[sdw32]

@mraccess77 thanks for the feedback. For the claim in the second paragraph:

The WCAG contrast ratio also forms the basis of Section 508 compliance, which is legally binding, and has governed billions of dollars of ICT procurement contracts (for governments and other public agencies).

I wasn't intending to imply that this is good, or bad, or wasted. I'm just trying to set the scene with a statement that informs the reader that the contrast algorithm that's in WCAG is a significant thing that is worth paying attention to. I'd be very glad to receive any feedback on how I can better achieve this aim, many thanks

[Myndex]

Hi Sam, Jonathan @sdw32 @mraccess77

508

508 does cite WCAG 2, and does indicate that IT procurements should meet WCAG 2, but it should be noted that 508 has two very big exceptions:

1) Commercially available. If software needed for a task does not have a commercially available version that meets 508 standards, then the requirements are waived to the degree needed.

2) Alternate methods. If there is a method that is better for accessibility, it can be used instead of WCAG 2.

Other Legal Standards

There are aspects of WCAG 2 contrast, such as 1.4.11 that are essentially impossible to comply with in a practical manner (1.4.11 is among the worst examples, and it has no empirical support nor relevant peer reviewed cites).

THAT SAID: WCAG 2 has been codified into law in a number of nations, in most cases that law applies only to governmental sites, though in a few rare cases it's being applied to all sites (Finland), or commercial sites of companies with more than a certain number of employees, such as in Canada.

In Australia, I believe they only mandate the A level, which avoids all of the "wrong" contrast SCs.

Many nations only specify WCAG 2.0 and not 2.1, which avoids the 1.4.11 problem.

In the US, the ADA does not specify WCAG 2, but there is some case law supporting WCAG 2, all by lower courts thus far. (Dominoes was not about WCAG, but about any form of compliance). The ADA standards themselves are incredibly weak when it comes to visual accessibility, to the degree that following any actionable reasonable standard should suffice, especially if it has been shown to functionally exceed WCAG 2 — and there is a growing number of third party articles supporting APCA as a superior alternative to WCAG 2.

Thoughts on "significance"

I've been thinking there are two basic issues of significance here:

1. Companies feeling that they are forced to use a faulty contrast method under fear of lawsuit, especially places like Canada that has some case law that has companies concerned.

2. The general issue that a set of faulty SCs related to a very visible area that affects the most users, fully tarnishes the remainder of the WCAG 2 standards to the degree that credibility is reduced or lost.

The fact that 86% of the top one million websites fail the WCAG 2 contrast SCs should be sobering. The take-away here is that people do not use them. And from my outreach to designers I will tell you that WCAG 2 contrast is not used because it is much maligned and disregarded. It has no credibility. And the remainder of WCAG 2 has weakened credibility as a result.

3. Changes in how people use the web today make this now a pressing issue:

• WCAG 2 contrast can not calculate for Dark Mode (meaningless results), but dark mode is increasingly popular.
• WCAG 2 contrast is inaccurate for light text on a darker background
• WCAG 2 contrast does not follow or track human perception of suprathreshold contrast for readability, which has resulted in massive confusion, and subsequent animosity between designers and accessibility advocates.
• WCAG 2 contrast results are harmful to the readability needs of color insensitive (especially protan).

And... it is increasingly being codified into law, which has potential negative repercussions for more than just contrast.

[Myndex]

Hey Sam, @sdw32

I just read your latest draft. The comment regarding red is not completely accurate.

red text on black in -37.5, while it does indicate 28px bold, anything under Lc45 is for "spot reading only" though there no indication on the current version of the tool. This is part of the uce case guidelines.

45 • The minimum level for larger text such as headlines, and large text that should be readably fluently. "Sort of" like the old 3:1 in WCAG2.

I've also written two articles on this specific subject of red and protanopia:

What’s Red & Black & Also Not Read?

The Lighter Side of Dark Backgrounds

Unreleased Technology

I want to mention that there is some unreleased IP that more completely addresses hue and saturation related color issues, including that for red text. It is not implemented per Jeanne Spellman statements to me that I was prohibited from being innovative.

[mraccess77]

I experience sites and apps every day that I can't see due to contrast issues - and for me - almost always the contrast is either below the WCAG 2 ratios or on th the line 4.6:1-7:1.

I've also recently run through quite a bit of results on SC 2.4.11 and found that most of the focus indicator issues being flagged are indeed hard for me to see. So, for me personally (using positive video and not color limited) much of what I find aligns well with WCAG 2.

Yes, WCAG could be better and yes there are situations and groups it doesn't cover well - and we should work towards those - but there are many designers out there creating content that is not seeable because of contrast issue that fail today's WCAG 2.

[Myndex]

Hi Jonathan, @mraccess77

That has been my experience as well: 4.5:1 is often woefully inadequate for body text. At the time of adoption, the only recommendation from Dr Arditi was 7:1, and nothing less.

As a comparison, APCA fails many more colors than WCAG 2, when it comes to things like text readability.

But that's not what I am talking about—the SCs in WCAG 2 relating to contrast have generated a lot of misunderstandings and confusion.

For instance, the issue of visited and unvisited inline text links, and I discuss that in the APCA repo. open for comments. (Note: I'm not cross posting anymore as it simply becomes confusing as to what/where the discussion exist.)

WCAG 2 contrast is like "a broken clock that's right twice a day".

• People don't notice the things that are perfectly discernible, but that WCAG 2 incorrectly fails.

• People DO notice the things that are hard to see and that DO fail.

• People DO notice the things that are readable and that do pass.

• Things that are NOT readable but that pass anyway are LESS LIKELY to be noticed because a good designer is not going ot use those colors in the first place!

And herein lies the growing problem: the increased use of "dark mode" and "automated" color selections takes the designer out of the method—and the result using automated features, such as those in CSS5, are unreadable colors.

I've shown this before, and here it is again:

In this comparison of WCAG 2 and APCA, on the left, WCAG2 passes unreadable colors, yet on the right WCAG 2 fails things like the buttons which are perfectly viewable. A perceptually correct method correctly fails the left, and correctly passes that on the right.

The only case that can be made is that WCAG 2 1.4.6 provides enough contrast for text when the background is lighter than #bbbbbb

Regarding 1.4.11 (non text): the 3:1 is woefully inadequate for thin lines. And is simultaneously overkill and a design problem for solid areas larger than 8px on the smallest side.

This is because contrast is driven by spatial frequency more than color.

If a contrast standard does not consider spatial frequency as the primary driver of contrast, then you don't have a standard based in science.

WCAG 2 contrast does not have scientific support. It has a tiny area of brute-forced specification that is incorrect over the majority of the visual range, and literally works properly only when it is dark text on a very light background. This is especially true of 1.4.3 and 1.4.11.

Human issues of contrast and readability were well researched and defined by the 1990s by Legge, Bailey, Lovie-Kitchin, Barten,and many more ... and none of that research was considered in the WCAG 2 specifications, which cite only obsolete or irrelevant material, and which uses math unfit for purpose, and with no empirical support, no peer review, and nothing but a lot of confirmation bias to hold it together.

It is a broken clock that is right twice a day, and nothing more.

And I have written extensively as to how it is harmful and not helpful in the claims it makes, here's a couple recent:

What’s Red & Black & Also Not Read?

Please Stop Using Grey Text

Thank you!

A

[Myndex]

Hi Sam @sdw32

Something else regarding the "significance" aspect:

A lot has been made of WebAim's "million site4 survey" and that 84% of sites fail WCAG 2 contrast.

I've been reviewing these so called failures, and they are much more "failures of automated testing" rather than failures of site designers.

• Most that I've found are false failures due to the known issues with WCAG 2 contrast math with white text.
• There were failures because the WAVE app ascribed 4.5:1 contrast to things like non-text, and 4.5:1 even for large text.
• There ere failures claimed for things we'd say are "spot" as for use case and not content.
• There were failures for dimmed text on disabled or inactive controls.

In short, a problem with the current WCAG 2 is that is it not fit for automated testing such as this.

Amusingly one site that DID have ACTUAL contrast failures was the USDOJ.gov — the Department of Justice's site has actual contrast fails which I find ironic considering their recent announcement...

The point:

The real significance is the confusing and contradictory nature of WCAG 2 contrast specs results in people simply ignoring them wholesale. This is not good for accessibility nor is it good for the credibility of this organization and the WCAG document as a whole.

[mraccess77]

I agree many automated contrast checking tools in general have false positives despite claims that they do not. In my tests I've seen 50% of results from some tool when it comes to contrast are not correct. However, despite these challenges contrast issues are a significant issue that is among the top issues on pages even if it's placeholder text, footer text, etc.

[Myndex]

Yes, contrast is definitely a problem, and WCAG 2 contrast math misses bad pairs as well as incorrectly rejecting good pairs. No consideration for how we perceive contrast, so the specified levels are inadequate for some, more than needed for others. This leads to significant design problems, because it is literally impossible to meet requirements such as maintaining readability contrast while also maintaining "3:1" between multiple possible states, and regardless, that has no scientific support. The contrast needed for readability can not be applied as a standard for the contrast needed for state differentiation. The "references" for 1.4.11 are notwithstanding.

[Myndex]

Hi Jonathan, Sam @mraccess77 @sdw32

WCAG 2 and Automated Testing

Pursuant to the issue of automated testing using WCAG_2, and false passes and false fails, here is a real world example, using the WAVE tool in this case, all of the white text on blue call to action buttons were indicated as failing for low contrast. All of the utterly unreadable text in the body of the page was indicated as passing.

Samples from a Live Production Site

When I say results from WCAG 2 are meaningless, these examples demonstrate what I'm talking about. I applied WAVE automated testing to this page, and these examples summarize the results.

BAD FAIL

The text in this sample image FAILS WCAG 2 but reasonably should pass.

BAD PASS

The text on this example PASSES WCAG 2 but reasonably should fail

Ironically (tragically) this is the site of a medical organization that promotes inclusivity!

---

PRIMARY PROBLEM

Automated testing aside, the fact is in manual testing the same results are found if you follow WCAG 2 contrast SCs.

This is the principal problem with visual accessibility on the web today.

Some in the accessibility community have publicly stated "oh contrast is only 2% of the standard and not that important."

I completely disagree with these views. Visual contrast, especially for readability, directly affects the vast majority of users — 100% of sighted users are adversely affected by the misuse and misunderstandings surrounding contrast. And continued promotion of incorrect contrast standards is not the proactive way forward here.

Not "Better Than Nothing"

Before WCAG 2, sites were mostly grounded in black text and a light grey background. In many ways this is ideal. The emergence of WCAG_2 guidelines allowed (and possibly encouraged) designers to use light grey text. Compounded with HTML5 which requires CSS (unlike HTML4) and CDN available assets like Google Fonts,

The problem is the WCAG 2 guidelines—they are worse than nothing because they have led to greater misunderstanding and increasingly unreadable content.

[mraccess77]

Andy's examples highlight a weakness in many automated tools in that they don't test text over background images and thus the text often appears as white on white and is failed or white on black and it passes, etc.

[Myndex]

Hi Jonathan, @mraccess77

Yes, I saw that as the case on a lot of sites, however, that is not the case on on the example site shown. There is a page background regardless of if there is an image or not: Here it is without the image:

This still fails WCAG 2 contrast. According to WCAG 2, this is 3.95:1

These examples were chosen to demonstrate failures not due to some technical glitch, but failures due to fundamental flaws in the methods and maths of the WCAG 2 contrast specifications.

I know I take a lot of flack for pointing out the flaws of WCAG 2 contrast—ut I do not know how else to get across what needs to be done in a future standard.

[Myndex]

Hi Sam @sdw32

I was just reviewing your recent draft, and I have some additional comments:

Additionally, the examples in this article show that black text on coloured backgrounds becomes considerably more legible when the page background becomes black. At the time of writing in March 2022, both ‘APCA Lightness Contrast’ and ‘WCAG Contrast Ratio’ were two-colour models that do not account for the effect of the page background, which limits the accuracy of the models. Attempting to optimise a universally applicable two-colour model will necessarily involve attempting to find a compromise that is equally inaccurate for both black page backgrounds and white page backgrounds, and further research may be required to resolve this issue.

APCA does have compensation for page background, though it is estimated and "built in".

Just so you know, I do have multi-way-color versions, and this is a key part of unreleased research and unreleased IP.

I will tell you this: the way a black, grey, or white total page background affects the stimuli of interest is at times counter intuitive, but it is already considered and has some accommodation and estimation in place. For instance, you'll notice that APCA has a slight increase in contrast s colors get darker—this is to compensate for light screen/bright environments. There is a lot of nuance here though as well that I have not discussed publicly yet.

When automated checkers are used to calculate whether a particular colour combination passes or fails, this author thinks the result should be reported separately for full-colour, red-impaired and green-impaired as a minimum, and the overall result should only be a pass if all three of these values pass.

This also relates to unreleased IP that I have shown a few, but I may have mentioned that at the moment I've been restricted in terms of what can be in the WCAG 3 guidelines.

[sdw32]

Hi Andy, thanks for the follow up. regarding the colour impairments adjustment for lightness calc, regardless of any restrictions related to wcag 3, if a better solution is available then I would be glad to promote it, and supplemental guidance may have less restrictions than core guidance. Happy to talk more on this subject if you would like, thanks Sam Sent from my mobile, please excuse brevity.

…

________________________________ From: Andrew Somers ***@***.***> Sent: Sunday, April 10, 2022 4:10:22 AM To: w3c/low-vision-a11y-tf ***@***.***> Cc: Sam Waller ***@***.***>; Mention ***@***.***> Subject: Re: [w3c/low-vision-a11y-tf] Sam's article comparing contrast algorithms (Discussion #155) Hi Sam @sdw32<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsdw32&data=04%7C01%7Csdw32%40universityofcambridgecloud.onmicrosoft.com%7C06d04ad2cb0c4fb4a2f908da1a9fb9f7%7C49a50445bdfa4b79ade3547b4f3986e9%7C0%7C0%7C637851570560689761%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=570QH8AwZkEkeiwjZL1IUk64MrUYNiPxDdRxAgkOSn4%3D&reserved=0> I was just reviewing your recent draft, and I have some additional comments: Additionally, the examples in this article show that black text on coloured backgrounds becomes considerably more legible when the page background becomes black. At the time of writing in March 2022, both ‘APCA Lightness Contrast’ and ‘WCAG Contrast Ratio’ were two-colour models that do not account for the effect of the page background, which limits the accuracy of the models. Attempting to optimise a universally applicable two-colour model will necessarily involve attempting to find a compromise that is equally inaccurate for both black page backgrounds and white page backgrounds, and further research may be required to resolve this issue. APCA does have compensation for page background, though it is estimated and "built in". Just so you know, I do have multi-way-color versions, and this is a key part of unreleased research and unreleased IP. I will tell you this: the way a black, grey, or white total page background affects the stimuli of interest is at times counter intuitive, but it is already considered and has some accommodation and estimation in place. For instance, you'll notice that APCA has a slight increase in contrast s colors get darker—this is to compensate for light screen/bright environments. There is a lot of nuance here though as well that I have not discussed publicly yet. When automated checkers are used to calculate whether a particular colour combination passes or fails, this author thinks the result should be reported separately for full-colour, red-impaired and green-impaired as a minimum, and the overall result should only be a pass if all three of these values pass. This also relates to unreleased IP that I have shown a few, but I may have mentioned that at the moment I've been restricted in terms of what can be in the WCAG 3 guidelines. — Reply to this email directly, view it on GitHub<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Flow-vision-a11y-tf%2Fdiscussions%2F155%23discussioncomment-2537930&data=04%7C01%7Csdw32%40universityofcambridgecloud.onmicrosoft.com%7C06d04ad2cb0c4fb4a2f908da1a9fb9f7%7C49a50445bdfa4b79ade3547b4f3986e9%7C0%7C0%7C637851570560689761%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=q9qdGrFj0ddV%2B0q%2BuNK631XCQsORBZNpFHuyZrdKPh8%3D&reserved=0>, or unsubscribe<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAS775B64T3SPK6RCQ72BCCTVEJBB5ANCNFSM5SFSMYOA&data=04%7C01%7Csdw32%40universityofcambridgecloud.onmicrosoft.com%7C06d04ad2cb0c4fb4a2f908da1a9fb9f7%7C49a50445bdfa4b79ade3547b4f3986e9%7C0%7C0%7C637851570560689761%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hQSC0Ubq%2FLjD7689n3FtDYzCV2HREVt9afPx4ayri6U%3D&reserved=0>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[Myndex]

Hi Sam @sdw32

Let me rephrase what I am saying as I don't think it is being conveyed here.

Under Lc45, for score 4 (the highest conformance score at the moment) only non-text elements, and non-content text is permitted.

I am thinking the term "spot reading" as a term may lead to some misunderstandings. In this case this means:

• Placeholder text (in a form field)
• inactive or disabled control/form text
• copyright, trademark, byline, license, etc. notices

It literally means text that is not intended to be read, or is not considered apart of the active content.

For sRGB, full red text on Black is Lc -37.5, and black text on red is Lc 40, in both cases below the level for any content text.

My concern is that your article does not clearly identify this use case as non-content text, as it only says spot text without defining what that actually means, as I described herein. "Spot text" is not presently defined in WCAG 2, so it is an unknown or out of context term without the added definition.

---

As for the extensions to APCA such as the color module, this is part of the unreleased IP that we at one point talked about exchanging an NDA to discuss — none of the unreleased IP is part of WCAG 3.

Andy

[sdw32]

Thanks @Myndex for clarifying, I hadn't previously appreciated your intended meaning of 'spot reading' as solely referring to copyright bylines etc. I have had another go at writing the text of the article, please can you let me know your feedback on this (now DRAFT10):
https://www.cedc.tools/article.html

The updated text is also copied below:

However, pure red on pure black still gives a ‘WCAG Contrast Ratio’ of 5.3:1, which passes the recommended minimum for Level AA. Comparatively, ‘APCA Lightness Contrast’ is Lc=40 for this colour combination, which fails the recommended minimum for any website text that ought to be readable.
APCA therefore penalises red on black considerably more than WCAG. Nevertheless, both algorithms use full colour models to calculate luminance, so this author thinks that neither algorithm can be guaranteed to appropriately predict the legibility for those with colour impairments.
This author would be glad to see further research to consider how the multipliers within the luminance equations might be modified to better predict the legibility for those with different kinds of colour impairments. When automated checkers are used to calculate whether a particular colour combination passes or fails, this author thinks the result should be reported separately for full-colour, red-impaired and green-impaired as a minimum, and the overall result should only be a pass if all three of these values pass.

[Myndex]

Hi Sam, @sdw32

Thank you, that is a better presentation of the difference.

However, I want to advise you regarding the statement:

so this author thinks that neither algorithm can be guaranteed to appropriately predict the legibility for those with colour impairments.

Research in color vision impairments shows that those with CVD have substantially the same luminance contrast sensitivity as standard vision. The only potential significant difference in terms of readability is that for the protanopia, do to the fact that red on an sRGB monitor appears 35% to 50% darker perceptually (the absolute luminance is approximately 55% lower for sRGB for protanopia).

Only achromatic luminance contrast is important for fluent readability. The only concern therefore is how well the luminous efficiency function applies to someone with certain forms of CVD. The below information applies to sRGB monitors. Other colorspaces, especially Rec2020, have significant differences for red-insensitive.

Protan: (~1% of the population) this is red-insensitive vision, with anomalous or missing L cones. In the most severe case (missing, i.,e. protanopia) for sRGB, the red luminance is reduced by a little over half. However, even for standard vision, sRGB red is only 21% of the total luminance for an achromatic grey. In terms of an achromatic grey, the difference in total absolute luminance between standard vision and a protan is at most 10%~12%. But more importantly for readability, the difference in terms of relative luminance is what is important for a given pair of colors. This is therefore most critical for a specific color against 0 of that color. APCA deals with these issues in two ways.

First, there is a subtle increase in contrast for colors near black. The darker color increase is provided to offset issues with lighter page backgrounds and brighter environments, but also is assistive for color insensitive vision. Further, the APCA contrast guidelines consider critical contrast and contrast reserve, which are more than an order of magnitude above threshold. Contrast reserve more than covers the small luminance deficit, if the guidelines are followed properly.

Deutan: (~5% of pop) this is green-insensitive, with anomalous or missing M cones. Because L and M cones overlap substantially, there is only a small reduction in deep green contribution to absolute luminance. The relative luminance is not significantly affected, and again the contrast sensitivity is essentially the same as for standard vision.

Tritan: ( less than ~0.002% of population) BLUE is not a part of readability (other than how it interferes due to glare) and blue is insignificant to luminance contrast, so tritan's legibility is not significantly affected by the lack of S cones in terms of readability.

BCM: ( less than ~0.001% of population) BCM is co-morbid with low vision and photophobia and requires AT.

Note that these factors relate only the READABILITY, and do not apply to DISCERNIBILITY based on hue and chroma, which is a very different neurological process.

APCA is tuned to luminance contrast for readability, and luminance contrast as needed for aiding discernibility. Therefore, what is important is how the luminous efficiency function varies per CVD types, as just outlined.

SAPC/SARCAM, makes specific considerations as to hue/chroma, but as I've mentioned, will not be a part of any W3 guidelines at this time.

[Myndex]

Hi Sam, @sdw32

Going back to your initial post, regarding color insensitive vision, I've written extensively about how WCAG 2 math does not address the needs of protanopia, and in fact does literally the opposite.

READABILITY and CVD

When it comes to readability for sighted users, 100% of them need luminance contrast, and not color contrast (color meaning hue and chroma. Luminance is considered separate from color; hue/chroma are processed separately in the visual cortex, and not associated with readability, except as noted below).

There are two potential issues with color as in hue (specific wavelength(s) of light) that can interfere with readability:

1. For standard vision, and most other vision types, there are some colors that interfere with each other, such as pure red against pure blue, due to chromatic aberration. Blue is also associated with glare. Nevertheless, most of these conflicting color pairs also have insufficient luminance contrast. Example red/blue:

https://www.myndex.com/APCA/?BG=ff0000&TXT=0000ff&DEV=G4g&BUF=lvtf

2. Those with dichromatic color insensitive vision have otherwise "normal" contrast sensitivity¹, and otherwise normal visual function. Like standard vision, they simply need adequate luminance contrast for readability.

The single exception is the protan types, as they have a reduced sensitivity to "red". On sRGB, the red is actually redOrange, and protanopia sees this as a 50%-55% reduction in luminance. Nevertheless, as red itself is only a small (21%) component of luminance (for standard vision) the only place this is a significant issue with with red on black. This does become a bigger issue for UHD/Rec2020, a new wide gamut color space.

As I've mentioned, I have some unreleased IP that adjusts contrast values to better accommodate CVD, though these are not part of WCAG 3 as Jeanne Spellman informed me that "new research" was not permitted.

Note the different contrast values better represent the deficits for deutan and protan CVD types:

The basic APCA Lc values (withOUT the protan compensation) are (clockwise from top left):
Purple: -46.2, Green: -86.5, Red: -37.5, Blue: -16.2

Either way, red and blue are outside the guidelines for content text. But with the protan compensation, pure red text on black is strictly prohibitied.(under Lc 30).

Articles & References

I've written about this a lot. Here are some articles that discuss in further detail:

What’s Red & Black & Also Not Read? Looks at the red issue with comparisons and visual examples.

Orange You Wondering About Contrast? Looks at the orange issue.

The Lighter Side of Dark Backgrounds Discusses "dark mode" and red.

Reference

1. Ilhan, C., Sekeroglu, M.A., Doguizi, S. et al. Contrast sensitivity of patients with congenital color vision deficiency. Int Ophthalmol 39, 797–801 (2019). https://doi.org/10.1007/s10792-018-0881-7

[sdw32]

Thanks @Myndex for the extra detail, I'm happy that the text that I have in the article covers this issue to an extent that is reasonable for an article that is not on this particular topic!

As and when you are ready to release your ...

unreleased IP that adjusts contrast values to better accommodate CVD

I would be glad to review this and help to promote it, many thanks.

[Myndex]

The reason I bring it up Sam, is the statement "so this author thinks that neither algorithm can be guaranteed to appropriately predict the legibility for those with colour impairments." —— there is a lot of misunderstanding, particularly in the accessibility community regarding contrast sensitivity for color impaired vision. There is a mistaken belief that conflates readability (which requires achromatic luminance contrast and not color) vs discrimination, which relates to color differentiation. The cite I mentioned is one of many that present the scientific consensus that CVD has normal or better contrast sensitivity for luminance.

In practical terms, the only practical contrast sensitivity deficit that affects readability is that of the protan specific to red on black. This statement is the result of my research and investigation, but I have not published a paper on it yet, just the few non-academic articles that introduce the concept.

I want to be super clear on this because this directly relates to how people try and "justify" the use of WCAG 2.

The common sentiment is that "color vision deficient need WCAG 2 contrast for readability" when in fact WCAG 2 does the literal opposite of what color deficient (and standard vision) need for readability.

I don't want to delay your article any further, but I would like to get you two of the "protan enhanced" versions of the math if you want to play with them for a further evaluation.

That said, is your article ready for distribution? One of my articles recently went viral, so it is a pertinent topic right now, and more and more people are talking about this, and I'd like to start citing your article in my future articles...

Thank you
A

[mraccess77]

What I take out of this is that ensuring there is sufficient contrast is one way to make sure content that uses hue is available to users with CVD without relying on hue as this will ensure there is also a sufficient difference in luminance.

One common mistake I see often is people thinking that grayscale mode is a mode that makes things more accessible to people with CVD when it does not. It's really only a mode to help you understand the difference in luminance without hue to help ensure there is sufficient contrast.