4 ms·

> We used it internally here at Figma for our own accessibility revamp for a final result that ended up much better than it would have otherwise. Can you go in

> We used it internally here at Figma for our own accessibility revamp for a final result that ended up much better than it would have otherwise. Can you go into more detail here? Do you mean you use only APCA and ignore what the WCAG 2 color contrast algorithm flags as insufficient contrast?

jjcm 3y ago
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 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.webp 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.
- seanwilson 3y ago
  Thanks! > 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.
  - jjcm 3y ago
    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.

jjcm 3y ago

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

seanwilson 3y ago
Thanks! > 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.
- jjcm 3y ago
  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.