Closed darekkay closed 9 months ago
We don't use WCAG 2.0 contrast ratios and don't recommend anyone to rely on that unless required in their situation by a certain regulation.
Radix Colors are designed using a more modern APCA algorithm that accurately predicts how human vision perceives text contrast. In comparison, WCAG 2.0 contrast ratios have a lot of problematic areas—they are not good at predicting the contrast of yellow and orange hues, don't recognise that light text on dark background and dark text on light background are perceived differently, and it tries to make the idea of an "accessible color combination" a bit binary with the AA/AAA grades, which is way more elastic in the real world.
If this is the first time you are hearing about this, here's a good reference (bear with that prose): https://gist.github.com/Myndex/069a4079b0de2930e72d5401bde9af98 https://gist.github.com/Myndex/c30dba273aa5eca426ad9f5200917c9d
A quick Google search for APCA vs WCAG 2 will find you more info.
As for the actual contrast ratios, on the website, every step has an APCA Lc contrast ratio documented, and ~Lc 70 is a very reasonable value for non-body text:
Also, keep in mind that step 11 is not designed for body text, it's designed for short spot-readable text, like buttons, headings, and individual interactive elements.
Thank you for the explanation. That's fair, and I indeed want to include APCA in my tool as well someday. Favoring users over specifications with problematic edge cases is a good thing. However, I would suggest to put your explanation as a short disclaimer/footnote on your homepage, to make sure that everyone is aware that the color palette is not WCAG (2) compliant. WCAG is not without faults, but it is often the legally-binding definition of "accessible". When a framework / library claims to be accessible, WCAG is what accessibility consultants and testers will use to verify the claim.
When a framework / library claims to be accessible, WCAG is what accessibility consultants and testers will use to verify the claim.
Oh we are aware, as some people already came to us with this construct of the WCAG compliance having a monopoly on the idea of accessibility. That's just not the status quo that we want to be a part of. As you said, “favoring users over specifications with problematic edge cases” is a great way to put it. This is with all due respect to all the good outcomes on the web that WCAG 2 enabled.
When the WCAG 2 grade is important, my usual recommendation is to not use the Radix Colors scales which are problematic with WCAG 2 (oranges, yellows, cyans, etc.). WCAG 2 and APCA overlap in blues, purples, most of the greens, so these are a safe choice if you are working in a regulated area.
However, I would suggest to put your explanation as a short disclaimer/footnote on your homepage
The homepage mentions that target contrast ratios are based on APCA. Eventually that will become the official WCAG 3 method to assess contrast anyway.
Hello, from the Radix UI homepage:
I have just published a new version of a11y-contrast and included both Radix UI palettes under examples. Because your approach is slightly different than my "magic numbers", I have temporary removed all colors apart from "backgrounds" (1 and 2) and "accessible text" (11 and 12).
I have then checked whether each background/text combination passes WCAG AA:
This returns 283 inaccessible color combinations. Maybe your statement means that only combinations within the same color family are expected to be always accessible (I would then suggest to make it more prominent in the documentation), but I have found a couple of violations here as well:
Note: The dark palette is accessible for all background/text combinations, even cross-family.