Lc Value vs Simple Ratio •• AND •• Bridge-PCA #42
Replies: 1 comment 3 replies
-
|
Thanks @Myndex , I will come back to this more, but four notes-to-self kinds of things. These are all just my personal opinions, and and I am not speaking for USAB or AG WG. (1) Keep in mind that a should/shall/may approach is actually counter-productive in the context of crafting 2.x SC phrasing. It is good for a11y guidance and for discussing things generally, and fits WCAG3. (2) That said, as a plug-and-play replacement for 1.4.3, this seems very promising to me:
(3) Does Lc 75 permits both white and black on a certain hues? (I think so.) Could you please write up something more about that? White and black on orange is a good example. Is there a blue? How about a green? From lack of experience, I don't have an intuitive feeling for the range of hues where Lc75 is possible for both white and black text. Your have provided many of these kinds of samples, but I would like to have a page or discussion thread just for this three-color challenge. My understanding is that Lc 75 white and black on any middle gray is not possible, so please clarify that. Not having a middle gray that supports Lc 75 (for both black and white text) is probably not a blocker to adoption. Historically, that 2.x 4.5:1 allowed for black (and white) on a middle gray was important to its early adoption and acceptance. But the contrast (for black on those middle grays) is quite apparently not great, so it is very good to have a better algorithm. WebAIM link example: white and black on gray 2.x 4.5:1 allows a very limited range where this works. Some hues are possible, but really they are fairly characterized as all being a middle gray. (4) I perceive a need to figure out how to get some real-world testing by end-users with Retinitis Pigmentosa and Lc75 reds and oranges. I have some ideas of where to start asking, and I plan to make an inquiries in 2022, but before that, I would like to have more confidence that Lc 75 is the value which should be subject to particular scrutiny. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Bruce! @bruce-usab Thank you these are excellent questions, some have led to recent refinements last couple days, others may have been answered elsewhere and I'll link... This has lead to my realization that over the last nearly three years my work is now so scattered about that it's even less coherent than ever. UGH!!! Collating and bringing everything together is a priority for 2022. In order to make my posts more readable, I'm going to try to just link to the larger explanations.
Got it. I revised into the "Drop In" and then two "enhanced" levels. The drop in is literally just "replace the math, and LcX = Y:1" as explained here.. Right after that, I listed "Bridge-PCA Enhanced" which is an AA enhanced and an AAA enhanced, which adds the "a11y guidance".
Yes and no. For instance, fully saturated blue #00f should not be used with black, nor should full red #f00 and will fail basic APCA. Full red #f00 does not fail WCAG_2, one of its downfalls. In fact WCAG_2 rates #f00 against black as 5.25:1. APCA though puts it at 37 below the cutoff for all fluent text (45). There is literally not enough available contrast in a typical sRGB display to have two high-contrasts of body text sized stimuli on top of each other with a common middle. It might be possible in HDR, but with high expected fatigue. On the https://www.myndex.com/SAPC/ site, there is "research mode" — click research mode and select the middle contrast experiment that demonstrates this. ....Andy Tangent Alert....This by the way is an important proof to how WCAG_2 does the opposite of what it is claimed to do, and in this case is harmful to protanopia. While it is true that in sRGB a protan will see the luminance of the red primary, it is 35% or more darker. This makes #f00 text on black unreadable for protanopia unless it is very large (60px ish) But WCAG_2 says 5.25:1, and for protanopia, red #f00 is fine against white, but WCAG_2 fails it at 3.99:1 WCAG_2 is backwards, literally. Here's a comparison chart from some very early studies in 2019, comparing different maths. This is sort of equivalent to the current Lc 60 — WCAG2 just flys off in the wrong direction as the colors get darker.
Compared to other common contrast maths WCAG_2 performs worst (literally flying off scale), and when comparing to the needs of CVD, WCAG_2 performs the opposite of what it needs to. I have visual examples in this article from a year ago. END TANGENT ALERTFlip For Color!
I discuss this "middle point" more in my article Let's Flip For Color But specifc to adoption and "three way" as a design issue: There is no reason it should be a blocker for adoption, because that has never been a "thing" in classical design. For body text, there is no need for the "three way"; that has never been a "design need". The "multi-way" color is more about text vs a background versus object vs background, i.e. a large button. A large button shape (ignoring text) needs much less luminance contrast than text, which is thin. This is the key importance of spatial frequency. That APCA is designed to consider spatial frequency is where the design flexibility comes in, and it is relevant to classical design rules and relevant to perception. The need for this to this to this to... etc is not (and functionally can not) be about a pair set of three colors.
So for three-way: is there ever any case wherein body text is going to be on top of other body text, that needs a third color? No, but there is a common case of background A, and sub-background B (i.e. button) and text on the button. BUT still, where is the three way? there is the need for contrast between the background and the button shape, which is low because the button is a large, thick object, and then there is the need for the text against the button. So, even here, there is no functional need for "three way". The button can easily be Lc 45, and often as low as Lc 30. The text needs to be at least Lc 60, or Lc75, and maybe Lc90. The APCA range is 105+ But the "contrast center" where there is an equal amount of contrast above and below a common "mid grey" is about Lc 54-ish. I can't change the physics of light, nor how we perceive it — I can only model the reality of light and perception.
Yes, unfortunately on the dark half it's unreadable...! While there is the "classical" middle grey of 18Y (18% grey card) that is not necessarily middle contrast, though that does happen to be where WCAG_2 puts the middle around #777. The proof and the reasons why are the subject of a paper I am working on. And it's a deeper rabbit hole that I initially expected, but I do discuss more in the Flip for Color article I linked above. In addition to the above article on Flip for Color I have a live CodePen that can be played with that demonstrates this. You'll see in the mid grey area the text gets larger to compensate. SIDE NOTE: Rather than focus on publishing papers, I've focused on presenting prima facia evidence and live examples that people can play with and see for themselves. Based on some recent controversies, I'm reducing some of these key discoveries to academic papers to address this.
Well, again, this is a downfall — it's not the "3 way" that is as important as readability, and the recognition that some objects like a button shape need much less contrast than text. Once we realize that we need to establish the needs based on spatial frequency FIRST, then use case, then color, hue, luminance, all falls into place in a way that is very useable and very readable.
I really want to gather some data here too, and the published literature on RP is weak. I definitely want RP individuals involved in the 2022 studies. As far as should Lc 75 be the focusof the five primary levels it's probably going to become the catch all. The five big-uns are 30 45 60 75 90, with 15 and 105 being the "ends" and this is for a typical sRGB display in typical indoor ambient conditions similar to the SAPC standard observer. Not Set In Stone:
What is Lc 75 ?The driving force on much of this, as indicated in a number of posts I've made in the LVTF and on the VC Wiki, is driven by the research of Bailey/Lovie-Kitchin, and also Legge, in readability. The current settings are such that every time I think it needs to be adjusted one direction or another, moving to another environment indicates adjusting the other way. In other words it represents "close to ideal compromise" while keeping the math and overall guideline simple. And still some minor voices are calling it too complicated. But in a semi-automated design system, or testing system, it is easy to implement. As such, there are multiple "levels" emerging:
All for now, Thank you! Andy |
Beta Was this translation helpful? Give feedback.
-
I cannot think of any body-text-on-body-text example. But there are plenty of examples where three colors of good mutual contrast are quite important. Any map or graph really, but in general, than requires four colors with good mutual contrast. which is not mathematically possible. One has to settle for 3:1 and use other approaches for maps. That said, having black, white, and a third color opens up lots of design choices. I think a Word Cloud is a good example where 4.5:1 should be the minimum expectation. Not body text, but text that is meant to be read easily.
I respectfully disagree with this assertion. A classic example is traditional old-school BBS style web page. In the 90s this would have meant a noticeable background color. If I have a page giving homage to tigers or Halloween, I want an an Orange field. Black text with linked text and 1em headers in White.
I agree that multi-way is |
Beta Was this translation helpful? Give feedback.
-
|
Hi Bruce @bruce-usab I think we are saying almost the same thing. I am not saying that multi-level color is not needed, what I am saying is that body text is (traditionally, if you want people to actually read it) is handled uniquely relative to any other element type. If "multi way" in involved with body text, the body text is traditionally given a cutout-area or some kind of hold-out so that high contrast can be maintained.
Yes, but map areas are not small text. Map areas are by definition, areas. Map areas are not "high spatial frequency", and are in fact large to the post of being considered low spatial frequency (except hard edges) where chroma/hue contrast is strong, and can be stronger than luminance contrast (CVD not withstanding of course). TEXT especially body text is small and thin and at a very high spatial frequency. Map areas or other areas of a color or lightness is a low spatial frequency, and the contrast sensitivity needs are completely different. I know you've seen this contrast sensitivity chart before, but for review or anyone else reading along at home: click for full size
What that chart shows is that the needs of body text vs large bold text, or areas of color can be as much as two orders of magnitude. Now, at higher contrasts that curve flattens a but due to contrast constancy. But the point is the contrast needs to text and that for areas of color like on a map are essentially unrelated. ANd then this leads into the discussion of if you need to "discern" differences, or "understand" differences.
Yes and it can if the font is large enough — again with the chart above, once things are smaller than 20 cycles per degree or so, contrast needs skyrocket. And the skyrocketing happens a bit sooner for impaired visions.
Okay, but a classic BBS is a poor example of good design.... 🤣 I remember those days lol (300 baud acoustical coupler uphill both ways!!) I can't change the laws of physics of light, and I can't change how our perception evolved. I can only report what the limitations are. Screen shot of https://codepen.io/myndex/full/RwZJyPR near middle contrast the font is enlarged...
Yes I agree, more about... but if you have a column of body text, it likely will need a hold-out area on a complex page, OR use a large enough font... map tool...BTW that's an interesting map tool, in playing with it I found 5 and 6 colors that worked and also allowed borders and roads, and were okay for CVD... but the tool does not allow individual adjustment of colors, which I found to be necessary when considering the overlays of single color roads or city names without an outline or backing. There is also a big difference if you have borders on or off. With borders off it seems you need a higher luminance contrast than the relative hue/chroma contrast... adding it to my studies to do list... Legge had a study indicating that color contrast (hue chroma) do not add to the total contrast perception, and remains a separate contrast... For readability, APCA looks at luminance only, as that is what is key for reading... Thank you! Andy |
Beta Was this translation helpful? Give feedback.
-
Hi Bruce! @bruce-usab
Let me explain briefly (well as briefly as I... um... well... okay.... let me... explain)
Bridge-PCA
First, let me introduce you to Bridge-PCA — this is a 100% backwards compatible replacement of the WCAG_2 contrast math. By 100% I mean that if you pass Bridge-PCA you automagically pass WCAG_2 (using the same fonts as WCAG_2). To emphasize:
if you pass Bridge-PCA you automatically pass WCAG_2
Weeee! But there is no free lunch. To be backwards compatible, the contrasts have to be forced higher than technically needed when using the full APCA and font lookup table. The trade offs are "easy to use" vs "most flexible for design". I can make the conformance as easy to use as WCAG2, or more functionally flexible, as what I've shown for APCA.
I explain this more completely below, now to answer your main question:
The "exceeds" vs "sort of like" thing
Sooooo.... Trying to keep this brief. How does Lc 60 relate to 4.5:1 or 3:1...
The "perceptual middle" grey has traditionally been considered 18% (18% grey card), but like all of this, the reality is more complicated. In sRGB, 18% is about #777 ... and this is also what WCAG_2 math considers middle contrast.
And while it is easy to assume that "middle grey" would also be middle contrast, well....
...nope.
Middle contrast shifts around based on a pile of the usual psychophysical factors.
On a typical monitor, and depending on spatial frequency, the perceptual middle tends to be around
#999to#AAA, as dark as ~#888and as light as ~#bbbdepending on stimulus size, ambient, etc.#a0a0a0is a good "rule of thumb" middle between black and white text, if you want a place to flip from white text to black text based on the BG. For proof of this I made a CodePen:Fancy Font Flipping
Great, so what about APCA vs WCAG2?
As we know, WCAG_2 is centered on old technology and uses a simple linear ratio that does not follow human perception. For any given contrast value, for the highest actual perceived contrast, the lightest color must be white #fff. As the lightest color gets darker, the 1.4.3 contrast math is increasingly inaccurate relative to how we see.
APCA is perceptually uniform for a given contrast value across the available range, with a very slight boost in very dark colors, there to assist with misadjusted monitors, flare, and other issues.
There are two ways to compare WCAG_2 Ratio vs APCA Lc:
What Lc value meets or exceeds the max WCAG_2 contrast for a given ratio, OR
What Lc value is functionally equivalent to a useable WCAG_2 ratio.
"Exceeds WCAG_2" This is "Bridge-PCA"
"Functionally Equivalent" This is "APCA for W3"
Lc 60 Exceeds WCAG 3:1
Lc 75 Exceeds WCAG 4.5:1
Lc 90 Exceeds WCAG 7:1
The "exceeds" set exceeds WCAG_2 over the entire range. So much so the AA set is able to relax slightly for darker colors, but still superior to 1.4.3. The AAA set is superior to 1.4.6
The Functionally Equivalent values are based on a narrow range with a center color ~ #9e9e9e (per the G-4g scaling) or luminance ~34Y to ~42Y. Outside of this very narrow range only APCA remains perceptually accurate, the old method does not. The following table demonstrates the "Functionally Equivalent" relationships.
"Engineered on Purpose" 😁
The SAPC math was engineered to put the key values at the easy to remember levels of Lc 15 30 45 60 75 90 etc.
I specifically wanted Lc 45, Lc 60, Lc 75 to line up at some point with WCAG 2.x's 3:1, 4.5:1, and 7:1 to be able to say that "Lc 60 is about like the old 4.5:1" to help in moving toward this new guideline.
Because APCA is perceptually uniform within reasonable tolerances, a change by a certain Lc amount has a similar perceptual change regardless of the present value (except of course when one of the colors is clipped at #000 or #fff). In the current scaling, increasing contrast by adding Lc 15 is approximately equivalent to the contrast change of a 400 weight font to a 700 weight font, when the font is smaller than about 32px.
The G Series exponents demonstrate that the old WCAG2 spec is completely out-of-line with perception. Darker color pairs that WCAG2 incorrectly passes will fail under APCA, and light text on dark backgrounds that WCAG incorrectly fails will correctly pass under APCA. Ultimately, APCA will provide 50%+ more colors, and do so correctly per use cases and spatial frequency.
CONFORMANCE INFO ON THE BRIDGE-PCA VERSION
Bridge to the Advanced Perceptual Contrast Algorithm
Current Version: 0.1.0 4g (w3) betafish
Bridge PCA is a contrast assessment method based on APCA & SAPC technology for predicting the perceived contrast between sRGB colors on a computer monitor. It has been developed as an assessment method to facilitate better readability while maintaining backwards compatibility with WCAG_2 contrast (1.4.3) accessibility standards relating to content for computer displays and mobile devices. The intention is to improve readability and understandability of content.
WCAG_2 Bridge-PCA Font Use
Large Font: 24px normal weight or 18.7px bold, or larger.
Thin Font: 300 weight.
AA
SHOULD
SHALL
MAY
AAA
SHOULD
SHALL
MAY
Unlike the main APCA, BridgePCA is all about "emulating" WCAG_2 contrast. So, BridgePCA is a like-for-like replacement of the quirky WCAG_2 contrast math.
Like APCA, BridgePCA reports results as Lc (Lightness Contrast), and it's super easy to convert to WCAG_2 ratios:
DIFFERENCES: for best results, send the text color to the text input of the tool. Bridge PCA is "polarity sensitive," even though WCAG_2 is not. For light text on a dark background, the result will have an R for "reverse" after the LC value. N means "normal".
No Free Lunch: while BridgePCA corrects the many false passes and improves readability, the cost is that there is reduced design flexibility due to the fact that to maintain backwards compatibility, some contrasts are forced higher than they actually need be.
BridgePCA has some minor internal adjustments to align with some of the more incorrect aspects of WCAG_2 contrast math. In order to be backwards compatible, BridgePCA will not forgive the false-fails of WCAG_2, but BridgePCA will correct the many false passes which vastly improves readability.
But if you need a standards compliant method that also improves readability this is it. If on the other hand you do not need to abide by the letter of any particular standard, you may want to consider the more flexible full APCA solution.
Thankyou
Andy
Beta Was this translation helpful? Give feedback.
All reactions