Bridge PCA gives different results than APCA checker?

[rdoyle720]

Noticed that the default values in the two tools give the same result but when I start plugging in other colors they vary.

Foreground: #ffffff
Background: #b40041
APCA: -86.6
Bridge PCA: -83.9

Intentional?

[rdoyle720]

@Myndex

[Myndex]

Hi @rdoyle720

Sorry for the delay in reply.

Yes, intentional. When one color is white or very light, especially in reverse or dark mode, the output results are adjusted slightly. This is done only for light color pairs, to provide backwards compatibility with WCAG 2.x

History

WCAG 2.x contrast math is not perceptually uniform, and it isn’t even close. 1.4.3 and 1.4.11 use a contrived formula that is nothing more than a variant of Weber, with a small offset added (of limited utility).

The “WronCAG” math fails in two ways. Various independent studies show that 47% of the colors it passes are of sufficiently low contrast those color pairs should be rejected. This affects mostly dark color pairs, and especially if one of the colors is black (WCAG 2 overstates dark contrast with an error up to 250%).

Meanwhile, WCAG 2.x also incorrectly rejects bright and saturated color pairs, and does so in a way that’s harmful to readability for people with color vision deficiency. It incorrectly rejects 23% of colors.

Because APCA corrects these problems, it is by definition not “backwards compatible” in the way that WCAG 2.x claims it must be.¹

Bridging the Gap

BridgePCA is designed to be backwards compatible, and to correct the more serious failings of WCAG 2.x. It does this by artificially forcing more contrast than needed into certain light color pairs.

The benefit is backwards compatibility (which arguably is neither valid nor useful, but that is a separate discussion).² What is lost is the added flexibility from the complete design system guidelines such as ARC.

Coming Soon

We are soon to release a new simplified BridgePCA, which is not sensitive to contrast polarity, i.e. like WCAG 2.x it won’t give different results for light text on a dark background. It will effectively be a drop in replacement for the faulty WCAG 2.x math.

And again, with simplicity and backwards compatibility, what is lost is accuracy and flexibility of the more complete system.

Thank you for reading.

———

Footnote
¹ Backwards compatible, as far as WCAG 2 is concerned, means that if you pass a future version, you automatically pass the previous version. However, there’s no protection regarding future versions and breaking existing sites. I.e. you could fully pass a previous version, yet fail a current or future version. This means that incremental versions do in fact break “passing” websites. As you can see the alleged backward compatibility mandate is a misnomer with no functional benefit. (Not to mention that the working group violated this with the removal of an SC for version 2.2).

² The genesis of BridgePCA was driven by the obstructionists, who like to squawk about “following WCAG by the numbers because law tho”, creating unwarranted concerns over backwards compatibility. This despite the fact that certain WCAG 2 SCs are harmful to visual accessibility and especially color vision deficiency. Not to mention the more appropriate legal standard is actual accessibility—a goal the very low-bar of WCAG 2 fails to reach.
The failings of WCAG are from ill-conceived SCs that are neither peer reviewed nor grounded in the relevant science of visual readability.