Black text on solid colours is less accessible than the contrast checker tells you

[krassowski]

So I am struggling with this for a long time due to some changes in JupyterLab (and elsewhere) and now on this website too.

TLDR: The tools that measure color contrast are wrong (for a certain definition of wrong). Please do user testing; please use APCA from upcoming WCAG 3. Do not listen to contrast checkers blindly.

The old way of displaying white text on blue or orange seems to be working better for me, even though it technically fails in contrast checker audits. There are many articles written on it, but I would like to highlight The Myths of Color Contrast Accessibility (Myth 1: The WCAG requirements are always optimal) and especially relevant due to our brand colour Orange You Accessible? A Mini Case Study on Color Ratio:

There may not be consensus on this one, and I may be in minority of users with mild colour blindness which find the black on orange and black on blue annoying, but I just wanted to share it. I really think that the designers who worked on Jupyter colour palette did a great job and I don't feel we need to force-change the colours based solely on the tools which calculate contrast.

I do feel that using more subtle changes like adjusting text-shadow (and not just with black/white colour, but to carefully selected shade of the relevant colour), which is in WCAG guidelines but unfortunately is not properly accounted for by Lighthouse and friends, is much better way. I do hope that this will change, Lighthouse is investigating using Advanced Perceptual Contrast Algorithm (APCA) which is now available in developer version of DevTools over old AA/AAA guidelines but it is not clear if it will solve all the issues.

APCA will be included in WCAG 3 according to this tweet by Dan Hollick and beautifully it highlights that the "white on orange" is fine (even though it was failing in the old simple algorithm):

The tweet highlights the that the orange button issue is really a failure of WCAG 2 and links to Why the New Contrast Method APCA a document from WCAG 3 contrast author who clearly highlights the issues with WCAG 2 colour recommendations calling it:

the single "most wrong" part of WCAG 2.x

which really well expresses my feeling about it

CC @isabela-pf

[krassowski]

In particular:

• I think that the old white on grey footer was better than the new black on orange footer as introduced in Simplified footer and made its background orange #546; I fully agree with @choldgraf's review - footer is not a primary element and it should use a dimmed colour; grey colour - whether the one we had originally or the one with better contrast introduced in #486 was really good there.
• I am not against the changes that switched to a darker orange for links (I believe it was a good idea), but I don't think that we should reconsider the colours in the brand guidelines (the contrast checker is lying to you, these colours are fine)
• I would prefer the text-shadow introduced in #486 to be more toned down; we really don't need it as strong and should not use black (it is an opinion, but please see Don’t Use Black for Shadows; my experience tells me that the readability/contrast can be actually reduced by strong black shadow but again, this does not seem to be well documented); I tried to encourage it in Accessibility fixes #435 (comment) earlier too.
• [off-topic] in JupyterLab I would like to harmonize the file browser text to always use white on selection as it was before; I am confident that it will pass APCA (even though it was failing WCAG 2 criteria)

[choldgraf]

Thanks @krassowski for sharing this perspective and these helpful links. I am no accessibility expert, and so I defer to the judgment of yourself and others when deciding what is and isn't accessible.

I agree that we ideally wouldn't follow Lighthouse blindly, and that we need more user testing, but my feeling is that we don't have the resources needed to properly do this on a regular basis. This website and the jupyter docs get very little regular attention, and I am just excited to be improving things at all. Given that most people that work on this site will have little-to-no training in accessibility, and will have very limited time to work on the theme, I think Lighthouse is quite useful as the closest thing we have to a shared goal to shoot for (obviously, if there is a better automated accessibility checker out there, I would love to explore it).

I'm not sure what specifically you're suggesting we change here. Could you clarify? Are you saying we shouldn't use Lighthouse? Or is your concern just about the specific changes in our site that need to be made? I think it will be hard to use Lighthouse but not treat its accessibility score as a "source of truth", unless there's some way to make it ignore certain kinds of rules like how noqa works with pep8 checkers

[krassowski]

Apologies that my initial post did formulate the intent clearly; please see answers below:

I think Lighthouse is quite useful as the closest thing we have to a shared goal to shoot for

I agree.

I'm not sure what specifically you're suggesting we change here. Could you clarify?

I highlighted some action points in #587 (comment), but those are not urgent; it is more of a PSA, "please be aware of this before changing colours blindly" rather than "please change it because its bad"; also see the proposal in jupyter/accessibility#65.

Are you saying we shouldn't use Lighthouse?

No, I have nothing against the tool. It has its limitation in that it still relies on the suboptimal contrast checks, but other than that I think it's brilliant

I think it will be hard to use Lighthouse but not treat its accessibility score as a "source of truth", unless there's some way to make it ignore certain kinds of rules like how noqa works with pep8 checkers

Yes, there is. I already added one (our canonical URL differs from the local URL when testing - by definition):

jupyter.github.io/.github/workflows/lighthouserc.json

Lines 8 to 10 in 9956b8c

	"settings": {
	"skipAudits": ["canonical"]
	}

Tools are good when used properly; maximizing metrics blindly works only as well as the metrics, so I am trying to highlight a metric which is flawed (and simultaneously provide a better metric which is APCA).

[choldgraf]

Is there a way to add APCA as a metric as part of our CI/CD infrastructure and disable the Lighthouse check for contrast? I think we'll need something that can be automatically tested for regressions.

[choldgraf]

Ah it looks like Lighthouse in Chrome already has experimental support for ACPA:

https://developer.chrome.com/blog/new-in-devtools-89/#apca

I suspect this means that we'll be able to use it soon in our CI/CD as well?

[krassowski]

I suspect this means that we'll be able to use it soon in our CI/CD as well?

That's the hope, but strictly speaking, Lighthouse is a separate application (from DevTools). There is no ETA given, but the relevant issues are:

• Investigate switching to CDP color-contrast check GoogleChrome/lighthouse#12720
• https://bugs.chromium.org/p/chromium/issues/detail?id=1197489

[isabela-pf]

Hey there, super late reply but I agree pure black text is not usually the ideal on screens even when it technically is higher contrast. This is one of those common design principles for any designer working on digital media, but not something I have taken the time to state here (I'm now realizing).

This issue is talking more about how the contrast is calculated being misleading, but the reason we commonly don't recommend black text is because it's rumored to cause significant eyestrain. (I will say that I went looking for proof of this and can find nothing that looks reputable, so perhaps it's not a tested statement?) A different reason, same results.

[choldgraf]

Given this discussion, can somebody suggest an action that will close this issue? Should we make the footer text white instead of black?

[isabela-pf]

I'm looking into proposing some solutions. I don't think just switching to white text will have enough contrast to be readable, let alone pass any contrast standard (WCAG 2 or 3).

[Myndex]

Hi @isabela-pf

...but the reason we commonly don't recommend black text is because it's rumored to cause significant eyestrain...

Rumored is the operative work here. That clown Anthony at "UXMovement" put up an article in 2018 that substantially misreads relevant science in a way that that I can only describe, in the nicest way, as egregious cognitive dissonance. Here's a tweet of my sarcastic snarky response to the article.

Will the real fatigue please stand up lay down...

It's not the black text, it's the high luminance background being too high relative to the eye's adaptation state. And yet you can't just lower the total screen, because then your eye simply adapts to that lower level as the new peak white.

For light mode, text is ideally black #000000. But we want to avoid excess screen luminance.

When reading on paper, it's full black ink (and has been for 1000 years) printed on a diffuse paper that reflects 80% - 85% of the ambient illumination. Newspapers are about 70%, very high quality magazines can get up to about 90%.

But when you look at #ffffff on a display, it's equivelent of 102% to potentially 120% or more. That's a lot more than the 85% of a book.

TPRE

We're working on "The Paper Reading Experience", a set of simple guidelines for light mode that allows for a body-text background that emulates the lightness of diffuse paper, and anchors the adaptation state of the eye, so the BG behind text remains about 80% to 85%.

Here's a sample screenshot from the APC-Readability Criterion

The thick white border at #ffffff is in the peripheral vision, more than 2em away from the main text, so it does not interfere with the text. The thick (>6px) white border anchors the adaptation to that as peak white. Then we set the BG to 80% to 85%. Here the background is about #eee8d8, which is about 80% relative to the thick white border.
The idea is to have a BG luminance that is 80% ~ 85% of a peak-white adapted state.

That's the simple explaination, there is obviously more nuance. Working on the explainer for this now.

But wait there's more

Text contrast is actually not about the color, it's more about the spatial, i.e. size and weight, of the element. Very thin fonts are at a lower contrast sensitivity, therefore more luminance contrast must be used to compensate.

And thin fonts can lose 30% or more contrast if -webkit-font-smoothing: is used. -font-smoothing should be left at "auto" for thin and small fonts. Only use it for fonts larger than 24px with a stroke more than 2px thick.

Dark Mode

On the related subject of white text on black:

For the APC Readability Criterion, we are evaluating a max contrast for dark mode,
$L^c\ -90$ for small text, and $L^c\ -85$ for 24px and $L^c\ -75$ for large/bolder text as in >36px.

And see the new Easy Intro to APCA