Contrast improvements issues: ensure that WCAG 3 APCA is used over WCAG 2 AA/AAA contrast rule

[krassowski]

As outlined in jupyter/jupyter.github.io#587, I find some changes made in good faith aiming to improve accessibility metrics, unfortunately do not achieve intended end goal of actually improving accessibility but result in the contrary. There are a few issues with changing colours, including:

• the relative importance of elements in the layout gets changed and may create a distractive environment (this requires to rethink how the layout should look like with the new colours!)
• the number of visually distinct colours decreases because we restrict luminance bringing remaining colours closer (especially affecting partially colourblind people)
• users prone to migraine might experience more exacerbations when working in high-contrast environment

While all are important (and were discussed previously in various issues and accessibility meetings), I want to draw attention to a new problem, which I was experiencing for some time now but did not understand on technical level and could not express it clearly; it comes down to the limitations of the tools which we use when evaluating contrast.

Most tools in 2021 use the WCAG 2 algorithm which computes luminance difference ignoring most aspects of human contrast perception. WCAG 3 will include a much better algorithm called Advanced Perceptual Contrast Algorithm (APCA) which solves some of the issues.

APCA is already available in the Chrome DevTools 89 (see Color and contrast accessibility, and how to enable it) and guidelines are included in the draft of WCAG 3. A very colorful APCA contrast calculator is available on: https://www.myndex.com/SAPC/.

May I suggest that going forward any changes to colours aiming to increase contrast/accessibility will be evaluated with the use of APCA over AA/AAA rules from WCAG 2? At the minimum, could we consider both and discuss whether a change is really needed?

Ideally we would perform some user testing like an informal anonymous survey for each major change. I would not want it to be something with high burden (not even surveymonkey or google forms) - just a simple Twitter poll or equivalent.

[ellisonbg]

Thanks for bringing these issues up. I have also been looking at the new APCA guidelines. After working with some designers who have been trying to design against these new guidelines, my sense is that it is non-trivial to build applications, especially complex, themable ones, that satisfy those guidelines and are still usable and accessible in other dimensions (such as the ones you mention). My preference is that we consider the APCA guidelines, but weight them against the other design/accessibility goals.

[isabela-pf]

I agree that APCA is addressing the many complaints about WCAG 2’s color contrast calculations and that it might be good to consider it since we know it is coming in the future. I’d prefer if we could at consider both in reviewing instead of just one over the other.

I think my feelings about considering it as our main standard now are best summed up by this blog post WCAG 2 is what we have, where they argue to stick with current standards until the new ones are out of draft mode.

• I do expect we’ll have to make changes in the future if we stick with WCAG 2 now, but I also think I prefer making that transition when the system is fully tested and adopted.
• We have a lot of work to do with Jupyter projects’ accessibility already, and I’m not sure if it’s the best use of our time to have to keep up with a standard that is still explicitly in flux.

However, I am open to being persuaded, especially if we have multiple people who are okay with/interested in keeping up to date with draft guidelines.

I do also agree that there’s really not a single, perfect case where everyone will be happy with every change (which is kind of how color contrast calculations can feel since they end with a binary pass/fail). Would you find it helpful if we focus on having the ability to edit colors/themes where possible before proposing more singular changes on behalf of any color contrast calculation?

As for testing/feedback, my understanding was that opening issues and PRs (both of which hold no actual guarantee of being fulfilled and/or merged) was the process for getting feedback on these changes in Jupyter projects. This could be a misunderstanding, or it could be a process that isn’t serving to reach the right people well. I’m open to alternatives, but I’m personally not sure a poll on one platform would end in prioritizing the right people. Maybe it needs to be more cross-platform overall? I can make that happen with any proposals I make.

---

Most of all, thanks for raising this issue. We are in a kind of awkward phase of trying to leverage guidelines when there is a major update is being publicly discussed. It’ll be good if we can be on the same page in what we’re auditing and/or making changes based on.

[krassowski]

Thank you for your responses, I really appreciate this.

Would you find it helpful if we focus on having the ability to edit colors/themes where possible before proposing more singular changes on behalf of any color contrast calculation?

That would be perfect.

As for testing/feedback, my understanding was that opening issues and PRs (both of which hold no actual guarantee of being fulfilled and/or merged) was the process for getting feedback on these changes in Jupyter projects. This could be a misunderstanding, or it could be a process that isn’t serving to reach the right people well. I’m open to alternatives, but I’m personally not sure a poll on one platform would end in prioritizing the right people. Maybe it needs to be more cross-platform overall? I can make that happen with any proposals I make.

I see your point. In an ideal world we would be able to create a survey which would prioritise getting answers from right people (!= subset of core developers who happened to be available for review) and properly evaluate the UI/UX decisions we make. I feel that we are making a lot of UI changes based purely on gut feeling and do not evaluate later.

For JupyterLab/Notebook I would love to see (/help coordinate) a regular survey sent on the mailing list "help us test our latest beta" with instructions on how to update and short questionnaire to gather feedback on UI changes (since previous stable version). Was there ever discussion about this?

[isabela-pf]

I feel that we are making a lot of UI changes based purely on gut feeling and do not evaluate later.

I generally have to agree with this. It's hard to keep up with and be aware of justification for everything merged (whether or not it's there in the first place).

For JupyterLab/Notebook I would love to see (/help coordinate) a regular survey sent on the mailing list "help us test our latest beta" with instructions on how to update and short questionnaire to gather feedback on UI changes (since previous stable version). Was there ever discussion about this?

Not that I'm aware of. I do think this is feasible, though. I am happy to put it on my list to make a template email and questionnaire so this is easy to repeat periodically. It might need to be posted on a few places to get a good sample, though. I'm thinking the google groups mailing list and Jupyter Discourse at the very least.

The thing I'd need help with would be the update instructions/verifying any of the technical information is correct before sending. I think this could be quick to review in a meeting once it everything gets set up on a regular basis.

[ellisonbg]

@isabela-pf Thanks for sharing the link to the article on WCAG 2. I think I mostly agree with that idea and your comments on it. In addition, there is a legal dimension of this because of laws such as Section 508 (the US law that governs accessibility and which many institutions are subject to). Section 508 currently refers to WCAG 2.0, but other jurisdictions have moved to WCAG 2.1 or have language about the "latest WCAG version." (such as CA). Because Jupyter is used extensively in educational and research institutions that are subject to these laws, I think it makes sense for us to track the latest official version of the WCAG standard.

I think this is important enough that it should be written into the (yet to be written) charter of the accessibility working group that would eventually be approved by the Jupyter governing body (see jupyter/governance#121 for a description of working groups in the new governance model).

[Myndex]

Hi @krassowski @isabela-pf @ellisonbg

This year marks the third anniversary of the research and development project that underlies APCA (and it is significantly more extensive than just the APCA tool). I wanted to drop a note as to status, and resources.

Quick Status Update

The Basic APCA math/algorithm is stable, and has not changed in over a year. This base algorithm is probably not going to change, however, there are more advanced versions that are separate and may be introduced due to the development of new display technologies, but that is not relevant to the Basic sRGB version that is donated to the W3C for use in guidelines.

I just published APCA W3 0.1.2, which includes some key new features, such as an integrated dynamic font lookup table that automatically indicate the appropriate font/weight, alpha blending, displayP3 support, and a "reverseAPCA" where you can specify a contrast value, and either the bg or text color, and it generates the missing color.

It is on npm, npm i apca-w3

It has one dependency, which I've also placed on npm: npm i colorparsley

Also, Bridge-PCA is a drop-in replacement for WCAG 2's math. See that tool at https://www.myndex.com/BPCA/

Bridge-PCA is backwards compatible with WCAG 2, meaning it meets or exceeds WCAG 2 for compliance purposes, (including the areas where WCAG 2 rejects colors incorrectly). That said, Bridge-PCA is less flexible than the basic APCA guidelines.

APCA guidelines are compliant with ADA. Separately, the 508 rule does have an exception for alternative methods of compliance, as well as an exception regarding commercial availability.

Please let me know of any questions. The main repo discussion area is open with active discussions on APCA and related technologies: https://github.com/Myndex/SAPC-APCA/discussions

Thank you!

Andy