Most active commenters
  • robin_reala(4)
  • seanwilson(4)
  • cb321(3)

←back to thread

856 points tontonius | 13 comments | | HN request time: 0.001s | source | bottom
Show context
rollcat ◴[] No.45011054[source]
Wherever you're working with colors and text/emblems, please also consider contrast and legibility: <https://apcacontrast.com/>
replies(1): >>45011138 #
1. robin_reala ◴[] No.45011138[source]
While the above site is great for measuring with a modern contrast algorithm (it’s the current algorithm for the yet-to-be-released WCAG 3 accessibility standards), it’s worth bearing in mind that the WCAG 2 algorithm is somewhat different, and a legal requirement in many markets / industries. You can check your colours against that with a tool like https://www.siegemedia.com/contrast-ratio, although there are many more.
replies(2): >>45011391 #>>45011915 #
2. seanwilson ◴[] No.45011391[source]
You can pick colors that pass both APCA and WCAG contrast checks though so it's not a problem to use APCA recommendations now.

I find APCA is a little stricter than WCAG for light themes, and APCA is much stricter than WCAG for dark themes, to the point where you really shouldn't use WCAG for dark themes. So most of the time APCA is giving you stricter contrast that easily pass WCAG also.

I keep seeing mentions that APCA will let you finally use e.g. white on orange, or white on vibrant blue that pass APCA but fail on WCAG, but my feeling is there's not a lot of examples like this and most of these pairings only have okay contrast anyway, not great contrast, so it's not ideal to be stuck with WCAG's false negatives but not that big of a deal.

replies(1): >>45011455 #
3. robin_reala ◴[] No.45011455[source]
If your colours have enough contrast to pass them both then of course that’s fine!

I only bring it up because I had a situation last week where the better APCA was giving results for both white-on-colour and #111-on-colour as suitable for headline copy under WCAG3, but #111-on-colour was 7.5:1 and white-on-colour was 2.5:1 under WCAG2, hence we could only use one of them legally.

replies(1): >>45011519 #
4. seanwilson ◴[] No.45011519{3}[source]
> I only bring it up because I had a situation last week where the better APCA was giving results for both white-on-colour and #111-on-colour as suitable for headline copy under WCAG3, but #111-on-colour was 7.5:1 and white-on-colour was 2.5:1 under WCAG2, hence we could only use one of them legally.

Yeah I understand, would you agree this is fairly rare when using APCA though?

I've had the opposite where the brand guide was suggesting we use a light on dark combo that passed WCAG2, yet it failed APCA, and worst of all clearly had poor contrast just by looking at it. Yet, some people will still go with it because WCAG2 gave it the okay haha.

replies(1): >>45011651 #
5. robin_reala ◴[] No.45011651{4}[source]
Rare, yes. Checking with both is definitely recommended!
replies(1): >>45011697 #
6. seanwilson ◴[] No.45011697{5}[source]
Maybe you've seen this but there's also https://github.com/Myndex/bridge-pca that does the "this color pair passes both APCA and WCAG2?" check in one pass.
replies(1): >>45012953 #
7. ximm ◴[] No.45011915[source]
Any reference to APCA has been removed from the WCAG 3 drafts in 2023 (see https://github.com/w3c/silver/commit/d5b364de1004d76caa7ddc4...).

I am not sure what the status is.

replies(1): >>45012451 #
8. robin_reala ◴[] No.45012451[source]
Oh, interesting, I’d missed that. Good info, thanks!
9. cb321 ◴[] No.45012953{6}[source]
As per discussion of this new OKLCH idea in TFA - Are we even sure we have great formulas for measuring/defining contrast in the first place? Do you agree / disagree with any of the counterexamples over at: https://github.com/tattoy-org/contrast-experiments
replies(1): >>45013160 #
10. seanwilson ◴[] No.45013160{7}[source]
I'm not following. These examples are using the WCAG2 contrast algorithm which is well known to be flawed for people interested in this stuff, especially for dark themes so there should be lots of bad examples here? APCA is supposed to improve on this (see the example graphic comparing WCAG2 and APCA): https://git.apcacontrast.com/documentation/WhyAPCA.html

> But as @c-blake has rightly pointed out, this doesn't take into account the ratio of visible background pixels to foreground pixels. For example the contrast required for a single fullstop character, ".", is goting to be diffrent from a capital, "B".

So APCA includes more guidance on font weight and font size for more contexts (e.g. headings, body text, shorter text, copyright notices), but it's still going to be an approximation for edge cases like displaying a single fullstop character. If this case is common, you'd want to increase the contrast value instead of going with the minimum passing value, so the contrast algorithms can still help you.

There's a tradeoff with having guidelines that are very accurate (e.g. a contrast algorithm that counts pixels) vs simpler to follow (e.g. recommended font weight and size). People already find WCAG2 hard to follow as it is.

replies(1): >>45014221 #
11. cb321 ◴[] No.45014221{8}[source]
I don't think you & I have much disagreement here as I like the way you write about approximations and edge cases and things involving human judgement calls and "both not either" kinds of testing. The WhyAPCA document you link to also includes language to such effect with sliding scales over regions & such. Me - I'm mostly asking questions not offering answers. That said, to correct the record..

>These examples are using the WCAG2 contrast algorithm which is well known

Only one of the 4 tables shown is the thing you say is the known-to-be-flawed WCAG2 one. Some counterxamples are listed for all 4 formulas, though, 2 of which use the CIE Lightness (which, sure, is probably different, but I believe the CIE L is what APCA is based upon - in spite of so..many..words on their doc pages they often just say "lightness").

------------------------

Another point of those 4 tables, perhaps more clear when looking at the python script, is whether "numerical ratio" vs abs(difference) is better. It seems to me that color space designers, like this OKLCH, are going after "perceptual linearity" which suggests abs(diff) is far more appropriate than a "ratio" which has "near zero" troubles (and zero & one are downright seductive numbers for perceptual lightness scales).

I certainly should learn more about it, but various "click through" APCA things I've seen seem to speak in ratio terms like "10 times the contrast" (though admittedly that only assumes some scale for contrast not that it's formulated as a ratio - it's just suggestive). So, I should probably look more into it before actually offering a critique, but it still has the feeling of "cross purposes" - using some color space axis designed for [0,1] linearity differences instead for ratios within that axis. When I tried using the WCAG2 one I was kind of stunned how sensitive everything was to what should have been a kind of "arbitrary adjustment" to handle near-zero.

I might wonder what designers of color spaces actually have to say about this ratio vs. difference issue if you know of any articles. You seem knowledgeable. The spaces seem literally designed for differences to me.

replies(1): >>45015201 #
12. ximm ◴[] No.45015201{9}[source]
There is no real difference between ratio and difference. It is just scaled with a logarithm. See https://blog.ce9e.org/posts/2022-09-10-contrast-algorithms/ for details.
replies(1): >>45017107 #
13. cb321 ◴[] No.45017107{10}[source]
Your link itself admits the 0.05 makes it a different formula. Both Y and L* go to zero for hard black which is a very common color (the most common for me) and would be infinite with black in there. I disagree this is all "not real".

The 2x2 table in that contrast experiments link I sent enumerates some differences along the edge cases { even with just |diff|s. }. Just empirically if you change that 0.05 to 0.02 or 0.10 things change "a lot" in terms of all the edge cases. You can try fiddling with running that Python script yourself and see.

Also, I believe the project of an actual "contrast measurement" - not merely threshold checking - is a worthy goal. I think it would be good to be able to say how bad, and for that the specific monotonic transformation absolutely matters, and again, I expect the color space designer people have opinions on this very worth listening to. I think they are targeting differences in the numbers being the most meaningful thing.

All that said, I did like your George Box quote. :-) I just don't think dismissing the problem is a great solution here. I'm not sure there is a great solution. But you & anyone are always free to find any problem uninteresting. I mean, you could also find all the color space distinctions of TFA similarly "no real difference".