supporting APCA (Advanced Perceptual Contrast Algorithm) - WCAG 3

[carlosjeurissen]

To better determine accessibility when it comes to enough contrast, we should think about supporting APCA (Advanced Perceptual Contrast Algorithm) as specified in WCAG 3.

See:
https://twitter.com/DanHollick/status/1468958644364402702

[paulirish]

FWIW there's an implementation in Chrome DevTools: https://source.chromium.org/chromium/chromium/src/+/main:third_party/devtools-frontend/src/front_end/core/common/ColorUtils.ts

https://bugs.chromium.org/p/chromium/issues/detail?id=1121900
https://bugs.chromium.org/p/chromium/issues/detail?id=1170879

[WilcoFiers]

I very much appreciate and understand the enthusiasm for things like this, but it is really early days for WCAG 3.0. Speaking as the product owner of axe-core, I don't think APCA is anywhere near mature enough to be put into tools.

Once the W3C announces something is ready for adoption, we'll definitely pick it up. But my expectation is that we are years away from this for APCA. Implementing standards before they are ready is a problem. It sets the expectation that things are more stable than they really are. I think it's more likely than not that APCA in its current format will not make it into the final version of WCAG 3. It can see significant changes, or it may not get adopted at all.

From a practical perspective, my understanding is that the license of APCA wouldn't allow it to be used in axe-core. I'm not sure if Google looked at that when they pulled it into Chrome. I did hear that W3C lawyers had gotten involved. As far as I've heard that conversation is still ongoing.

I'm going to close this issue. Your enthusiasm is appreciated, but please be patient. Lets get WCAG 2.2 done and into axe-core. We'll see about WCAG 3.0 after.

[Myndex]

Hi @WilcoFiers I'd like to address some things here if it's okay:

I very much appreciate and understand the enthusiasm for things like this, but it is really early days for WCAG 3.0. Speaking as the product owner of axe-core, I don't think APCA is anywhere near mature enough to be put into tools.

APCA W3 may not be, however, last month we released Bridge-PCA, which is backwards compatible with WCAG 2, but using APCA technology. As it is backwards compatible, if you pass Bridge-PCS you automatically pass WCAG 2, but the result is substantially improved contrast for readability.

npm i bridge-pca

From a practical perspective, my understanding is that the license of APCA wouldn't allow it to be used in axe-core. I'm not sure if Google looked at that when they pulled it into Chrome. I did hear that W3C lawyers had gotten involved. As far as I've heard that conversation is still ongoing.

This is the first I've heard of this one. And not true. The APCA W3, the one developed FOR use in WCAG 3 is being donated to the W3 per their collaborative agreement for use in accessibility guidelines.

Similarly, Bridge-PCA is open source, at the moment it is under the AGPL3 public license.

There may be confusion regarding the MAIN project, SARCAM (formerly SAPC) which has a limited term license, only because it is beta and there needs to be an avenue to recall obsolete code, which is not possible with a public license. This is in response to a chunk of alpha code that became part of a public facing link. There is a disclaimer and restriction from using the technology in clinical, medical, transportation, and aerospace or other human safety applications due to liabilities.

BUT the APCA W3 version is in a stable package now on npm, and the license in that repo stipualted the W3 collaborative license.

The npm package is npm i apca-w3

Thank you,

Andy

[WilcoFiers]

Thanks for the update Andy!

[tsmd]

Why don't you reopen the issue?

[meduzen]

Any reason why it wouldn’t it be a good fit for an experimental rule?

[WilcoFiers]

The experimental tag isn't there for early-adoption of new standards. It was created to let us roll out rules that require more real-world testing before we're confident we can support them without false positives.

On APCA itself, it is no longer part of the WCAG 3 Editor's Draft. This likely means it will not be in the next public working draft of WCAG 3 either.

[Myndex]

Hi Wilco @WilcoFiers

On APCA itself, it is no longer part of the WCAG 3 Editor's.

This is only because of the change in conformance model, and the need to remove the old version/tables which no longer aligned with the current APCA, as they were over two years old.

This likely means it will not be in the next public working draft of WCAG 3 either.

It does not mean that Wilco. The next public working draft is a ways off, and there's already a mature APCA model and guidelines, requiring only minimal work to align with the new conformance model.

The APCA Readability Criterion includes the bronze simple version which is easy to automate as it is just a few simple levels, similar to WCAG2, however APCA is using perceptually uniform math.

Thank you for reading.

[dylanb]

@WilcoFiers I suggest we take a todo to work on a policy for how we will handle the development of WCAG 3 rules within the context of axe-core - thoughts?

[giamir]

At Stack Overflow we have recently concluded an initiative to make our colors more accessible. Our design team decided to use APCA to redefine our palette and we have developed a small experimental package containing axe rules for APCA to help our engineers check for color contrast in their UIs and their tests.

apca-check

I think this package could help (or inspire) people landing on this thread as we wait for WCAG3 standards to solidify over time.

[Myndex]

Hi @giamir and @dylanb

While I continue to work on WCAG 2 and 3 as an invited expert, you might be interested to know about the other developing standards, such as Inclusive Reading Technologies, Inc. a California Non Profit. At IRT, the independent APC-RC is in early draft.

@giamir
That axe-apca test suite is cool — are you using the Silver level from the draft APC-RC? I am very curious in any feedback per how all of it is working for you, any issues, questions, etc, probably not here but at the APCA forum ... are you and Stack interested in being a beta site? In addition to the public beta, we have some private stock items we'd like to test before they join the public beta...

As for other accessibility companies that are adopting: Stark has added an APCA option, and they have a cool toolset, Equivalent is using APCA... Evil Martians have a couple new tools, at this point I'm having hard time keeping up on the tools list.

[dylanb]

StackExchange/apca-check#8

[giamir]

@Myndex thanks for your comment and your work on APCA.

are you using the Silver level from the draft APC-RC?

Yes, you can check the source code for details. Specifically the table in this page.

I am very curious in any feedback per how all of it is working for you, any issues, questions, etc

In my opinion one of the main issues we found was to fully comply with the bronze conformance levels (which requires Lc75 for body text). This is one of the reasons why the package we created accept also "custom thresholds" (see here) and we started by aiming to achieve Lc60 (see our design system docs). I am happy to pass on the APCA forum link to my colleagues in case they are interested to join the conversation and share their feedback.

are you and Stack interested in being a beta site?

I cannot comment on this. I will mention it to my leadership though. Thanks

[Myndex]

Hi @giamir

Just FYI, I took the liberty of starting a new thread with a copy of your message, and I'll respond in detail there...

[vincerubinetti]

I'm going to try out the StackOverflow people's package mentioned above:
https://www.npmjs.com/package/apca-check

Also while I'm commenting, here are references I've gathered discussing the inaccuracy of current color contrast calculation methods:

• Contrast Ratio Math and Related Visual Issues w3c/wcag3#192
• https://uxmovement.com/buttons/the-myths-of-color-contrast-accessibility/
• https://github.com/Myndex/SAPC-APCA
• https://twitter.com/AlPackah/status/1773375760125857949
• https://twitter.com/DanHollick/status/1417895151003865090
• https://twitter.com/DanHollick/status/1468958644364402702
• https://twitter.com/argyleink/status/1329091518032867328

Due to these things, I have to turn off color contrast checking in my Axe tests, and I really wish I didn't have to do that.

---

Edit: I've had a ton of trouble integrating that apca-check package into my Playwright tests due to serialization issues: StackExchange/apca-check#143 I've basically spent so much time and exhausted so many options that I'm giving up. It's infeasible, if not impossible. Thus, it would be really great if this were built-in to axe-core. Or perhaps a plugin? Does Axe have plugins like that?

I get your hesitancy to not implement things before they're standardized, but I really think this case is an exception. Purism has no place in programming (or anything really). The current color contrast calculations are so obviously inadequate, and even if APCA is not perfect, it's clearly better. But possibly the most important part: it's better for user accessibility. That is the spirit and motivation of this whole library, right? As it stands, injecting one of these APCA libraries is a no-go, and the current color-contrast rule is so bad that many people will turn it off. Is that what you want?