Proposal for color and contrast (1.3.1, 1.4.1, 1.4.3., 1.4.6, 1.4.11) (WCAG 3.0) #901
Comments
HI @JAWS-test This is the primary focus of my current research, most of which is aimed at SILVER (i.e. WCAG 3). A key thread here that you did not list is issue #695 on Contrast which I opened in April. I've discussed much of these issues there, and also in the related closed thread #665 . There are some SCs under development for WCAG 2.2 that are intended to extend and address some of the issues, also intended to help provide some "stepping stones" toward the more comprehensive visual standards in current development for Silver. One that you hit upon, that you are mentioning as "line width" is related to the psychophysical function of CONTRAST SENSITIVITY, and how it is directly affected by SPATIAL FREQUENCY. However, it is wrong to conclude that it is only stroke width or weight that affect legibility. The fact is that human visual perception is complex and the issues of perceptual contrast are very interdependent between color values (luminance contrast), stimulus size (visual angle), stimulus "weight" (CSF/Spatial Frequency), light adaptation, local adaption/surround/simultaneous contrast, etc. And THEN the many forms of visual impairments all present different (and sometimes conflicting) needs and methods to address. There is no "one size fits all" in terms of standards — what one impairment needs for accommodation may interfere with another. > Unfortunately, I am not an expert in visual perception. As it happens, human perception is a primary area of my expertise as discussed elsewhere. This is also my primary research task here, and we are having some exciting breakthroughs. The new methods and understandings being created for Silver are both more flexible for designers, and more robust in accurately predicting human perception and impairment needs. I can't respond to your entire post/issue line by line right now, but I can tell you that the issues you've raised are being comprehensively addressed, including some new original research that is ongoing. I've written about much of this already here and elsewhere-— while I have some items on my ResearchGate account, several of the experiments and discussion can be seen in this repository on one of my sites. Take a look at #695 and some of the more recent experiments, and feel free to ask any questions you may have. I've been so very busy on the Silver Task Force I have not had much time to post updates here on GitHub, but the work is ongoing and in depth. Most of the new research is targeted at Silver, but as I mentioned there are a few SC extensions under development for WCAG 2.2 that will indicate a pathway forward. You are correct that many things are better targeted at Silver (i.e. 3.0), as Silver is a new paradigm in standards and standards development. Nevertheless the new research that indicates testable methods appropriate for WCAG 2.2 is making its way into SCs, such as those relating to CSF and spatial frequency (relating to methods involving thin fonts and body text for example). Regards, Andrew Somers |
I wonder if comment (within the SCs or Understandings) make sense for this one: I have seen quite regularly that logotypes are used on buttons. A popular example is PayPal. A button users are meant to click to take them to PayPal to make a payment on an e-commerce site often has awful contrast when the logo's blue colours are set against the e-commerce platform's own colours (orange is popular. So is purple). When making tickets for these, I've had to file them under "UX problem: button text is practically invisible to users with poor contrast vision" because WCAG cannot reference it due to the logo exception (which likely did not think about logotypes being used on controls other than "back to Home" links, although that's also sometimes an issue). I can offer easy solutions to the clients though: most logos have variations used for black and white printing (letterhead stuff) where a single colour of sufficient contrast can both be recognised by people familiar with the logo while now allowing the contrast to be set by the developer. And for those logos which do not have a unique silhouette, forcing the addition of a contrasty-enough background to just the logo part-- the rest of the control can still follow the e-commerce branding colours. We recommend this for multi-colour SVG icons anyways, so they remain highly contrasted even in Windows High Contrast. |
|
probably a bit of an aside thought, but: @StommePoes every exception will, at some point, be used or abused. personally, I'd say WCAG can't cover every possible permutation of content/usage/design in the wild, and it becomes a sisyphean task trying to make a laundry list of all possible situations. this feels more like "i want to fail this but can't, and the client won't do it unless it's a clear fail", which is probably more of a problem of how the client sees WCAG (as in trying to "pass" it, rather than using it as guidance/minimum baseline). |
|
@StommePoes
But I think that the logos can already be weighted as a violation of WCAG 1.4.11. There is even a good example in the Understanding (https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html), Figure 14 and Figure 15. Either the logos are designed to be rich in contrast or provided with a text subline. |
|
@JAWS-test i admire your cavalier attitude towards logos, but will note that designers/developers are not allowed to just randomly modify corporate identity of their own nor any 3rd party. so NOT having an exclusion (or just saying it only applies to 3rd parties) is unrealistic. |
|
@patrickhlauke: The logo exception does not exist for 1.4.11. There is even an explicit example in the Understand with logos, which is marked as Fail. Thus it is not my opinion, but that of the WCAG. |
https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html |
|
The logo exception is neither in the normative SC nor in the definition of "essential". It only stands in the non-normative Understanding and is therefore worthless for me, because in my country the WCAG is the law, but not the Understanding documents.
and because it contradicts the example in Figure 14 and 15. I will create an issue on this. If one does not want to change one's logo, the exception "Alternative presentation: If there is an alternative presentation on the page that meets all requirements, then there is no contrast requirement." can be used. This would mean, for example, for a linked logo that the link contains logo and visible text alternative. |
|
@Myndex
In this respect, I think that many of your remarks overshoot the mark. My attempt was to unify the existing criteria for contrast and color and otherwise change them only slightly because they have proven themselves in the past. Instead of taking too many values into account, WCAG's approach should be to demand a high contrast value in general, which then works well in many circumstances. What makes sense in any case would be to improve the contrast formula if the current one does not work correctly. This wouldn't affect the test either, the only important thing would be that all testers use up-to-date tools that implement the new formula. If the 2px threshold does not make sense, I am more in favour of not using a threshold at all than too many or a threshold that is complicated to determine. Note that 1.4.11 does not have a threshold value. I noticed that under 2px bad contrasts are even worse. Above 2px I did not notice any differences, no matter how wide the font or line or icon is. |
|
figure 14 and 15 are infographics that already bastardise the respective logos. they do not conform to the corporate id requirements of the respective companies they depict. you would not be able to do this / make up your own visual interpretation of another company's (or even your own company's) logo in most circumstances. and the colors of a particular logo are essential, since they're the branding for that particular company. if you changed them yourself, you'd be fundamentally changing the nature of those logos. |
That's not a doubt. However, 1.4.3 and 1.4.11 are only about sufficient contrasts. It is clear that certain users have different requirements, therefore there are several other SCs like 1.4.1, 1.4.4, 1.4.5, 1.4.8, 1.4.12 etc. And that's why I think it's so important to support High Contrast Mode better in WCAG (#623). In any case, I am looking forward to the improvements that will hopefully come with WCAG 3.0 and with your support. |
Hi @JAWS-test And to be clear, thread #695 ended when I joined W3C/WAI/STF/LVTF, and I am more active in the phone conferences, WAI mailing lists, and the most relevant discoveries are listed in my research repositories on Myndex.com and ResearchGate. I'm less involved here mainly as I am now completely buried in new research for what is a very complicated subject — not to mention becoming directly involved in Silver which is a ground-up approach to a new paradigm for accessibility standards. As for #695, my first several posts were indeed very broad. Later posts in #695 and #665 clarify a number of issues, and indicate some of the state of research.
The work we are doing in Silver is unifying the interrelated aspects of visual perception.
Not really, there are present issues in terms of false passes and false fails. Here is a resent assessment using 200 random color pairs, compared to newer methods that are weighted using more recent research of human perception:
No, this is an inaccurate assumption and unsupported by research. Among other things excessive contrast is problematic for many impairment types. And "just brute force" shoving contrast higher is not addressing the issues.
It is not "just" the formula — to be sure, there are issues with the exiting math & lack of accurate modeling of the "curved nature" of human perception — that is what brought this to my attention as a research project. But the last 6 months of my research, which incorporates the last 10 years of advancements in the field of Image Assessment Modeling (some of which was unknown at the time of the WCAG 2.x standard) shows that there are many factors affecting perceptual contrast that need to be unified as they are inseparable from simple luminance ratios.
Line width/line weight is affected by a couple factors. One is the basic CSF and spatial frequency, but the other is related to various rendering engines and the use of antialiasing — antialiasing of diagonal and curved lines in particular reduces perceived contrast due to assimilation/blending with the background. 1px lines fall prey here the most, 2px and wider starts to avoid the antialiasing for the "core" of the line. But this is separate from the spatial frequency dependent CSF. To help get on the same page, here's a quick (and rough) example of spatial frequency and contrast perception:
The body text lower right is at the SAME COLOR as the text "Large Headline," yet the body text is essentially unreadable. So, an example problem that has manifested in the last few years since WCAG 2.x is that designers are using the "4.5:1" contrast standard on very small, very thin fonts, but as several of the experimental results I've posted elsewhere show that body text of thin fonts needs much higher contrast even for NORMAL vision, not to mention various forms of impairment. But it is also impractical and inappropriate to demand that designers use only pure black and pure white — no only will designers refuse to do so, but such high contrast becomes problematic for many impairments types. |
That is correct, but 1.4.3 and 1.4.11 require only a minimum contrast and no maximum contrast. 1.4.3 and 1.4.11 are not relevant for people who cannot see high contrasts well. They rely on being able to adjust the colours. There should be a better SC for that. Nevertheless, I think WCAG needs a criterion for high minimum contrasts rather than a very sophisticated one for minimum contrasts. |
The starting point of my proposal (without knowing the discussion so far) was:
This led me to the following consideration:
Of course, I could have considered many more criteria and named some (e.g. contrast differences of distant foreground colors are more difficult to detect if the distance to the background color increases), but I wanted to keep the SC and the testability of the SC as simple as possible |
|
HI @JAWS-test
And not actually true and/or not relevant. The point of functional needs is not about contrasts, but about legibility and readability. There is a definite difference between lines vs icons/letters in this regard.
Also not necessarily true, and/or very context dependent, but again most especially IMPAIRMENT TYPE dependent. The variety of impairments is far wider than your comments seem to be focused on.
This is one of the things you've stated that has made it a little difficult to follow what you are saying — what do you mean by this? What do you mean by "distant foreground colors"? What do you mean by "distance to the background color increases"?? Spatial 2D? Spatial 3D? Euclidian distance in a colorspace? And again, as you clarify the statements you've posted you seem to be very caught up in the concept of "contrast." Contrast is simply a "testable method" — what is actually important is the "functional need". So in an effort help you, below is a work in progress of a functional needs outline. It is not complete, but part of ongoing work — needs are what drives the "methods", not the other way around. Contrast between a font and the background is a method, not a "need". A BRIEF ENCAPSULATION OF USER VISUAL NEEDS:Visual Acuity deficits:Acuity is essentially the ability to resolve a stimuli in the eye and perceive it in focus. “Blurryness” is the plain language way to describe poor acuity.
Contrast Sensitivity deficits:Contrast Sensitivity Function (CSF) can be impacted by poor acuity, by retinal disease such as AMD, retinal migrains, by degraded ocular media (cataract, etc), and by neurological problems (MS, neuropathy). VERY ROUGH (to be written):
Visual Field deficits:Closely related/essentially part of contrast sensitivity impairments are those relating to visual field.
Color Vision deficits:Color Vision Deficiency (protan, deutan, tritan CVD types) is primarily helped by ensuring there is enough luminance contrast between items (i.e. between text and a background, or between roadways on a map and geographic features on the map).
Cognitive/Neurological related Visual Deficits:62% of the brain is involved in visual processing. Over 20% of the brain is dedicated to visual processing, and of 42% processes visual in conjunction with other senses such as auditory and tactile.
In ClosingSome of things you mention in your initial issue are fairly well understood, and in fact making their way into either SC extensions for 2.2, or new standards and guidelines for Silver. (One example is font weight, as those proposed SCs are already being created). However, you make statements that are not supported by research, your codepen notwithstanding. Visual perception is not binary logic, so "absolute" statements don't really fly in a field where there are no absolutes. Human perception is far more complex than can be determined by some examples at maximum contrast. I have listed references and footnotes to authoritative research supporting most of my posts in #695 and elsewhere, and I do suggest reading through those references to gain a better understanding of the underlying concepts. In particular you might want to read Legge's book Psychophysics of Vision. And please keep in mind these standards are ultimately about the functional needs of a very wide swath of users & impairments. It is needs that should be considered, not so much the abstraction layer methods. Regards, Andy Andrew Somers |
I don't agree with you. 1.4.3 and 1.4.11 deal only with contrast (as a way to improve legibility and visibility), but not with legibility or visibility itself. There are many other SCs that I have already mentioned. For a good readability there is also Guidline 3.1 (https://www.w3.org/TR/WCAG21/#readable). |
I am not focused on this at all, I have only tried to make a proposal for 1.4.3 and 1.4.11. And since 1.4.3 and 1.4.11 are about sufficient contrasts and 1.4.3 about sufficient contrasts depending on font size and weight, I have made a proposal that takes this into account. My concern was not to completely revise WCAG to meet all the needs of visually impaired users. As I said, there are other SCs for this - and hopefully also new SCs in the future. |
I mean something very simple: 1.4.1 prohibits the use of colour as the only visual means of conveying information. The exception, however, is that colours may be used if their contrast is 3:1 or greater (see https://www.w3.org/WAI/WCAG21/Techniques/general/G183). To check whether 3:1 is sufficient, I have installed two sliders on the https://codepen.io/jaws-test/pen/VwZBGWJ page to set different foreground colors. Imagine, one color defines the color of text and the other color the color of links. At what contrast can link and text be distinguished from each other? My tests have shown that with the same contrast ratio between links and text, the difference is easier to see if the background color has a lower contrast to text and link. And my conclusion was
|
|
@Myndex
This is not true for me, but it is also not true for many visually impaired users. This depends on the type of visual impairment, e.g. the colour vision defect. That brings us back to my main point:
|
|
What you posted in the section "A LETTER ENCAPSULATION OF USER VISUAL NEEDS" is interesting and should be considered by WCAG as far as possible. Many of them were already known to me. However, most of it does not concern the perception of contrasts according to 1.4.3 and 1.4.11 and is therefore irrelevant for the current discussion. |
I was speaking more about the work being done in Silver (functional needs) regardless, I think you are misinterpreting the manner/structure of the current WCAG 2.x format for standards. And Silver will be very different, but is under development.
As mentioned there are some being authored right now that address small and thin fonts for instance, and are being structured in part as stepping stones toward Silver, but also to bring some of the most recent and helpful research into WCAG 2.2 so that it can be adopted by authors sooner.
In this context, color means HUE. Prohibiting HUE as the "sole" means of information is correct and well understood in the professional design community. The saying is "make it right in black and white" meaning that general design choices should work in a greyscale context. This goes back to classical design theory, and was an understood concept well before desktop publishing and Web based content.
No, that is NOT the only exception, that is only ONE of multiple exceptions for how to convey information not by HUE.
What is your monitor gamma, what brand and type of monitor, what calibration method was used, what is your ambient LUX, what is your test environment, what is your criteria for evaluation, etc...? Not sure quite what you mean here, I think you are using the term "background contrast" to mean background luminance. It is known that a dark background with light text has a higher apparent contrast than dark text on a light background. These differences in contrast polarity are not modeled by the present math method. I am already on record about how the current math method does not model human perception accurately, and that is undoubtedly part of what you are seeing here. Using WCAG math for determining some contrasts will lead to false passes (and false fails) as is already documented. The equations that fix this are already written and being evaluated for Silver. But changing the equations means changes to the standards values themselves, and that is a non-starter for WCAG 2.2 — it is not going to happen, it needs to happen in Silver for a variety of reasons discussed elsewhere and later in this post. I have already provided links to threads and repositories that describe much of the current gestalt here.
You're missing a lot of what has been discussed in these areas and on these topics, and I think you are missing a key structural element of the WCAG 2.x — part of which is defining a "parity" between normal vision and a certain group of impaired vision types. If you read it fully, 1.4.1 does not require that links have 3:1 contrast to surrounding text, UNLESS there is a hue aspect that is perceived by normal but not impaired vision, AND that is the only differentiating factor. BUT IN FACT 1.4.1 clearly states that is not the only way to address the issue — underlining the link as an example is one of the ways to meet this SC.
I have already stated that MUCH of what was written in the first few posts of #695 has led to much more comprehensive research. The first post was an initial observation, but later posts, and more importantly the (presently unpublished) research is finding differing conclusions, and I indicated as such. I've also provided links to some of the more recent experiments and observations, which provide pre-published discussion.
Yes, I agree in general, though probably for different reasons than you have indicated.
No, the nature of perception is sufficiently complex that such a panacea of brute force will do more harm than good, this also has been discussed, and the current math and standards are based on some brute-forcing of their own. Just shoving contrast "higher overall" is not a valid solution by any stretch. TRANSLATIONS
AHHHH!!!! I JUST REALIZED that you are using a TRANSLATOR and that English is not your first language. (Hint: it translated the title of "needs" wrong). Knowing this is very helpful, because I've felt we are partly battling semantics (and I loath semantic arguments), and the reasons for your unusual use of wording (which is hard to parse here, BTW) now makes a bit more sense, I now better understand why your posts are so difficult to understand.
No, considering functional need is not irrelevant when you are promoting a standards change. Nevertheless, I am speaking more for Silver. Knowing that this conversation is not fully understood due to translator issues points to a cause of some misunderstandings. CONTRAST IS NOT AN ISLANDAgain, I have pointed out that CONTRAST is affected by many factors and NOT JUST the color components. The other factors are inseparable. However, there is currently more isolation in the WCAG 2.x than I anticipate for Silver. As it has already been discussed that 2.2 is not appropriate for such major changes to existing SCs, they were moved to Silver. On the otherhand extensions to the existing can illuminate a path forward.. I.e. the equation/methods/values of existing contrast SCs are not going to change dramatically for 2.2 (backwards compatibility is one key reason). But there can be EXTENSIONS (NEW SCs) to address some issues leading a path toward Silver. The "major" changes are being evaluated for Silver. This has a lot to do with the structure of the documents, scope, workflow, the charter, etc. etc. I mention this because I think it would be useful for you to read more about what can or cannot be changed in the various SCs, how the change and pull request process works here, etc. There are multiple working groups and over a hundred people directly involved in managing and handling these standards. And there is a process, which I have attempted to indicate, and which is detailed in the charter docs etc.. Some of your comments are lacking foundation and seem due to misunderstanding the actual document(s). Some of your comments that do have merit are indeed understood, being investigated, or are part of the current work. And as always it is useful to have alternate perspectives. I also encourage you to read the complete WCAG and understanding documents. Regards, Andy |
There have been many discussions here about contrasts, which I do not think have led to a satisfactory outcome (https://github.com/w3c/wcag/issues?q=is%3Aissue+1.4.11). I am afraid that the problems with WCAG 2.1 and 2.2 cannot be solved because the SCs are unchangeable and the "Understanding" documents cannot give the SCs any other meaning. But I think that for WCAG 3.0 a thorough revision of the color and contrast themes would be useful.
Unfortunately, I am not an expert in visual perception. However, I suspect that the following is correct:
Therefore I suggest the following:
Changed SCs, new SC
Logotypes: Text and graphical objects that are part of a logo or brand name has no contrast requirement.Logotypes: Text and graphical objects that are part of a logo or brand name has no contrast requirement.Logotypes: Text and graphical objects that are part of a logo or brand name has no contrast requirement.Logotypes: Text and graphical objects that are part of a logo or brand name has no contrast requirement.Note for 1.4.1, 1.4.3, 1.4.6, 1.4.11:
Note for 1.4.3 and 1.4.6:
Understanding
1.3.1 also applies to users who adapt color and contrasts (user styles, adaptation of colours in the browser, high contrast mode etc.). This means that the following must be fulfilled for information transmitted via color or contrast:
1.4.1 applies only to colors that transmit information as a specific color and are therefore not interchangeable (e.g. red = error, green = success). If the color is interchangeable with any other color, 1.4.1 is not applicable. Then only the contrast requirements from 1.4.3, 1.4.6, 1.4.11, 1.4.14 apply.
1.4.3, 1.4.6
1.4.3, 1.4.6, 1.4.11, 1.4.14 applies with User Interface Components for example for:
Open questions
At level AAA, the exceptions for logotypes could possibly be omittedRelevant in this context
The text was updated successfully, but these errors were encountered: