Functionality "lost" in SAPC/APCA #57
Replies: 5 comments 9 replies
-
|
#38 May be helpful |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
Hi Colin! @JustColin Thank you for two great questions, sorry it's taken a bit for me to respond, for some reason GitHub did not notify me.
Yes, so the input that its labeled "text" is the "stimuli" field, and the one labeled "background" is for the surrounding color area. They are only labeled text and background to keep the learning curve short. The full SAPC and SARCAM appearance models deal with much more than just a pair of colors. Here it is kept simple for guideline purposes. Basically, the "thing" you want people to notice goes in the "text" field and the stuff that surrounds it goes in the background. I discuss use cases and categories of use in this discussion post. Take a look at that and we can certainly continue with questions in this thread.
Spatial frequency is the dominant factor for small/thin elements, while the contrasts of large thick elements and areas of color are dominated by luminance contrast, which in the case of APCA is calculated as the difference of perceptual lightness/darkness. Spatial CaseWhile it's clear that the high spatial frequencies of fonts make them a special case for readability, non-text is also subject to spatial frequency effects. A principal difference is that you'll be much more likely to have very low spatial frequencies for non text elements. Consider a button, not including the text, or form fields — low spatial frequencies by which I mean larger than 4px in stroke width OR for a filled element the smallest dimension is larger than ~4px. These large elements do not need the same level of luminance contrast. Here's a preliminary table of Lc values to non-text element size:
I'm going to look at your other message, but do feel free to continue in this thread with questions. Thank you! Andy |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the lengthy response. This is all helpful information, but I'm not sure it answers the original question. As a common example, consider a very simple website with only plain text and links. There are three places where contrast matters:
The first two are what APCA seems to cover well: the contrast of objects against a background needed for someone to clearly read text or distinguish what an icon is. The third APCA doesn't seem to let us measure as well. Neither of the two colors is the thing you want to notice, nor does one surround the other. Both colors are of equally important and on seperate parts of the display. To satisfy WCAG 2 Use of Color (1.4.1) we need to use something other than color to distinguish the links from the plain text. This could be an underline, but it is also considered passing if there is a 3:1 contrast ratio between the two colors. If you follow the preferred method and add a completely non-color indicator like an underline, a good design would still have a nice color contrast between the links and the plain text to make links easier to distinguish/find. While we can try to pick good colors by eye, having an empirical way to measure this type of contrast would be extremely helpful. To rephrase the original questions:
Thanks again! |
Beta Was this translation helpful? Give feedback.
-
|
I'll add that this question came up from the following issue: We were designing a dark mode color scheme. The text and link color needed to be Lc 75 against the black background, then we assumed that because we saw Lc 60 listed as the equivalent of 3:1 for readability of text, the contrast ratio between the link text and plain text colors should be Lc 60. We discovered that there were no colors that could give us a Lc of 75 against the background for readability, and an Lc of 60 compared to one another, thus the question of which Lc should be used as a minimum for "users can tell that these two objects are different colors if they are are show on two different parts on the same page". |
Beta Was this translation helpful? Give feedback.
-
|
Hi Colin @JustColin I can't give a complete reply right now, but I wanted to mention that luminance contrast is not recommended for information coding, either — in fact as far as information coding, luminance is less functional than hue/chroma. Just FYI, I generally object to all of the 1.4.x SCs as they pertain to contrast, which is why I am doing this work. There is an unfortunate lack of science or empirical data to support most of them, and I have contrary findings as does the existing literature. There seems to have been a move to "just slap 3:1 on everything" — but while 3:1 is the classic readability contrast metric, that does not necessarily apply across the board to all stimuli types, and it is wrong to make such a blanket assumption. Luminance is what carries fine details, so high luminance contrast is needed for text for readability. But the human vision system is not necessarry good at discriminating luminance difference. The FAA limits luminance coding to 3: black grey white. When we are talking about underlines and bodytext, we have a host of issues. Is readability important? Because underlines interfere with readability. But also, when we think of information coding, we're usually meaning "north bound busses are red, east bound are blue, cross town are orange..." Inline text links are no where near that level of information coding. The only real question is how distinct is it from the non-link text? This level of distinction does not require the same level of consideration as that of multi-item information coding. Here then are some examples.
The classic blue link has a great deal of value. In this example, the blue links are Lc75, and the black text is Lc97, for about a Lc20 difference, which by the way... is 3:1 under WCAG 2. Wait WUT!?Remember how we discussed that as colors get darker WCAG2 contrast becomes less and less accurate? Well here's how we can work that into our favor. And dealing with things like 1.4.1 or 1.4.11, there are going to be times (if you have to meet WCAG 2) where it is advantageous just to use that math, because Bridge PCA is about making text readable. The other guidelines that surround APCA that make it flexible had to be tossed out, in order to facilitate backwards compatibility. Now, let's see how this plays out for color vision:
All forms of color vision deficiency can both read and distinguish the links from the surrounding text. Trying to do this by just making the text grey, even at Lc 75 vs Lc97, does not work particularly well. 1.4.1 does not say to discard color information, only to augment it. And you'll notice that the color chosen is #0050c2 - blue with a tiny hint of green. And guess what? Deutan. protan and tritan ALL see green. Wait WUT again?Deuteranopia/deuteranomalous, are missing or have problems with the M cones, sometimes called the "green" cones. But wait, if they are missing, how do they see green? Well, the reason we call them M for medium wavelength, and not "green" is that both the L cone (red) and the M cone overlap, and they both have peak response in green. (greenish/yellow for L and yellowish/green for M). The L cone overlaps the M cone almost completely, and the L cone extends down into red. So when the M cone is missing, the L cone takes up the slack to the point that deutans have essentially standard luminance contrast sensitivity. Summing upSo, we know we need luminance contrast for small, thin things like text, for readability. But we also need to understand the needs regarding discrimination, object detection, motion... those all have different requirements, and are all processed by different areas of the brain and visual cortex than lexical processing of luminance information. I hope I didn't go too far tangent, but try #0050c2 for links in text against #000 text. It meets WCAG2, and should more than meet future APCA guidelines in this narrow use case. Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
Hi @TaigaYamada
We are pretty good a recognizing luminance differences on adjacent colors. But we are terrible at judging differences in when those same colors are in different context.
See the two yellow dots, one of them is in shadow and even though they are exactly the same color on the screen, they both look very different due to the different context. Both yellow dots are It should be noted that we also have context sensitive hue and chroma, but we also have a greater capacity for recognizing and distinguishing differences in hue than we do for luminance. Unless of course we are color vision insensitive.
When you vary hue and chroma, you will essentially always be varying luminance, unless you are using a color model with orthogonal lightness. But the general guidance is to:
Eg: let's say you have a line chart, and you want to make one of the lines lighter. Instead of lowering luminance, consider making it dotted, or thinner. Thinner = lower contrast. Thicker = higher contrast.
DataViz is definitely part of our research. It's just the text issue has been the one that is most forefront because that is the one that is the current critical crisis. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you very much for the clarification! |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, this is all very helpful! Before marking it as answered, let me confirm that I am understanding the gist of your answer:
|
Beta Was this translation helpful? Give feedback.
-
|
hi Colin @JustColin
Yes.
APCA operates on luminance only, it is a derivation from the larger SAPC/SARCAM model. SAPC (full model) can definitely determine hue/chroma/saturation differences. SAPC is not part of anything currently publicly facing, and is not part of anything (at present) being donated to the W3.
Correct, context is key.
Yes, this predates computers by at least decades, old maps are often good examples with color+luminance+physical/dimensional differences—classical design rules are classical for a reason 😎… The reasonable exception is when there's interference with a higher level requirement such as readability. And this is where we get into the tender area of in-line text links as I demonstrated above. |
Beta Was this translation helpful? Give feedback.
-
|
Fantastic! Thank you for clarifying all this. |
Beta Was this translation helpful? Give feedback.
-
|
Just want to say that I was poking around for some more information on this, and the explanation you gave with the link colours was very helpful. I guess that it's kind of hard when you're stuck in the maths to just remember why colour exists in the first place; you can't really differentiate more than two or three things by contrast, but colour helps distinguish more than that. So, since not everyone sees colour the same way, the key is to design things that either a) don't need to distinguish between too many things, or b) use something other than colour to distinguish, like bolding, underlines, etc. |
Beta Was this translation helpful? Give feedback.
-
|
After looking around for a bit after posting, I think this discussion helps bring a bit of clarity to my question. If i followed correctly, the contrast between a button fill color and the background it sits on is not something APCA is trying to define nor should we try and hit those contrast levels for that particular case? |
Beta Was this translation helpful? Give feedback.
-
Howdy!
First of all, thank you for all of the work you've put into perceptual contrast measurements. We've started incorporating APCA measurements into some of our design work and have found the beta versions to be very helpful for informing design decisions. In that work we found one use case where SAPC/APCA lost a certain degree of functionality WCAG's measurement system had:
It is common to use color to show different states, whether it is button types, graphs, banner messages, etc. In these cases, the color contrast you are comparing are not foreground/background and you aren't measuring readability of text. The "contrast" you care about in these cases is how easily can a user see that one element is a different color than another. Obviously all these designs need text, icons, or other non-color elements to help users distinguish them, but good color contrast is important to ensure all users can distinguish the elements at a glance without regardless of what their color vision is like.
While generally inaccurate for representing human perception, WCAG's symmetry for foregrounds/backgrounds made it useful for these contrast measurements when it was all we had.
Thank you again for all your work!
Beta Was this translation helpful? Give feedback.
All reactions