Contrast Ratio Math and Related Visual Issues #695
The W3C's specification for determining sRGB contrast as discussed in "Understanding WCAG 2.0 and 2.1, Minimum Contrast 1.4.3" is not perceptually uniform and as a result creates "contrast ratios" that are not meaningful. The end result is incorrect contrast choices for some web colors. Compounding the problem are the number of "contrast tools" based on this math all over the web, and all of which are returning invalid data.
The end result are websites that may comply with the W3C's math for contrast, but are otherwise difficult to read. The bad math coupled with contrast tools have provided designers with color schemes of poor accessibility. This needs to be addressed!
Edit May 2019: after first-round research, we've found that the issue is not so much using "simple contrast" as it is the manner (or lack of) considering ambient lighting, the nature of illuminated1 displays, and/or a lack of math that better models human non-linear perception.
Weber contrast, Michelson Contrast, Bartleson-Breneman Perceptual Contrast Length (PCL), or other possible candidates are better choices for programatic legibility assessment. I am currently conducting studies on a "best" programatic contrast assessment algorithm for UI/Web design and will update this issue as I do. I am presently leaning toward a variation of PCL as it prevents the near-black contrast expansion. Using this and applying an exponent to the luminance data looks promising.
Edit June 2019: results of research/experiments below show that a "standard" Weber contrast does not provide better performance by itself — it requires a modification for a more accurate model of a computer display).
Note1: By "illuminated" I mean both emissive (led), and transmissive backlit (LCD) display types.
Web Links to some of the pages of the document:
I prepared a webpage that demonstrates the problem here:
(Edit: the full set of experiments is at https://www.myndex.com/WEB/Perception )
Here is a reduced resolution screenshot of part of that test page.
In the above experiment, we set a number of panels to color-pairs with a contrast ratio of 4.5:1, this counts as a "PASS" for the W3C spec of minimum contrast for small text. Interspersed among these panels are color-pairs that the W3C criteria counts as a "FAIL" even for large text, with a contrast of 2.9:1
As you can see, many of the "PASS" color pairs are actually hard to read and of low contrast, while all of the "FAIL" pairs are substantially easier to read and of higher perceptual contrast.
The point here is that the "contrast ratios" created by the equations listed in the WCAG documents are not useful or meaningful for determining perceptual luminance contrast.
Part of the reason this is happening is using simple contrast (L1/L2) Simple Contrast fails to account for non linear human perception in values between #0 and #FFF. Also troubling is the use of outdated standards documents or drafts. I list these issues on the webpage:
The upshot of all this is that if "contrast ratios" are going to be promoted as a means to define color for accessible design, then there needs to be a clear path to assess contrast based on human perception.
Looking for a Solution (EDIT 4/25/19: Better solutions in later posts)
One idea is to process the luminance with an exponent (^1.6) then take 1/3rd the contrast result, using either weber contrast or perceptual contrast length.
The purpose of the exponent is to shift contrast for black/dark text vs white/light text, this adjusts for our perception that light text on a medium or darker background has a higher perceived contrast than dark text on a medium background. The purpose for taking 1/3rd of the result is to bring the output numbers into line with the W3C standard indicating a 4.5:1 contrast.
A more ideal solution would be to commission a study with human subjects of various visual impairments to fine tune a model for programatic contrast assessment.
The text was updated successfully, but these errors were encountered:
Thank you Patrick but as you can see I already posted in that thread. That is a separate and somewhat minor issue. The issue I discuss in THIS thread is specifically about the minimum contrast 1.4.3, and is not minor as it has far-reaching consequences such as a ton of apps that now incorrectly present colors as "accessible" when in fact they are not. And this issue has led to a great deal of misunderstanding regarding color choices and contrast.
The thread you linked to deals with a minor error in the relative luminance equation, and while the W3C picked the wrong equation that is not what is causing the much more serious problem that I outline in this separate issue.
The issue HERE is using a simple contrast (L1/L2) on linear luminance to define color & luminance contrast. But this does not provide any meaningful value for perceived contrast.
I posted this as an issue for discussion while I continue my research (search for an accurate programatic contrast assessment) and pull request separately.
Some additional thoughts regarding 1.4.3
FWIW MY BACKGROUND: I work in the film and television industry in Hollywood as an editor/colorist/VFX & Title Supervisor. I work with color and visual perception issues every day.
I am going to continue to post in this thread while I delve further into this before generating a pull request. It is a concern for me because this W3C document is considered authoritative, and has made its way into government regulations. It is important that it be correct, and it is not at present. PLEASE COMMENT if you have thoughts or insights as to why some of these choices were made. Thank you.
Simple contrast "is not useful for real-world luminances, because of their much higher dynamic range and the logarithmic response characteristics of the human eye."
and using simple contrast seems to have led to the higher (4.5:1) contrast specifications:
What is the cite and specific justification for the claimed need for a 4.5:1 contrast ratio? Studies by Legge, Rubin, Bangor etc. found that "Contrast by itself had no significance for either vision group." [unimpaired or impaired] 
However font size and polarity are very important, and contrast does interact with very small font sizes to a degree, especially in negative polarity. The Bangor study indicated that font sizes below 18 px resulted in a need for increased contrast, but these study participants were ether legally blind (20/200) or very impaired (20/100).
It is NOT about contrast as much as size and possibly polarity. While it is true that increasing contrast can help legibility for small fonts for visually impaired, increasing the font size offers a better improvement.
As I mentioned in my first post Weber of Michaelson are possibly better here, and one of those are what is used in nearly all the research & standards. However, I am working with Bartleson-Breneman perceptual contrast at the moment.
To make this point more clear: The "simple" ratio of #FFF to #808080 is 4.6:1 (3.95:1 if you add in the W3C's 5% bonus luminance). But #808080 to #40404 is a ratio of 178.88:1 (5:19:1 using the 5% extra).
#FFF is luminance 100, mid-grey #808080 is 21.59, and #40404 is 0.12
So ignoring the oddly-applied/misapplied "flare" value, white to mid grey is a ratio of 100:21.6 and mid grey to black is a ratio of 21.7:0.12
BUT because the first much smaller ratio is also associated with high luminance it is much easier to read and has much better PERCEPTUAL contrast:
I find no justification for the 4.5:1 contrast ratio for 20/40 vision as indicated in the W3's standard. Is it set that way (along with the excessive flare luminance add) to attempt make up for the other deficiencies?
See also reference  below, a EU paper on this subject.
Contrast Sensitivity is a separate measurement from visual acuity. From the referenced Arditi paper: "visual acuity measurements alone are insufficient to characterize basic spatial visual function..." But I don't see where you get multiplying the ISO well established 3:1 standard by 1.5 ?? Looking at acuity vs contrast graphs is see a difference in CS as low as 5% for a 20/40 person. And as I recall the common 3:1 luminance contrast ratio included near normal vision (20/40 is near normal).
Here's a graph, (for reference logMAR 0.3 is approximately 20/40.)
In short, it appears to me the 4.5:1 contrast standard is somewhat arbitrary, and there are other more important means to improve accessibility, namely font size, appropriate polarity, and total luminance.
NITS TO THE RESCUE! (by nits I mean cd/m^2, 1 cd/m^2 is 1 nit ... but maybe I also mean ME, nit-picking on this issue, LOL).
The sRGB spec states an 80 nit monitor, however people commonly adjust them to 120 nit to 160 nit, even more (300+ is common. Some phones do 1200). If the monitor is brighter, and the material is black text on white, the light from the monitor results in pupil contraction which improves perceived sharpness.
I'll opine that it is more important to have a monitor that is adjusted bright enough for its environment. In fact it would be a good idea to lobby the ISO for an amendment to the sRGB spec to adjust away from 80 cd/m2 to a specific luminance based on the environment. 1996 was a long time ago, and display technology has changed substantially — we shouldn't have to adjust the ROOM lighting to match the monitor, it's easier to adjust the monitor. A standard stating the max display luminance for a given ambient light would go a long way toward real accessibility/accommodation.
The main thing I am lobbying for here is a revised programatic contrast assessment that is perceptually correct. But as I research this, I see there are other concerns that should be considered.
Thank you for reading. I hope to have a solid contrast assessment model this week.
Edited May 22 for typos and some clarity.
Thank you for commenting, it helps me to see when I am not explaining or describing completely. But perhaps more important it leads to some new discoveries. In answering your post I did some experiments that add insight. More below.
First, just to provide a little more background, I want to mention that I have personal experience with 20/200 vision. Several years ago (in my late 40s) I developed early onset cataracts which brought my vision to worse than 20/200 in one eye, the other diminished a bit less. I now have IOL implants, but those surgeries caused vitreal detachments and retinal detachments, requiring a vitrectomy in one eye, and in the other, continuing issues due to large vitreal floaters that still can interfere with reading. Also, I still need glasses (i.e. it is trivial for me to remove them to introduce poor vision).
As such WCAG is a topic I have a close personal interest in.
As I mentioned in an above post, I am an imaging professional in Hollywood with a career that spans decades and a background that includes broadcast engineering, colorist, VFX Supervisor, and perhaps most relevant, title designer.
I came across this WCAG issue while developing a CSS framework. For the color module I am trying to create a simple color subset that is both easy to read and aesthetically pleasing. This led me down the color and vision theory rabbit hole, where I stumbled on a contrast calculator and saw an odd comment by the coder who mentioned that his "calculate" button did not pass the WCAG standard. The button is completely readable with more than adequate contrast, thus started my present research journey.
I have since been doing nothing but research this issue in depth. My posts here are based on that research and my extensive experience in digital imaging.
I cannot agree here. Estimating roughly, 40% of the color pairs the WCAG math calls "PASS" are poor in quality and should fail. And somewhere in the area of 51% of colors they fail could conceivably pass.
Wrong nearly half the time is one huge fail. I believe it is the result of incorrect assumptions and cherry picking various bits of standards and cobbling them together into something that is truly inaccurate and unsuitable for the purpose.
I'm going to quote Whittle from his paper  (emphasis added)
And then from Pelli's paper  (emphasis added)
The WCAG ignores this wholesale, despite it being prominent in most research and even noted in the ISO and ANSI standards. WCAG is using simple contrast (Lw/Lk) and that is one of the errors.
Among my findings, some of the sites I have the most difficultly reading are "compliant" with the WCAG. There are countless contrast checkers and other automated or semi automated accessibility checkers that use the algorithm as written, and they all fail to detect poor perceptual contrast.
And there are a LOT of combinations that pass but are hard to read. An accessibility site has this on one of their pages indicating the problem:
The contrast checkers are all using this flawed model which ignores many important aspects of perception. The results are all over the place and inconsistent. I can see why designers are ignoring the contrast recommendations: they are ambiguous and inconsistent at best. At the moment, visual judgement does a better job than the contrast calculators.
I have a page where I am conducting live experiments in this regard, aloing with some commentary on my findings as I go along. This link is:
Here are some examples from today's experiments:
Today, I've been looking into luminance — it is well known and researched that increasing luminance improves readability (within a range). One thing the WCAG lacks is a specification on minimum lightness for the lightest element in a color pair.
I have more on this on the page, but as you can see, setting a minimum lightness of the lightest element to #AAA results in a consistent, readable, block of text. On the page you'll see examples where pages with 3:1 contrast and minimum #AAA on the brightest of the pair is more readable than 4.5:1 contrast on darker pairs.
Yes, I am aware, there is definitely correlation to contrast sensitivity due to a number of vision impairments. Indeed, one can have good visual acuity and bad contrast sensitivity. The WCAG does not discuss CS though, and only lists some Snellen numbers like 20/40.
I was talking mainly of 20/40, which is what the WCAG talks about regarding AA. For the portion of the standard that relates to profoundly impaired, still the math they provide does not create useful numbers for guidance.
And that is the point I am getting at. The math is essentially wrong. Lw/Lk is not well suited for determining contrast in this context. The vast majority of research on contrast sensitivity uses WEBER or MICHELSON or both. Rarely simple contrast. But there are other math mistakes in WCAG related to sRGB and computer displays that also need to be addressed.
(EDIT by Andy: May 2019: My recent experiments and research indicates that a "classical, unmodified Weber contrast" is really not "substantially" better than the WCAG math, though there is a modified Weber from Hwang/Peli that is much better than the WCAG math, and other more modern contrast equations such as PCL).
I never said that 4.5:1 is too high, particularly in regards to profound impairment, 4.5:1 is TOO LOW when using the WCAG math. WCAG indicates 7:1 for the more visually impaired (AAA). And yes, the "understanding" text is all over the place and not clear.
To be clear, I am not "condemning" the 4.5:1 ratio per se, but I am questioning where it was derived from and the basis of the equations when those equations are not supported by standards nor research. I am also pointing out that luminance is a much bigger factor than contrast yet it is not mentioned, nor is local adaptation unless I missed seeing that. My statements here are from published research as well as my own research.
The California Council of the Blind (Lozano, 2009) states, and Federal ADA guidelines also state, that contrast for signs be 70% (note it is a percent not a ratio). The math used for the Federal standard is (B1-B2)/B1 (B1 is the lighter LRV, and B2 is the darker). Now, if I use the WCAG math, 70% equals a ratio somewhere around 2.3:1 to 3.2:1. WCAG math is all over the place and does not relate to Weber's law nor anything else useful.
Nevertheless, California Council of the Blind (Lozano, 2009) is on record stating that the Federal equation is flawed when B1 is less than 45. I just came across this a minute ago — I'm slightly amused as it is closely mirroring what I have been saying about the WCAG.
I describe this in more detail on the experiments page, and there are more examples.
In closing I just want to say that simply switching the equation to Weber is not the complete answer. I think we can do better, and that is the focus of my research.
Thank you again for the comments.
Edited May 2019 for some minor clarity fixes.
Hi @Myndex I appreciate your efforts in addressing the shortcomings of the current algorithm. In your examples, I personally found some of the first 4.5 items easier to read than the ones with values greater than #AAA -- thus I know there will always be differences in interpretation by different people as we all see differently. Along those lines with the adaption you were discussing, halos may technically be used to meet the requirement but when you take into account the width of the stroke and surrounding colors haloed text can actually be harder for me to read. I agree that we want more people to use contrasting colors that meet users needs and if we can change the algorithm to meet those needs without lessening it get more adoption that would be a good thing. Personally, I see these changes as something that can't be changed with the current standard as the method is too normative to change with an errata but would be a great opportunity to address for the next version of the accessibility guidelines (silver). It would be good to socialize this with some other folks such as Jared Smith from WebAIM who also would like to change the future direction of the contrast calculations and the Low Vision Accessibility Task Force which is part of the Accessibility Guidelines Working group. Adding @WayneEDick and @allanj-uaag.
If that is based on the images in my post above, I should mention that the SIZE of the first set is 30% larger, and therefore easier to read (I just realized the scaling error due to how this site handles images as I looked at the post, post edited to correct).BUT ALSO, three of the first 5 have the brightest color well above #AAA. For an apples to apples comparison, please see the live experiment on the website: https://www.myndex.com/WEB/W3Contrastissue
Indeed, for instance, research shows that most people do better with dark text on a light background (Positive Display) but with my vision, I much prefer light/colored text on a black background (Negative Display). Right now I am having difficulty with THIS site due to the bright background (L* 98 in the text area) yet for most people this is the ideal presentation.
Yes I see it was just tagged as WCAG 2.2 which I was somewhat expecting. Correcting the algorithm also means changing the standard, as far as I can tell the current standard(s) seem to be compensating for the math issues — I don't know the complete history, but that is how it appears based on the reverse engineering/analysis.
For an errata, it might be useful to place a note to the effect of: "Current contrast algorithms may overvalue contrasts with pairs of darker colors. Designers should be cautioned not to rely on contrast numbers in these cases/"
I should note that problems and controversy on this very subject are visibly present in the research and some standards. It is partly why I am being so proactive here. I hope to cut through the clutter to bring some clarity (puns more or less intended).
Excellent. What are the deadlines for 2.2? As I mentioned in one of my posts while there is much research on simple monitor displays (i.e. black on white, white on black), there is not much in the way of research on complex, graphically rich content (that I've found anyway). I'm thinking some empirical studies would be illustrative.
Another idea is using the difference between a brighter/darker L* values (as in CIE L* a* b*).
Those are all fairly simple models for contrast determination. A more advanced approach is a true color or image model like CIECAM02 or ICAM. ICAM is the work of Mark Fairchild at Rochester Inst. of Technology. A model like that could (I believe) analyze an overall page, as opposed to a pair of colors in isolation.
On the experiments page there is an example of local adaptation issues do to surrounding colors. But here's a quick example:
The blue text on grey is WCAG 4.5:1 contrast, and both bits of text are identical. But the one centered on black is more readable because the black allows local adaptation to the darker colors. So among other things, minimum padding for elements against a high contrasting color are important.
(I'll mention in passing that pair of blue on grey is a fail in my modified PCL algorithm).
And this is where things are more complicated than a simple contrast — web content is graphically rich. Text on a background may be a pass, but if it is far different than the overall page, adaptation will affect perceived legibility.
Thank you again,
Thank you @bruce-usab — I consider this a particularly important issue, partly because W3C standards are used not just for web but for app design and other applications as well. Because it is a freely distributed standard, it has a very wide reach. Myself I spend 12 hours a day in front of monitors, while that may be more than average displays are certainly integral to the lives of so many — we are inseparable from our technology — standards like this have a very real affect on people's lives. This standard in particular has become part of government regulations, for instance.
What is the timeline/deadlines for 2.2? I'm hoping to have some candidate contrast models soon, but also thinking there is one giant rabbit hole to crawl down considering how page complexity affects perception (adaptation) etc.
There is a mathematical problem with this discussion line. L1 and L2 are computed using weightings that take color receptivity into account. R, G, and B have distinct weights in the relative luminance formula.…
On Tue, Apr 16, 2019 at 12:32 PM Myndex ***@***.***> wrote: Thanks @Myndex <https://github.com/Myndex> for writing this up so thoroughly! Thank you @bruce-usab <https://github.com/bruce-usab> — I consider this a particularly important issue, partly because W3C standards are used not just for web but for app design and other applications as well. Because it is a freely distributed standard, it has a very wide reach. Myself I spend 12 hours a day in front of monitors, while that may be more than average displays are certainly integral to the lives of so many — we are inseparable from our technology — standards like this have a very real affect on people's lives. This standard in particular has become part of government regulations, for instance. What is the timeline/deadlines for 2.2? I'm hoping to have some candidate contrast models soon, but also thinking there is one giant rabbit hole to crawl down considering how page complexity affects perception (adaptation) etc. Thank you! Andy — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#695 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0OF8FugSGRVmc2nIyMdaxNKnTND_7dks5vhiUzgaJpZM4cui9x> .
Hi @WayneEDick , thank you for commenting. I’m away from the studio, on location, so I can’t comment in depth, but:
Yes, luminance is spectrally weighted. However luminance is a linear measure of light.
Light is linear (additive) but human vision is NOT linear (essentially a power curve). So while the sRGB coefficients adjust for spectral sensitivity, luminance is NOT relative to PERCEPTION of lightness. L* is perceptual (CIELAB), and gamma encoded transfer curves are somewhat perceptual (such as luma, the Y‘ of Y‘IQ) but not luminance (Y).
But that’s not even the most relevant part. L1/L2 is called “simple contrast” and it is wrong in this context. The “standard” for contrast for TEXT is Weber, which is based on ∆L/L typically as
This issue came to my attention when I saw the contrast equation was wrong (as is the sRGB threshold WCAG lists), as I have outlined in my posts above. But now that this is being discussed, we can do better. I am currently investigating PCL and other methods.
For further details, I suggest Charles Poynton’s GAMMA FAQ and COLOR FAQ. Here’s a link: https://poynton.ca/GammaFAQ.html
@Myndex, you asked:
The formal/approved Project Plan has a goal of this time next year for the first public working draft.
I am not optimistic about the chances for wholesale replacement formulas for 2.2. That is possible for 3.0.
Yes. I am one of the actors in helping that happen.
There was some user testing associated with the validation of the 2.0 formula. I could not quickly find a cite for that. My recollection is that the hard data pointed to a ratio of 4.65:1 as a defensible break point. The working group was close to rounding that up to 5:1, just to have round numbers. I successfully lobbied for 4.5:1 mostly because (1) the empirical data was not overwhelmingly compelling, and (2) 4.5:1 allowed the option for white and black (simultaneously) on a middle gray.
I am sorry to say that I will offline for the next ten days or so, but I will be circling back to this!
@Myndex, this one assertion leapt at me:
That formula was only ever intended for reflective light, not luminescence. It was promulgated in the 1991 ADAAG and was sufficiently problematic that is was dropped in the 2004/2010 ADAAG/ADAAS.
Your citation  clearly states (more than once) that 70% “is no longer a requirement”.
Just upfront - I strongly suggest we come to a resolution on this issue before you spend time creating a PR.
This doesn't match my testing with people over the years. Not a large scientific study, but 100s of tests (since the early 2000s) with people with low-vision. Whenever there was a color combination that people struggled with it virtually always failed on the contrast level checks.
I've also found there are huge differences between people and the particular colors that were an issue for them. E.g. Some participants couldn't see a strong pink on white, which others couldn't ignore as it was so intense.
Broadly I think the context that you need to account for is what the guidelines are for, and how they are used. A method to measure contrast for the web content accessibility guidelines needs to:
A lot of the factors you added in the summary above cannot be accounted for in a web standard (e.g. display polarization, nits).
Also, at least some of the examples you created have the same 'background bias' effect I mentioned here, perhaps you know the name for that effect? I.e. having a different general background behind the area of interest affects the perceived readability. Reading on, I guess this is the 'local adaptation' issues?
In short, I don't think there is such as a thing as a "revised programatic contrast assessment that is perceptually correct", but I'd love to be wrong. A change would need a lot of real-world testing to ensure it provides better results.
Given the scale of change this would require (including the research), I suspect it would be a 3.0/Silver type of thing to do.
This is the section in reference  I was referring to (I did not read the entire document, I was mainly pointing out the continued controversy and unsettled nature of the issue):
Historical and current studies of contrast sensitivity it is typically about 1% to 1.6% over a wide range from 7 or 8 cd/m2 to over 500 cd/m2. NASA also found that under 8 cd/m2, contrast sensitivity fails increasingly.
But on the subject of reflected light vs emitted light: both can be measured in luminance. Luminance is proportional to both illuminance and reflectance.
And this is one of the HUGE ENORMOUS PROBLEMS facing us in the present conversation, I have seen two COMPLETELY DIFFERENT definitions of LRV. The correct definition of LRV is based on luminance (Y or L) which is linear light, yet some sources state it is based on lightness (L* as in CIELAB, L* a* b*) which is perceptual lightness NOT linear light.
YIKES. It appears this stems for the error in the 1991 ADAAG, which from what I have been reading was using Weber on L* and not Luminance?
Hi @alastc I agree and said as much in one of my posts, it is why I am posting an issue instead of a pull request first.
That's good to know, though I am concerned about the large number of sites I encounter that pass the test yet I find very hard to read. I am less concerned with false fails and more concerned about the false passes in other words.
A "strong" pink on white should have a fairly low luminance contrast, and should fail with proper math though the WCAG math might pass it when it should fail in some cases. The problem with hue is how people with color deficient vision rely on luminance contrast. But also, a light background changes perception of text & contrast vs a dark background. I'm wondering how those who had a hard time with pink on white would have seen the white on pink.
Yes the main issue is adequate luminance contrast. A useful tool for designers might be a tool that captured a website and converted it to greyscale based on luminance so the designer could see the luminance contrast without being influenced by hue.
Cheap or expensive, displays are built to sRGB standards, and often with better brightness. But not the point, as the eye adapts to various conditions of light. What is important is to consider how adaptation affects readability (more on that below).
Most that I am discussing is simple to implement. (It's not harder to use correct math, for instance).
It can — when I talk of polarization, I talk specifically of web DESIGN. light text on a dark background is "negative polarization" (or confusingly, positive contrast) and vice versa.
As for nits (cd/m^2) I'm not saying the web standard should specify any particular "absolute" luminance output, but the standard IS already trying to take environment into consideration
Local adaptation, and adaptation in general, need to be part of the design considerations. Dark text on on a grey background may pass via the math, but if the grey background is a div with no padding on a white background, they eye adapts to the white making the dark text on grey hard to read. There is a demonstration of this on the experiments site.
There are definitely better choices than using incorrect math, which is the current state. And while vision and perception are complicated, it is also mostly academic in terms of things like contrast. There is a wealth of research on vision perception and contrast over the last several hundred years that can and should be used to guide this standard. In other words, yes there is such a thing as "programatic contrast assessment that is perceptually correct." It's just a matter of implementing it.
There may be added challenges in modern webpages due to the graphically rich content AND the variety of environments due to mobile devices. But the W3C provides the standards and guidelines not just for web design but for browser software.
(edited for spelling and some clarity issues)
False fails/passes & ‘incorrect math’: Yes there is lots of research, but any model using Mathematics is a mapping of how light is measured to how it is perceived.
There are individual differences in perception, so there cannot be a perfect model (that’s what I meant by ‘no such thing’). Otherwise the pink example wouldn’t vary by person.
A different model may improve the fit across a range of visual impairments, but it is not an absolute right/wrong. One model will not fit everyone perfectly, and we should be optimising for people with visual impairments rather than the general population.
If there is a better industry standard model to use for measuring contrast, great, let’s test it across a range of people.
There are already tools for greyscaling a screenshot, but we need to be able to assess text (and certain graphics) and show a pass/fail individually.
Web content can be defined to use color spaces other than sRGB, but we are planning to standardise testing of contrast to sRGB as a lowest common denominator.
That makes sense, there are probably some incremental changes that might be helpful as well as "leading a path" to a larger change.
Ah excellent! However, that also means that the standard needs to be solid and unimpeachable. I'd like to help to get to that point.
Hmmm. I'd love to see this data. I believe you that the ratio from the data is higher that other standards as the equation being used overstates the contrast ratio in addition to being perceptually incorrect.
I'm not sure it does, as written the equation is overstating contrast for darker colors. It appears the equation does not take system gamma gain into account, nor the floor of 8 cd/m2 in terms of minimum luminance for contrast (NASA). More discussion to come on these issues.
QUESTION: it would be helpful to get online access to certain ISO standards, as well as papers used in the current specification — is that possible?
Just for context though, the formula was already in WCAG 2.0, and that's been out since 2008 https://www.w3.org/TR/WCAG20/ ... so just a word of warning that it's something deeply enshrined and not something that can be changed quickly or easily. It would take a few years at least...
HI @patrickhlauke, Yes, I do realize this and recognize the issue. I'm certainly not expecting any overnight major change! As I mentioned in one of my posts, I am looking at potential incremental changes that can lead to a more solid solution.
At the same time there are a lot of other related standards that use different models and compliance parameters. Nearly all of them are using Weber, but there are newer more useful models emerging.
I mentioned some of the reasons I'm motivated for some positive changes here — and to be clear, my intent is to assist in finding easy and workable solutions to the issues I've outlined, and perhaps others.
As CSS, Java, HTML develop into greater feature sets, I've noticed a disturbing trend toward sites that are "fancy but less useable." So much so that many browsers now have the reader view to turn off all the crap!!!
Here are my questions. When you use the term spectral in the sense of functional analysis? While gamma is not a linear function it is differentiable and can be represented piecewise by line segments without? Are you saying the W3C representation does not use enough line segments in it's approximations? Or are you saying that gamma does not come into the equation? Finally what is your formula precisely including visual factors. I would like to analyze this. I am a mathematician. Sincerely, Wayne Dick PhD.…
On Fri, Apr 19, 2019 at 3:41 PM Myndex ***@***.***> wrote: Just for context though, the formula was already in WCAG 2.0, and that's been out since 2008 https://www.w3.org/TR/WCAG20/ ... so just a word of warning that it's something deeply enshrined and not something that can be changed quickly or easily. It would take a few years at least... HI @patrickhlauke <https://github.com/patrickhlauke>, Yes, I do realize this and recognize the issue. I'm certainly not expecting any overnight major change! As I mentioned in one of my posts, I am looking at potential incremental changes that can lead to a more solid solution. At the same time there are a lot of other related standards that use different models and compliance parameters. Nearly all of them are using Weber, but there are newer more useful models emerging. I mentioned some of the reasons I'm motivated for some positive changes here — and to be clear, my intent is to assist in finding easy and workable solutions to the issues I've outlined, and perhaps others. As CSS, Java, HTML develop into greater feature sets, I've noticed a disturbing trend toward sites that are "fancy but less useable." So much so that many browsers now have the reader view to turn off all the crap!!! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#695 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB6Q4F4R2KE2T7DNR7IJLFLPRJDDJANCNFSM4HF2F5YQ> .
Pink/white relates to hue contrasts. The more perfect accepted model is luminance contrast as it's connected to contrast sensitivity. CS threshold is 1%-1.6% over the wide range of 8 cd/m2 to over 500 cd/m2, as shown in study after study, including many visual impairments. There are of course some impairments that directly affect CS/CSF, but contrast sensitivity is separate from visual acuity.
Visual acuity is helped more by size than contrast. perceived contrast is more complex than a ratio between two colors as it is substantially affected by adaptation, local adaptation, chromatic aberation, and other issues.
CHROMATIC ABERRATION: So this relates to an optical issue with any lens system, including human eyes. Light at different wavelengths are "bent" differently through a prism, which is why a prism creates a "rainbow". Lenses are a form of prism, and blue light through a lens lands in a different spot than red light as a result. (It is theorized that this is why our eye evolved to have red cones in the center and blue cones on the periphery). But this is a reason that red (#F00) and blue (#00F) look wacky together - the shared red/blue edge focus to different places on the retina. The hot pink you mention is #FF00FF - so red and blue with no green, the red portion of the text edge focusing differently than the blue edge. So for instance, working with colors that have a high blue content needs care, as NASA discusses:
That NASA site covers a lot of related material, and it is all about user interface design considering adverse viewing circumstances.
The "standard' has been Weber the 1800s. There are better models now, and particularly as web pages are a "unique environment" in that they are displayed using certain standards, there are definitely better ways to assess perceptual contrast.
Okay, but as I have demonstrated and discussed, the ratio of two colors by themselves in isolation will not give you a complete answer.
Hmmm, no you can't. The standard is still sRGB. the CSS 4 working draft does list additional working color spaces as something desired for future implementation, but that's a pretty horrible idea at today's level of technology. sRGB is ideal for 8 bit. Any larger colorspace and you start needing at least 10 bit pretty quick. I see talk of linear_sRGB or linear_Rec2020 - then you need at least 16bit_HALF(FLOAT). Double bit depth and you double data size, and pages are ALREADY overbloated and slow. And you'll NEVER see the benefits under typical ambient conditions and cheap devices.
To wit: bigger color spaces do absolutely ZERO to assist impaired vision, There is ZERO luminance contrast difference (and it's worse if you stay in 8 bit: A super-big space like ProPhoto is GARBAGE on 8 bit, and will provide WORSE contrast gradation (i.e. causes banding) due to the ginormous delta E errors. NOT TO MENTION the fact that ProPhoto uses IMAGINARY primaries, meaning that values like #00FFFF DO NOT EXIST in ProPhoto as something you can see.
Most mobile browsers and many desktop browsers still do not support any form of color management. sRGB is the standard, and is expected remain that way for the foreseeable future. The CSS tag for alternate colorspaces is not.
FOR ACCESSIBLE: 8 bit and sRGB (and Rec709) is the ideal standard at present technology.
Yes, there are some emerging color spaces like Rec2020 that are bound to make a difference someday but all these alternate color spaces have different transfer curves and different primary coordinates. Converting between spaces is computationally expensive, which is why most mobile browsers are NOT color managed and instead are sRGB "compliant".
I have high end $$$ wide gamut monitors (which are probably what caused my early cataracts), but those are rare — sRGB/Rec709 define nearly all distributed content be it Web or Broadcast worldwide, and in a non-color managed way. If you use monitors OTHER THAN sRGB/Rec709, then you MUST have color management to transform colorspaces, and that is computationally expensive. I discuss some of this in some articles I've written over the years reprinted here: https://www.generaltitles.com/helpfiles/13-q-a-blog/colorspaces-and-file-types
Thank you for the comments!
Hi @WayneEDick !
This is part of the CIE 1931 standard on luminance, the Y in CIEXYZ. The standard is spectrally weighted relative to the LMS cones (red green blue cones) that make up human trichromatic vision.
The coefficients 0.2126, 0.7152, and 0.0722 are part of the Rec709 standard for HDTV, and sRGB is derived from that standard. Both Rec709 and sRGB use the same color primaries and white point — the only practical difference is the transfer curve (effective gamma) is a little different between sRGB and Rec709, the reason being that Rec709 gamma is relative to a dark living room and sRGB is relative to a brighter office type setting.
Charles Poynton's Gamma FAQ is really the best crash course on this.
Gamma is one form of a "transfer curve" to transform a particular color value from one colorspace to another. It is often represented "piecewise by line segments" as what we call a LUT (look up table). LUTs are very common in the film/television industry because the color represented in negative film is sufficiently complicated that it can't be accurately represented with a simple equation or matrix. 3D LUTs are used to create accurate transforms through various color spaces in the post production process.
Some color spaces like Adobe98, use a pure exponential transfer curve.
BUT ALSO: the sRGB and Rec709 transfer curves in their "correct" implementation use a combination of an exponential curve attaches the a linear region near black. The linear region has a number of purposes and motivations, including reducing camera noise near black and math issues with pure exponential curves near black.
It uses "none" because luminance is linear, as in a straight line. Luminance has no gamma (or technically, the gamma is 1.0). Luminance is proportional to light, and light in the real world is linear.
The human eye is NOT linear, photopic vision has a gamma of around 2.4 to 2.5 (though vision is more complicated due to adaptation, scoptic (rod/dark night) vision, etc.)
This is the CIE L* curve
Right now human perceptual contrast is not represented in the WCAG "Understanding 1.4.3."
Luminance is derived by first applying the reverse transfer curve to each of the R´G´B´components, then multiplying them by the coefficients, and then summing them for the total luminance (Y but sometimes shown as L but NOT to be confused with L*).
THEN they use a simple contrast ratio Yhi/Ylo or as they print it L1/L2. They also add 0.05 flare to each term. ((L1 + 0.05)/(L2 + 0.05)).
So here is the point I was getting at: the use of L1/L2 is only useful for very absolute black & white values, because it ignores a lot of what happens with perception of in-between values.
The "standard" math for contrast of TEXT is WEBER CONTRAST which uses the Weber fraction, which is ΔL/L — Weber has been around for a very long time, and most contrast standards and research are based on Weber or Michelson, not simple contrast. Simple contrast is used for example for the contrast of a monitor from maximum black to maximum white, but not for the in between values.
EDIT: Weber contrast is often stated as (Ybg-Ystim)/Ybg, but this can result in odd results. For monitors/displays, try (Ylightest- Ydarkest) / Ylightest
I am NOT saying that Weber is the ultimate solution, but it is what jumped out at me when I was investigating why web contrast calculators were presenting "weird" numbers relative to legibility. This led me on this path of "how did we end up here" which has now morphed into "what is the most useful modern perceptual contrast calculation."
Other notes on WCAG math: The sRGB conversion to luminance is using some incorrect values. The problem is minor and likely has little effect on the contrast issue, but I will show to the correct sRGB formula below.
Also, just FYI the coefficients must be applied only after the gamma is removed, but there is an interesting wrinkle here: even the "correct" luminance math does not account for system gamma gain. There is an additional 1.1 or 1.2 exponent applied to the signal by the monitor/display. This is common even in older systems like NTSC, which used a 1/2.2 exponent at the camera, but the CRT display was actually ~ 2.5 resulting in a system gamma gain at final display. Final display gamma can in fact be adjusted by the user with the monitor controls (that adds the uncertainty aspect to all of this). But I did notice that when I added a 1.2 exponent to the resultant luminance, it improved the perceptual uniformity of the resultant reported contrast (at least it seemed to, I have not run a real controlled study yet).
I suggest looking at Weber contrast, Michelson contrast (aka modulation), but also two modern methods that I am investigating and experimenting with, Bartleson-Breneman Perceptual Contrast Length, and one I just recently found that apparently is the basis for the Australian accessibility standards, the Bowman-Sapolinski Equation , though I;m not certain it can be used on CIE Y (Luminance). And then there are methods using L* (perceptual lightness from CIE L* a* b*) instead of luminance, in that case, it's not usually a ratio, but a difference (L*1background - L*2 foreground) as L* is perceptually uniform.
So for normalized values of 0 is min and 100 is max:
Y (luminance) 0 = L* 0 = sRGB 0 and Y 100 = L* 100 = sRGB 100
This is because the perceptual halfway point between black and white is not a luminance of 50, but a luminance of 18.4 but on the perceptually uniform L* curve, the halfway point is 50. On sRGB its about 46.7 because as I mentioned earlier, sRGB has additional system gamma gain. Adding an expoinent of 1.102 to Y will put Y 18.4 at sRGB 50 for example (and I'm not saying that necessarily "should" be done, just that's how the math is for comparison).
That is REALLY awesome to hear, I was hoping a mathematician would get involved. I have some planned experiments this weekend, I'll post more as I progress.
Note: the correct luminance calculation for sRGB -> D65 Y is:
R * 0.2126 + G * 0.7152 + B * 0.0722 = Y (D65 luminance)
For your cut and paste convenience, here is the gamma-to-linear portion from my OO spreadsheet:
=IF( R1 <= 0.04045 ; R1/12.92 ; POWER(((R1 + 0.055)/1.055) ; 2.4) )
ALSO if you are looking at other color transforms, we are only concerned with D65. Some CIEXYZ and L* a* b* transforms use a D50 whitepoint, which should not be a part of anything we are doing with monitor contrast, it's D65 only.
MORE USEFUL CONTRAST MATH
So today I came across this recent research at NIH (just a couple years ago) that directly states what I have been attempting to explain in the above posts. While they don't mention the WCAG, they do use the WCAG simple contrast ratio (CR) equation as a comparison to their modified Weber equation, including the WCAG's 5% ambient component.
The paper states specifically (emphasis added):
They do modify Weber a little differently than I have, and their results are interesting and provide a further demonstration of the problems with "simple contrast" (CR). There are a couple small caveats I'll discuss after the summary. The paper is a short read, but here's a synopsis:
The WCAG contrast ratio (CR) is (Llight + 0.05)/(Ldark + 0.05)
The modified Weber is: (Llight - Ldark ) / (Llight + 0.05)
Hwang-Peli Modified Weber for Realistic Contrast for Monitors
For the purposes OF THIS DISCUSSION THREAD, I want to offer these (hopefully more clear) terms based on acronyms:
WOB: for white on black, any light text on any darker background.
WOG and BOG, where the background is near a middle grey value.
Next Post: Path Forward.
Based on all the research and discussion THUS FAR, I see the following general path forward as far as changes and pull requests for the WCAG:
WCAG 2.2 (and possible errata for 2.1/2.0)
THREADS: Should we create a new thread for 3.0, and then set the discussion here just to the incremental changes I've proposed for 2.2?
Thank you all again for all comments and thoughts.
In the interest of providing a status and recap of this thread:
Modeling Light and Perception
There are two basic groups of models for light and vision:
One is how light exists in the real world, and how to model light mathematically, i.e. linear light models.
The other is human visual perception of light which is very non-linear, and moreover, visual perception is a function not only of light values, but also spatial frequency, the eye's light adaptation state, neurological development, and then various levels of impairment, etc.
In the real world, light values are additive. That is, if you have 100 photos of light and double it, you then have 200 photons of light. But humans do not perceive this as a doubling.
Linear image encodings (code values linear to light) are very useful for compositing (combining multiple images) as it makes math operations easy — you can use simple addition for instance, as that is how light in the real world acts.
However linear light models do not model human perception, and you cannot use linear light models and hope to predict how a given stimuli will be perceived. This is the main issue with the present WCAG 2.x contrast math: it linearizes sRGB to Y (the linear luminance from CIEXYZ) then uses this to determine a ratio.
But as is now known, the results are not consistent with the human experience of vision, regardless of impairment.
All forms of human perception are non-linear. And vision is especially non-linear, with many added nonlinearities on top for a multi-non-linear extravaganza. Predicting visual perception is extraordinarily complex as a result.
CIELAB and CIELUV are simple models that attempt to approximate human perception. The idea was that then you could use the simple euclidian distance between two colors to predict the perceived change or difference. But even these models fell short of accurately predicting color difference perceptions. They were followed by various CAMs (Color Appearance Models). Some of these models are incredibly complex, such as Hunt's model, and Fairchild's ICAM.
CAMs have been instrumental in developing image data compression, as they predict what can be discarded while maintaining image fidelity. For instance luminance (light level) is three times stronger in contrast and resolution of fine details than hue and saturation. So in many encodings, color data is reduced in resolution relative to the luminance data.
Ultimately these models are complex because human visual perception relies on more than just light values.
For readability, we can simplify, provided we understand the gestalt of visual perception, which is a combination of:
For readability, we can focus on the aspects that are most critical. Those things are simplified to:
Perceptual color difference as distance, as affected by expected light adaptation & predicted local adaptation from context, as affected by spatial frequency of the stimuli, with consideration for impairments, and flexibility for impairment adjustment.
SAPC (development name. Release name will be APCA) does this with a combination of an extensible algorithm (new maths) which reports a contrast result as a percentage value, coupled with easy to follow guidelines for content design that have their roots in classical design and color theories.
All with a focus on readability.
Thank You All for Your Participation and Support.
Apologies if I've missed it above (and with a long thread, it might be hidden), but is there an easy definition or explanation of "Spatial frequency"? I'm guessing the Wikipedia definition is correct but not entirely useful? "a characteristic of any structure that is periodic across position in space"
Maybe we need another term for use in WCAG 3? Something like Text density: A measure of how wide each stroke is and how widely spaced the letters are. (Poor grammar, but is that in the right ballpark of meaning?)
"Spectral distribution" has also been tripping me up, it has a dictionary meaning but it isn't very helpful if you don't already know what it means, most references seem to be for radiation. Is that what you translated as "Perceptual color difference as distance"?
This is amazing, and SO welcome. As a designer who is looking to create accessible software products, I have had a range of experiences with the current generation of contrast checker tools that range from disappointing to actively bad. I'm glad that my perception of poor results wasn't based in my own biases.
How reliable is the linked SAPC tool with regard to the emerging standards in development? If I were to adopt that as my contrast checker of choice, would I be too far ahead of the curve, or can I reasonably expect the standards to move in the direction of results I get from the SAPC tool?
If not in this thread, we did discuss in some others (I think 665) Spatial frequency in our application relates to FONT WEIGHT.
I have an explainer with demonstrator here: https://www.myndex.com/WEB/WCAG_CE14weight
The SAPC tool is a beta, but is part of the first working draft of WCAG 3. It is not the final answer, but part of a series of steps focused on bringing technologies that accurately predict perceived contrast and readability, along with guidelines that designers can use.
The reality: perceived contrast is much more than just the difference between two colors. It's multi dimensional in scope, things like font weight, size, ambient light, immediate background, larger background, line spacing, letter spacing, etc etc all have an effect.
In the first draft, the most important aspects: Font weight and size, and color pairs are what is taken into account, in part to keep the workflow simple and similar to the existing, On top of this, design guidelines are discussed in the explainer texts. At some point more will be added to the algorithm (it's extensible) but one thing: classical design theory has often been about readability. Much if it applies here as well.
In this context, spectral distribution means the eye's response to different frequencies of light.
There is no such "thing" as color — there is only different frequencies of light. But we interpret those different frequencies with the sensation of color. In a normal eye, green is by far the most prominent, making up over 70% of total luminance. Red is a little over 20% and blue is less than 10% (in some models blue can cause a luminance reduction).
There are further interesting aspects of spectral distribution — the "blue" S Cones are not present in the fovea, only in he periphery, and there are very few - only about 2% to 7% blue cones to the red and green. It is thought that this is nature's way of dealing with "chromatic aberration" (different frequencies of light bend at different angles through a lens, so blue light bends more than red light, and ends up at a different spot on the retina.)
Some of the implications for design include considering problems of some color pairs and their affect on resolution. Blue for instance is very low in resolution due to the very few cones and lack of any blue cones in the fovea. This does not mean one cannot work with blue, just how. Pure blue can never be the brightest of two colors. You can not have #00F text on a #0 background for instance. But you can add substantial green, such as #0AF to make that a workable blue.
Something I've been working on a a way to reduce glare and chromatic aberration is to have color pairs with equal blue in both the text and background, such as BG #CA9 and text #9 — what this means is that there is literally zero detail in the blue channel, but also no "shimmering" or other glare-type artifacts.
To help illustrate what I may not be as verbally clear with:
The colors are identical in the top and bottom lines, the only change was reducing the spatial frequency by using a larger and heavier weight font:
This has particular implications for accessibility, as various impairments affect the minimum resolvable spatial frequency.
THe example below demonstrates some of what I was saying in the previous post.
And to add, the effect of "flattening" the blue channel to reduce or eliminate details in the blue channel as a way to improve readability:
In addition to chromatic aberration, there is probably some opponent color processing that partly results in the shimmer effect on the lower sample.
In the last example, the blue on yellow has so much chromatic contrast that staring at it causes a (short-term, like 1m) persistent visual artifact for me, and just having it nearby still makes the darker-blue-on-pale-yellow example harder to read than it would usually be.
In fact, those are screen shots from the explainer I wrote...
I don't want to publish the link, but if you wanted to look at the rest lemme know and I'll DM you a private link...
Yes, interesting effect isn't it? The lower example is intentionally playing on the "opponent color process" and nearby strong opponents can have a disruptive effect on other stimuli.
Chromatic aberration is an optical phenomenon due to light of different wavelengths bending different amounts — but I believe the shimmer sensation for those that have It is in part a neurological phenomenon, either with the ganglion cells behind the retina, or somewhere in the visual cortex, particularly filtering stages v1 and v4/v8 -- and likely a combination of all.
Blue/Yellow is an interesting one because literally all three of the color opponencies are in play is some way, plus resolution and chromatic aberration.
But also, to draw your attention to it: of the "beige" and the yellow, does the beige "feel" darker? It does to me.
Yet both the beige and the yellow have the same amount of red/green. But the beige has blue in it too, and the yellow does not.
Can Adding Light Make Something Darker?
In other words, adding the blue to the yellow to make beige.........also makes it have a darker sensation for some people. Blue having a negative luminance is presented in some color models. Addressing these non-intuitive color issues will be part of the color module in development for SAPC, but that will not be part of the first working draft as more research needs to be completed.
And again it's useful to mention that "color" is not real, it is only a perception — in the real world, there is just light of different wavelengths. But our perceptions do not respond linearly to light in the real world.
This also demonstrates why contrast is "a lot more than just the difference of two colors"
I "think" you have much younger and less damaged eyes than I do — I have a very difficult time looking at the second blue/yellow — though if you spend much time on some of my sites you'll recognize the blue/beige combo.
ALSO: the device you are using (the screen technology), and how (or if) it's calibrated, and the ambient light, and are you wearing glasses or contacts with any blue blocking effect or UV filter.... these will also account for different perceptions here.
And again: "color" is not real, it is only a (nearly arbitrary) perception of light of different wavelengths that emphasizes some over others (assumed to be a result of evolutionary survival/selection). And not only do different people have different perceptions, those perceptions change over time and are also the result of early neurological development. For instance it takes 20 years for the brain to develop peak contrast perception — and if a young person has an astigmatism that is not corrected before age 12, that impairment get's "baked in" to the brain, even if glasses are later prescribed.
Red/Blue is the largest difference in wavelengths, and thus the greatest chromatic aberration. It is also the most likely to cause chromostereopsis, i.e the 3-D effect of depth just due to the colors. But this is not uniform across people, and is very neurological in nature and thus one could expect it's in part due to early neurological development.
A question might be, do kids with lots of Fischer-Price toys as infants-toddlers develop a different color and depth perception than those that have a different form of early stimuli?
Hi @StommePoes thanks for commenting
Hi Everyone, Since Andrew mentioned a couple of times about the relation of font size and its perceived background to foreground ratio... You may find this interesting: https://gist.github.com/xiaochengh/da1fa52648d6184fd8022d7134c168c1#use-case-reduce-layout-shifting-caused-by-web-fonts
for example -- "In short, it appears to me the 4.5:1 contrast standard is somewhat arbitrary, and there are other more important means to improve accessibility, namely font size, appropriate polarity, and total luminance.
First - if the question is contrast -- the fact that text size help reading (which is covered in another provision) and polarity and total luminance (which a page author has no control over) is distracting and not helpful.
Second - the fact that 4.5:1 seems arbitrary to the commenter is irrelevant. It was not arbitrary and was derived from several years of research, working with low vision experts and the working group -- and addressing comments from multiple public comment periods. . the rationale was explained and many of the problems now being faced by the working group are examples of moving too quickly around this topic without thinking it through.
I am happy to revisit this and see if we can come up with a better measure for modern display technologies - if it is needed -- but we should, I think, focus on the topic - and talk about how the original was calculated - and then how it can be improved -without talking about text size and luminance or polarity that is outside of the scope.
I have also (and at the time we were ) concerned that some things that passed did not seem very desirable. And if you are at the very low end (grey over black) you can get 'contrast' that didn't give good readability.
So lets see some alternate proposals and samples. I would LOVE to see a better formula
But remember that in the end you need
PS can someone digest this into 1 page. having the long string of comments that go off in different directions is a problem. It would be good if people making proposals - try to address all of the comments above in their proposals. I have to say that I find it very difficult to get a coherent picture out of all of the above. thx
Hi Gregg @GreggVan long time no chat, hope you are well.
I started this thread two and a half years ago. The first few posts in this thread here have only minor relevance to the eventual direction the research has taken us. And the latest work is not in this thread, but elsewhere, and I'll indicate more below.
As a reminder, you and I discussed much of this material in a series of emails circa June of 2019. Your comments then are similar to those of today as I recall, and I did indeed take them into account over the intervening years.
DUSTY OLD STUFF
Nothing is unsubstantiated, and I'm not sure what you mean regarding "conflating issues". We have solutions working in public betas now that are widely embraced by the design community and demonstrably better for accessibility and readability.
But I think you are glancing at the first few posts in this old thread of 123 posts — and this thread is NOT the canonical repository of the emerging research. It is an "historical record" of the first few months of what became a multi-year research project. I don't want to discuss old hypotheses.
We discussed this at length in those 2019 emails. Set aside comments regarding "4.5:1", the deeper dive determined the problem with the math and non-perceptual methods. And in fact, the first posts in this thread are two and a half years old, so it is of limited use to discuss, as we are far past them at this point. I'll add some links at the end of this post.
But on the topic of contrast ratio, I found Dr Arditi's 2017 article that points to the flaws and lack of empirical evidence for ratios like this interesting. https://jov.arvojournals.org/article.aspx?articleid=2628138
Which problems now being faced by the working groups? Which several years of research? I don't want to publicly comment further on this paragraph, please recall we discussed this in email in 2019.
I did not just start this thread, I have been proactive in finding the solutions to this and other related issues. This has been my primary research project, and it includes an R&D roadmap that is 3 to 5 years into the future. in fact I have "mostly" been working to be positive and proactive in developing new and future technologies instead of deriding previous iterations, except where it's necessary to provide a comparative context.
I'll discuss scope in a moment, but first...
Okay, it's called APCA — the Advanced Perceptual Contrast Algorithm for self illuminated displays, a subset of SAPC, which is a perceptually uniform colorspace for self-illuminated monitors, with extensions for accessibility.
It traces to, or is related to, modern vision models such as CIECAM02, R-LAB, Hunt, and more. It also considers important aspects of perception of self illuminated displays and related accessibility concerns.
The public beta for the simple tool is https://www.myndex.com/APCA/
There is the research version with some interactive demonstrator experiments at https://www.myndex.com/SAPC/
APCA is now incorporated into Chrome and other third party tools, and is a part of WCAG 3.
That said, text size and weight is definitely not outside of scope. Spatial frequency effects can have a greater impact on perceived contrast than a color pair, and is particularly true for readability contrast for small thin fonts. At the very least, the color (lightness contrast) and spatial frequency (stimulus size/weight) are inseparably intertwined. These design aspects are definitely in the scope of content authors.
For that matter, so is polarity in the design, so are the colors chosen and the relative luminance thereof. Not sure how you say that they are out of scope when WCAG 2.x 1.4.3 is using a ratio of relative luminance, and specifies a ratio dependent on font size and weight for the 4.5:1 and 3:1 breakpoint.. ?? YES, a user can override ALL of these using system level and/or browser level overrides. That does not mean these design aspects are out of scope for content authors.
If you are searching for a "why" the old 2.x/1.4.3 metric is failing "worse" today, look at Google fonts, which distributes fonts at ultra-thin weights of 100, and contrast destructive technologies like -webkit-font-smoothing, and the massive proliferation of mobile devices, and other related issues.
You really had none of these things to account for in 2007, when fonts were "Verdana" and sites were still using HTML 4 and many were not using much if any CSS. Today, HTML 5 makes CSS mandatory, and with the design flexibility of CSS comes...a lot of bad design choices.
Yes, the math used for WCAG 2.x contrast is not perceptually accurate. Many dark pairs are false passes, and reverse (light text on dark) fail with false fails, which designers find frustrating. As a side note this has resulted in derisive comments in the design community, and which creates animosity and resistance to adopting the guidelines. It should be noted that designers complaining regarding issues with the 2.x/1.4.3 contrast is what brought this to my attention and resulted in my involvement, starting with this thread, but shortly after becoming a W3 invited expert and providing solutions to these and other issues.
Here are two brief Gist articles with direct examples:
Yes, you and I discussed these in 2019, and as well I have been in constant collaboration with @bruce-usab Bruce Bailey of US Access Board who has been very helpful, such as regarding scope of impairment types, etc, and he has been involved as have a number of other AGWG members over the last few years. And indeed these issues you mention are motivating my research in this area. Specifically:
More important, APCA and the related WCAG 3 contrast guidelines provide for demonstrably better readability for all.
Providing a TL;DR
This thread is not the canonical repository of research notes. While I am working on papers for publication, there are the demo tools with info, and there are the guidelines in Silver/WCAG 3.
There is not presently a "super concise" white paper that covers all, but we do have a Visual Contrast Wiki that is the closest thing on a one page white paper. That said, it is not updated with "all" the latest, but should provide a good picture of the basics. It has additional links and a bibliography.
I am happy to answer further questions, just not so much on the early/raw research hypotheticals as those may not be in sync with eventual conclusions from empirical studies, as I'm sure you'd understand.
So this link: https://www.w3.org/WAI/GL/task-forces/silver/wiki/Visual_Contrast_of_Text_Subgroup has summaries of various aspects (much related to WCAG 3) and also has further links to more material.
I took the liberty to submit PR for a modest edit to the 2x Understanding that I think covers the first and second points.