We use a balance of both. All of our body text is WCAG 2 compliant - we wanted to ensure the primary usability of the app is accessible towards the current standard. Where we diverge is when combining saturated colors with desaturated colors for foregrounds/backgrounds, which WCAG has some trouble with. Some good examples of this are here: https://twitter.com/DanHollick/status/1417895151003865090
This was relevant for our Figma's brand color, as prior to our accessibility pass it wasn't compliant when combined with white text for neither WCAG 2 nor APCA. We modified it slightly to be #0D99FF, which was close enough to the original brand color it didn't feel like a rebrand, while still allowing us a passing APCA color contrasts score. Notably though it doesn't pass WCAG 2, but you'll see from this example the contrast is significant: https://image.non.io/15ed7558-5337-40fc-9e5b-2392087cc35b.we...
That's not to say though that APCA is a perfect solution. Interestingly, should APCA be adopted as the WCAG standard, Figma and Hackernews both would fail contrast guidelines. Part of APCA is a guideline for what font size/weight combinations are allowed for any color contrast level. Even with #000 and #fff as your colors, fonts under 11.5px are not allowed (Figma uses 11px for much of the UI). For many expert tools, 11px fonts are fairly standard due to the amount of UI you have to have on screen - other examples here where this is common are tools such as Blender or CAD software. Hackernews uses black 12px font for the main body text against a #f6f6ef background, which according to APCA requires a minimum 15px font at normal font weight. This is a perfect example of my earlier point that you have to use a collection of tools at the end of the day to get to a correct solution, rather than using a single tool or algorithm as a dogmatic source of truth. You can create poorly accessible solutions with WCAG and bad user experiences with APCA.
> All of our body text is WCAG 2 compliant - we wanted to ensure the primary usability of the app is accessible towards the current standard. Where we diverge is when combining saturated colors with desaturated colors for foregrounds/backgrounds, which WCAG has some trouble with.
Why not use APCA only though? Isn't it hard to keep track of where you're following WCAG 2 for some colors and APAC for others?
> Even with #000 and #fff as your colors, fonts under 11.5px are not allowed (Figma uses 11px for much of the UI). For many expert tools, 11px fonts are fairly standard due to the amount of UI you have to have on screen - other examples here where this is common are tools such as Blender or CAD software.
I've encountered this pain too. It feels like the only solution is the user configures their browser/OS to say what they find acceptable so the UI can adapt to that, rather than the default UI for everyone having to conform to the most restrictive rules.
> Hackernews uses black 12px font for the main body text against a #f6f6ef background, which according to APCA requires a minimum 15px font at normal font weight.
Do you have any tricks for conforming to APCA when you need to keep track of font weight, font size, and background vs foreground color while designing/developing UIs? There's style guides for reference, auditing tools, and potential for automation (e.g. CSS variables that pick a contrasting color for you), but curious if you had some thoughts given it can be a lot to manage.
> This was relevant for our Figma's brand color, as prior to our accessibility pass it wasn't compliant when combined with white text for neither WCAG 2 nor APCA. We modified it slightly to be #0D99FF, which was close enough to the original brand color it didn't feel like a rebrand, while still allowing us a passing APCA color contrasts score.
I'm curious how WCAG managed to miss this one during standardisation given how common blue is for a brand color. I wonder how many brands this has impacted.
Do you have any tricks for conforming to APCA when you need to keep track of font weight, font size, and background vs foreground color while designing/developing UIs?
I don't, as for us we set our goal to have a contrast of >60 regardless of font size/weight. Since we already weren't compliant with our 11px font sizes, we chose to use the contrast guidelines without the font size guidelines. Agree it's a lot to manage - we didn't find a great way to solve for this, which is why we mixed and matched WCAG, APCA, and general UX principles rather than relying on a single set of rules.
First of all thank you for these comments, I do proactively seek out comments like these as there are too few at the official APCA discussion forum https://github.com/Myndex/SAPC-APCA/discussions
That said:
A px is not a device pixel, it is referenced to the canvas abstraction layer as the canonical CSS reference px. It represents 1.278 arc minutes of visual angle as subtended onto the retina. Or 0.0213° 𝑽𝜽
This is the case with a 96ppi monitor at 28" away.
Visual Angle in arc minutes is what is used in research, and in fact what the Snellen eye chart is based around, 20/20 is based on a capital E that is 5 arc minutes high, where each line is 1 arcmin, and each space between the three horizontal lines is 1 arcmin, where we then find a spatial frequency of 30 cycles per degree.
But that is for minimum acuity .
Minimum acuity is NOT best readability, which needs to be ~2.5 or times larger than the acuity size (critical size). For a standard display a reference distance away, that means an x-height of 9.4px, which is 12 minutes of arc 𝑽𝜽.
Critical size and critical contrast are recited and empirically tested for decades by eminent readability researchers Whittacker, Lovi-Kitchin, Ian Bailey, Legge, et alia.
The font sizes for APCA are based on this, and assuming a reference font like Helvetica with a 0.52 x-height ratio.
ALSO, if you want a "catch all" contrast value,Lc 75 is more appropriate IMO.
NOT SET IN STONE YET
This kind of discussion is good at the forum, so that it can be tracked and considered in the conversations about guidelines.
ALSO
If you want an easy way to use APCA and be fully backwards compatible with the old WCAG 2.x, then try BridgePCA at https://bridgepca.com
> I don't, as for us we set our goal to have a contrast of >60 regardless of font size/weight.
That's my general strategy too e.g. I'd rather pick a single blue that always works for large and small text, rather than having to keep track of and workaround which shade to use for different sizes.
I do wonder if they'll make some compromises to APCA in this area to make it easier to apply before it's standardised, as there's much more to track now compared to WCAG.
Hi @seanwilson, standards work is nothing BUT compromises it seems.
The reason for the public beta is to find concerns like these.
One of the aspects of APCA that is unique are the many use-case levels that improve design flexibility by focusing contrast values where they are actually needed.
This was relevant for our Figma's brand color, as prior to our accessibility pass it wasn't compliant when combined with white text for neither WCAG 2 nor APCA. We modified it slightly to be #0D99FF, which was close enough to the original brand color it didn't feel like a rebrand, while still allowing us a passing APCA color contrasts score. Notably though it doesn't pass WCAG 2, but you'll see from this example the contrast is significant: https://image.non.io/15ed7558-5337-40fc-9e5b-2392087cc35b.we...
That's not to say though that APCA is a perfect solution. Interestingly, should APCA be adopted as the WCAG standard, Figma and Hackernews both would fail contrast guidelines. Part of APCA is a guideline for what font size/weight combinations are allowed for any color contrast level. Even with #000 and #fff as your colors, fonts under 11.5px are not allowed (Figma uses 11px for much of the UI). For many expert tools, 11px fonts are fairly standard due to the amount of UI you have to have on screen - other examples here where this is common are tools such as Blender or CAD software. Hackernews uses black 12px font for the main body text against a #f6f6ef background, which according to APCA requires a minimum 15px font at normal font weight. This is a perfect example of my earlier point that you have to use a collection of tools at the end of the day to get to a correct solution, rather than using a single tool or algorithm as a dogmatic source of truth. You can create poorly accessible solutions with WCAG and bad user experiences with APCA.