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.
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.
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
> 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.