Open krassowski opened 2 years ago
In particular:
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 https://github.com/jupyter/jupyter.github.io/pull/435#issuecomment-974678311 earlier too.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
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 https://github.com/jupyter/jupyter.github.io/issues/587#issuecomment-1003175834, 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 https://github.com/jupyter/accessibility/issues/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):
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).
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.
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?
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:
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.
Given this discussion, can somebody suggest an action that will close this issue? Should we make the footer text white instead of black?
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).
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.
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.
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.
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.
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
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:
which really well expresses my feeling about it
CC @isabela-pf