Bridge-PCA much stricter than WCAG?

[front-endian]

Howdy,

As mentioned in the other discussion topic I just started, thank you for all the work you are doing. Really looking forward to have a stable/accepted contrast measurement that better matches human perception.

I have started incorporating SAPC/APCA into the accessibility review work I do, and while it is very helpful to have something that might be less failure prone than WCAG, it seems like the base requirements are much stricter than WCAG. In many designs it is hard, if not impossible, to meet the "WCAG AA equivalent" requirements without some pretty washed out colors. These make the applications worse for most users as color differentiation is an important part of making elements/states easy to distinguish at a glance.

Here we have the color #72C0FC against black:

BCPA gives this a contrast ratio of Lc 64.6, which seems to be consistent with the apparent contrast of other color combinations that measure similarly. (Finally! A contrast measurement that is consistent with perception!) Unless I am missing something—and please let me know if I am—these appear to be reasonably contrasty colors, and at reasonable sizes are readable. Maybe not the best for a large body of small text, but for good for medium to large buttons/links.

BCPA gives a WCAG equivalent of 3.4:1. The WCAG contrast ratio for these colors is 10.7:1. While I can understand that there will be (and should be) some differences, this discrepancy seems pretty wide. This is a bright and desaturated color that appears to be pretty good.

To get the same contrast ratio using grey text and the original WCAG calculation requires #616161 which is significantly darker visually:

Using color blindness simulators seems to confirm the wide discrepancy:

What amount of color contrast is considered "acceptable" and "equivalent" is obviously a judgement call for the standards writers, but the WCAG equivalents in SAPC/APCA/BPCA seem excessively strict when compared to what has been considered acceptable for greyscale values in WCAG. Maybe these stricter requirements make sense for places like blog posts or news articles where people are reading large, contiguous blocks of text, but many applications and websites only have small amounts of text per element, often one or two words.

Happy to share more examples and discuss the use cases we are running into. I don't want any of this to come off as idle complaining. All this feedback comes from honest efforts to incorporate these measurements into production application work, and we'd love to work with y'all.

[Myndex]

Hi Colin @JustColin

As mentioned in the other discussion topic I just started, thank you for all the work you are doing. Really looking forward to have a stable/accepted contrast measurement that better matches human perception.

Thank you for your support, and thank you for these comments, they are invaluable.

And oh boy this is a big one...

I have started incorporating SAPC/APCA into the accessibility review work I do, and while it is very helpful to have something that might be less failure prone than WCAG, it seems like the base requirements are much stricter than WCAG. In many designs it is hard, if not impossible, to meet the "WCAG AA equivalent".....

First off, you are the first to comment on Bridge PCA specifically, so thank you — I was looking for some feedback on some of these issues to guide how certain things get shifted around.

Yes, BridgePCS is stricter, because it is not only fixing the problems WCAG 2 has in false passing colors that should be rejected, a key design goal is being backwards compatible with WCAG 2. And how do you take something that is correct and align it with something that is incorrect? 😳 In this case it means jacking up all the APCA values by approximately Lc 15 when one of the colors is lighter than #d8d8d8 then WCAG 2 understates the contrast, but in the documentation for BPCA there is this tidbit:

If the lightest color is darker than the equivalent of #d8d8d8, the minimum Lc value can be reduced by Lc 10, but lowered to no lower Lc 45. Does not apply to thin fonts.

But I have not built that into the "WCAG AA equivalent" ratio display. Until I do revise it, you may want to follow the description in the docs for the three Lc levels 60, 75, and 90, that relate to 3:1, 4.5:1, and 7:1 for backwards compatibility with WCAG 2.

Here we have the color #72C0FC against black:

BCPA gives a WCAG equivalent of 3.4:1. The WCAG contrast ratio for these colors is 10.7:1. While I can understand that there will be (and should be) some differences, this discrepancy seems pretty wide.

Yep. And the reason: WCAG 2 contrast math is really that bad most especially when one of the colors is black. In this example, the 10.7 should be probably more like 4.2 ish.

So, when WCAG 2 contrast has one of the colors as white, it underrates contrast a bit. But when one of the colors is black, the opposite occurs, and it is a massive opposite that over rates contrast by two to three times the expected value.

I've written multiple gists and also articles on this issue.

And here's a chart comparing WCAG 2 to a host of other, classical contrast maths. Dark colors toward the left. WCAG 2 is the fat red line with the crazy arc up. Perceptually uniform is a flat horizontal line for this chart.

And here is a visual example, wherein WCAG 2 says both of these panels are 4.5:1.

BCPA gives this a contrast ratio of Lc 64.6, which seems to be consistent with the apparent contrast of other color combinations that measure similarly....

APCA gives the same value, and indicates a 22px font is needed. This means it is "close" to WCAG 3:1, which requires a 24px font.

This is a bright and desaturated color that appears to be pretty good.
To get the same contrast ratio using grey text and the original WCAG calculation requires #616161 which is significantly darker visually:

Okay here's a good place to stop... If you try to compare WCAG 2 math to APCA like this, all you'll find is a new level of frustration. LOL. WCAG 2 only works when both of the following are true:

1. At least one color is lighter than #bbb AND
2. The text is darker than the background.

Under all other conditions, the results degenerate as demonstrated.

Color Vision

Using color blindness simulators seems to confirm the wide discrepancy:

Unfortunately most of the monochromacy sims don't simulate monochromacy, but just desaturate the image. The sim shown below is available at https://www.myndex.com/CVD/ and the blue cone monochromacy sim is based on the Brettel model that I'm using for the other types. One thing I have not added is that BCM also has low vision, but I did process that here a bit:

Now it's worth noting that all the common color vision deficiency—deutan, protan, tritan— have otherwise normal vision and normal contrast sensitivity, the one exception here that protanopia, with no L cones, can not see deep red, and loses whatever small amount of luminance would have come from red.

The main thing this informs us is that pure reds, oranges, and purples should never be used against black. The funny thing is that WCAG 2 rejects white on orange and passes black on orange, which can be an inaccessible combination for protan.

I should mention for completeness the very rare blue cone monochromat and the rod only mono, are also comorbid with low vision and photophobia. In fact rod only and BCM are the only actual "color blind" and they are very rare.

Contrast Concentrate: just add light...

What amount of color contrast is considered "acceptable" and "equivalent" is obviously a judgement call for the standards writers

Well since I am one of those writers, I will tell you that it's less of a judgement call and more of science, at least as far as my work in WCAG3 and APCA. In my answer to your other post, I linked to this discussion where I discuss the use cases and the empirical basis for the levels.

That research was from a few others, Bailey Lovie-Kitchin, Legge, etc... Lovie-Kitchin's groundbreaking work set the bar in terms of what contrast needs to be for:

• Block and columns of body text
• Other fluent text
• Spot reading text.

At the moment the focus has been on nailing body text, the most challenging. But there has been plenty of discussion on ways to handle conformance for other use cases — for instance, we relax it for a lot of things like copyright and disabled controls.

So...if you use the FONT LOOKUP TABLE in the APCA tool you'll see it's more flexible. The problem with BridgePCA is that to be backwards compatible, some things that should be relaxed a bit can't be.

but the WCAG equivalents in SAPC/APCA/BPCA seem excessively strict when compared to what has been considered acceptable for greyscale values in WCAG...

And has resulted in lots of unreadable sites…

....Maybe these stricter requirements make sense for places like blog posts or news articles where people are reading large, contiguous blocks of text, but many applications and websites only have small amounts of text per element, often one or two words.

Okay, so I must not have documented the use cases and levels well enough — because columns of text have completely different requirements under APCA.

From what it SOUNDS like, I need to relax the "ratio display" on Bridge PCA so that below #d8d8d8 it's equivalent to regular APCA... and below #d8d8d8 APCA beats WCAG as you can see in this chart — blue is what WCAG passes that APCA rejects:

It IS true for Bridge PCA,.... I do have an idea toward scaling back automatically. But it it will never — never ever — follow WCAG 2 down that dark hole to 10.7:1 type examples that are unreadable.

Happy to share more examples and discuss the use cases we are running into. I don't want any of this to come off as idle complaining. All this feedback comes from honest efforts to incorporate these measurements into production application work, and we'd love to work with y'all.

This is exactly the kind of discussion we need.

To be clear, are you only working with BridgePCA? Or are you using APCA? What is your workflow?

Thank you!

Andy

[front-endian]

Thank you for the lengthy response. I will have some follow up questions and a response to the questions you asked, it will just take a bit to write them out.

[front-endian]

This is all very helpful.

To be clear, are you only working with BridgePCA? Or are you using APCA? What is your workflow?

I've only just started to look at BridgePCA as a possible tool for us to use my org. After spending more time with it my current feeling is that BridgePCA is a very interesting way to get one combined metric, but we are probably going to use WCAG 2 and APCA separately going forward to solve the problems we deal with.

BridgePCA is a neat way to make APCA relatable for people who already think in terms of WCAG 2 ratios. However, the designers I work with don't think in terms of 3:1, 4.5:1, and 7:1. They want quick and easy ways to check, "Can I use these two colors in this part of the design I'm working on?" For that purpose there are three questions they need answered:

1. Does this pass the current legal requirements our customers have?
2. Could this fail future legal requirements? Is this likely to need a redesign down the road as requirements update?
3. Is this good for usability? (W3C guidelines are great, but it will always be possible to make a website that meets all W3C guidelines yet has terrible usability for many users.)

WCAG 2 answers the first question, APCA helps us answer the second two. Because BridgePCA is a single combined metric, it doesn't give the granularity to answer these questions individually. Splitting them up lets our designers evaluate what trade offs they want to make:

• Can we spend more time now to improve general usability and meet potential future requirements?
• Would trying to meet potential future guidelines necessitate too many changes and require a larger redesign? If so, maybe we can just meet the current legal requirements and create a task for a larger redesign later.
• What parts of our product pass legal requirements, but have poor readability? Those are areas we might want to reevaluate when working on our design systems.

By using APCA and WCAG 2 contrast measurements separately, we can create tools to automatically answer these questions for designers. They can keep their head in the creative space thinking about usability, rather than translating numbers and thinking about contrast ratios. We can incorporate these tools directly into our design system documentation and the editing tools designers use to shorten the feedback cycle even more.

If you are interested we can share the work we are doing with you as we make it, both to help you promote APCA and make it easier for people to work with in their design tooling.

Thank you again for all the information you've provided! All of these answers are making it much easier for me to digest your work and summarize it for our designers.

[Myndex]

Hi Colin @JustColin

Thank you so much for your detailed reply it really helps me to understand your needs as a user. And this all makes a lot of sense.

In reference to the chart I posted earlier, that was comparing levels without considering the font.

Well, when you think about it, at Lc 60, the minimum normal font is 24px... And that directly connects to WCAG 3:1. Here's that chart:

Here as you can see APCA does not pass any colors that WCAG does not pass. Caveat is the APCA uses a sliding scale for special frequency items like fonts, so it may be some specific cases or if you see a pass or some thing that WCAG might just barely fail. So I'm working on a way to codify that into a backwards compatible APCA that preserves as much of the flexibility as possible.

I would really like designers to have one single function so they can rely on that achieves all three of your desired goals.

Thank you again!

Andy

[Myndex]

Hey @JustColin

Bridge PCA Adjusted

I just wanted to let you know that I've updated Bridge-PCA to relax some of the strictness (to the degree possible), and is visible in the WCAG ratio calculation.

https://www.myndex.com/BPCA/

Now, you'll notice the WCAG ratio relative to Lc shifts by Lc 15 as the color pairs get darker, where it then aligns with regulat APCA.

So, the "false fail" problem of WCAG 2 is when text is white, which is why the previous Bridge-PCS ended up as so strict. But when WCAG calculate for dark colors, it results in serious false passes. The pivot point where APCA and WCAG 2 sort of equalize is when the lightest color is about #c0c0c0.

So now, the ratio diisplay starts where WCAG 3:1 = Lc 60, and then gradulally shifts to where WCAG 3:1 = Lc 45 (ish) as colors get derker, and at the point standard APCA takes over (leaving WCAG 2 in the dust).

The end result is the new Bridge-PCA only forces colors in the area of WCAG 2 false passes, and then returns to standard APCA when both colors are darker than #c0c0c0

Hope this helps, and please let me know of futher issues or comments.

Thank you

Andy