Technique G183 (and note 1 in F73) provide loophole resulting in inaccessible content (was: Technique G183 not applicable to touch/inputs that lack hover/focus)

[patrickhlauke]

Currently technique G183 https://www.w3.org/TR/WCAG20-TECHS/G183.html can be used as a "loophole" to stick with lower color contrast requirement for things like links in regular text, under the assumption that a user who has trouble discerning the 3:1 contrast can always set focus (with the keyboard) or hover (with the mouse) over the dubious item and get visual confirmation that it is indeed a link.

I would say the technique requires an additional note/warning that the technique itself cannot be relied upon for situations where a user may be using a touchscreen (or similar inputs that lack the concept of hover/focus).

Generally, touchscreens don't have a concept of "hover" (though there are a few experimental touchscreens that do recognise a non-touching/hovering finger, these are certainly not the norm - this also applies to stylus/pen type interfaces, which don't always sense a hovering stylus/pen). A user is either touching or not touching the screen. Additionally, while most browsers will react to a touch by then setting the focus (firing the focus event in JS, applying the :focus styles), this is done as part of the actual activation - i.e. the focus is applied, but the browser is already busy following the link (so either the user DID work out, despite the 3:1 ratio, that this was in fact a link, OR the user accidentally tapped it, NOT knowing it was a link, by which point it's already too later anyway as the link is being followed).

[patrickhlauke]

Prompted by the thread on WebAIM starting here: http://webaim.org/discussion/mail_message?id=31685
Further thoughts (well, the above) on the Mobile TF list: https://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2016Jul/0102.html

[yatil]

[w3c hat off – it is way to hot here anyway ;-)]

This technique relates to “1.4.1 Use of Color” which says

“1.4.1 Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)”

I think having to hover/focus to indicate that some text is an actionable element would itself need an indication of an action as per 1.4.1. I don’t think that we should allow developers to get away with guessing if an element might be interactive, especially for links inside text.

Also the SC itself is pretty absolute: “Color is not used as the only visual means”, there are no exceptions defined, and I don’t see why this non-normative technique should allow one.

Maybe there is historical context that I’m missing (please enlighten me!), but I can see that we (WCAG WG) might want to remove the technique.

[patrickhlauke]

I think the distinction/reason for this loophole is the general definition of "color" vs "using a different saturation/luminosity".

But I agree, on closer inspection (moving away from my fixated on the actual applicability to touchscreen), the entire premise of the technique seems rather shaky to me. You're either using color alone to distinguish things, or you don't...whether you then add extra non-color-specific styling or not when focusing/hovering doesn't detract from the fact that in the first instance, users who can't (easily or at all) perceive color will have difficulty working out what is or isn't a link or similar.

In that light, perhaps motion to obsolete this technique altogether?

[DavidMacDonald]

I believe G183 requires BOTH the link text AND the static text to have minimum 4.5:1 with the background... BUT 3:1 with each other.

[patrickhlauke]

sure, but fundamentally: this still effectively says that you're good to just use color as a differentiator between body text and link text, as long as you provide some additional ("redundant") visual cue on focus/hover. this seems ill-conceived/at odds with the idea behind 1.4.1

[DavidMacDonald]

I'd be fine with deleting it...

[yatil]

According to the techniques, the links in this example satisfy the success criterion… I don’t think that is the intent of the SC?

[DavidMacDonald]

The links would have to have a 3:1with the static text

[patrickhlauke]

And in @yatil's example, they do (links are #5A5A5A, body text is #000000, so a 3:1 contrast ratio between those). The fact that I opened that codepen example http://codepen.io/yatil/full/NAakoA/ and first thought Eric was trolling and that there weren't any links there speaks volumes to the fact that yup, this technique does nothing to actually help with solving the problem of the SC "providing the information conveyed with color through another visual means ensures users who cannot see color can still perceive the information" - this information cannot only be shown when the user is hovering/focusing, as at that point it's too late (unless we expect sighted mouse users to hover optimistically over every single bit of text in the hopes of finding an actual link, for instance)

This technique definitely needs to be deleted, in my view.

[DavidMacDonald]

Personally, I'm fine with that...

I should mention that there are a lot of organizations that have relied on it to meet wcag and not use underlines (arrows, brackets etc.) on links, so there might be push back, and could suck up a bunch of band width. It will delete an important negotiated what I would call an "exemption"... at the time some members said something like "well if you have sufficient contrast then you are not relying on color alone"

[patrickhlauke]

"if you have sufficient contrast then you are not relying on color alone" is a very warped view of what "color" is. it takes the "color is basically just the hue" approach, which is not what 1.4.1 actually says.

organizations that have relied on this have not worked in the interest of actually making their content accessible, i'd say...it's a bending of meaning/words to get away with something, IMO.

[jasonkiss]

I agree that G183 could do to go away, but I don't see how 1.4.1 actually says that color is or is not just hue. It just says "color", but doesn't normatively define it.

I suspect the vast majority of us interpret color rather simply, and that the more esoteric distinction between hue and lightness is a bit OTT for most. The only reason I've come to understand that distinction and how it informs G183 is because at some point I came across the non-normative Note 1 in F73 which expressly says that lightness is not color.

If G183 is disappeared, so should Note 1 in F73, I'd argue. This might help us all to start thinking of color in the context of 1.4.1 without the confusing distinction between hue and lightness generally (regardless of the fact that, strictly speaking, what we colloquially call "color contrast" remains luminosity contrast). More importantly, removing the Note 1 in F73 in addition to G183 would support calling links that are distinguished by color alone a failure of 1.4.1, even if they have a luminosity contrast of 3:1.

[patrickhlauke]

What I love about WCAG is that once you peel away one aspect that seems broken, you find 5 more bits that it's built on that also seem broken...

So F73 makes a distinction between hue and lightness. Leaving aside the fact that I would guess most people don't indeed make that distinction (and I'd guess that if you showed people two swatches, one fire engine red and one bright pink, they wouldn't say "it's the same color"), I wonder: what about saturation (if we use the classic HSL model)? This distinction seems already quite flawed (and it's enshrined in a non-normative note to a non-normative technique). Also, you can achieve a different color contrast by changing hue and saturation, not just lightness, so regular color contrast calculations wouldn't be enough to determine the 3:1 ratio...you'd have to also ensure that the hue (and saturation?) are the same, otherwise you're using a different color (in the restrictive "hue" sense).

Long story short: agree that F73's note 1 also needs to be chopped.

[Ryladog]

I am not 100% sure that this is broken. It may be related to some of the contrast algorithms or research done at Trace and elsewhere.

Don’t throw out the bathwater yet, let’s get some more feedback on where this came from……….:-)

[@yatil trimmed email footer of this comment to allow for more readability.]

[Ryladog]

The note on F73, if I remember correctly, was added at the same time as
G183, basically as the result of a consensus decision to allow contrast to
act as non-color way to distinguish links (G183). So yes the F73 note and
G183 are part of the same decision.

I was not part of the formulation of the G183 or F73 note, but I doubt SC
1.4.1 could have passed consensus without this "clarification" or
"exception" (depending on which side of the argument someone is on about
whether "lightness" is a color).

If I remember correctly, there was a well made argument, that lightness, at
least in some color models, is not a "color", and this provided a rational
to allow that which some stakeholders felt was a critical point, without
which they may not have consented to 1.4.1. It was a way out of a sticky
impass.

You gave dozens of helpful comments on the public working draft version of
WCAG, Patrick, http://tinyurl.com/jb3tp5n and all this was there for your
reading.

Consensus is a fragile thing, and I think it is the key to why WCAG has
been so well accepted.

In the 8 years since it's been out, we've never had, to my knowledge, a
complaint about link color from an end user.

The issue about keeping blocks of text free of visual artifacts
(underlines, arrows, link icons, etc.) is a very hot topic on the current
web and removing G183, F73 might shake up some important stakeholders who
rely on this to satisfy their usability people who say text is harder to
read with artifacts.

I'd suggest we punt this to the low vision task force to consider for 2.1,
unless we want to make a bold consensus decision to break a lot of sites
that use rely on these techniques.

Cheers,
David MacDonald
[AC: Trimmed past content]

[yatil]

[I think Github is getting confused by the email cross posting, is the comment above (that is currently attributed to @Ryladog yours, @DavidMacDonald?]

[patrickhlauke]

First of all, apologies for the slightly exasperated opening line in my last comment. Now, to address some of the points from @DavidMacDonald's (I'm assuming they're David's?) last comment.

I'd suggest we punt this to the low vision task force to consider for 2.1,
unless we want to make a bold consensus decision to break a lot of sites
that use rely on these techniques.

It was my understanding that at this point nothing can be changed in 2.0 (or am I wrong?), so of course my implicit understanding here was that my suggestion here is aimed at 2.1.

You gave dozens of helpful comments on the public working draft version of
WCAG, Patrick, http://tinyurl.com/jb3tp5n and all this was there for your
reading.

I do apologise that in reviewing the vast bulk of both the normative WCAG 2.0 and the various non-normative Understanding, How to meet and Techniques this bit slipped by me.

However, this in fact brings up what to me is a more fundamental problem: here we have two notes (which, at least in most other specs I worked on, are already treated as non-normative in themselves) in two techniques (which are part of the non-normative/informative material for WCAG 2.0) which in essence change the meaning/applicability of the normative SC - and I do feel that they're sneaking in an exception to 1.4.1 (since they redefine core concepts that 1.4.1 relies on). At the very least I would have expected an explanation of "what is meant by color" to be in the first-level informative documentation of "Understanding 1.4.1" https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-without-color.html - but here, that crucial bit is buried even deeper in techniques? This is possibly why I may have missed it at the time when reviewing WCAG 2.0 and sending comments...

If I remember correctly, there was a well made argument, that lightness, at
least in some color models, is not a "color", and this provided a rational
to allow that which some stakeholders felt was a critical point, without
which they may not have consented to 1.4.1. It was a way out of a sticky
impass.
[...]
Consensus is a fragile thing, and I think it is the key to why WCAG has
been so well accepted.

I can understand how this would have helped move beyond the impasse, but...are we saying, in good conscience, that @yatil's example http://codepen.io/yatil/full/NAakoA/ which is a PASS for 1.4.1 in light of this loophole, is really ok? If even a mouse user with good vision (me, and I would guess I'm not the only one) can't tell what is and isn't a link without having to manually move the mouse over each word/letter in an attempt to find a link in the haystack of text, I would say that's a very good case of the SC having been loosened (through this "clarification") to the point of being meaningless in real-world application.

The issue about keeping blocks of text free of visual artifacts
(underlines, arrows, link icons, etc.) is a very hot topic on the current
web and removing G183, F73 might shake up some important stakeholders who
rely on this to satisfy their usability people who say text is harder to
read with artifacts.

Would it also shake up the stakeholders and their usability people to know that links are harder / impossible to find for their users?

[awkawk]

I have been uncomfortable with this technique for a long time, and it seems to hinge on an acceptance that hue=color, and therefore lightness!=color. There is no definition of color in WCAG 2.0, which is partly the cause of the problem, at least in understanding the SC.

Here’s the most recent discussion on this:
http://www.w3.org/2013/03/07-wai-wcag-minutes.html (a banner meeting!)
https://www.w3.org/2002/09/wbs/35422/20130307misc/results#x2724 – the survey
https://www.w3.org/2006/02/lc-comments-tracker/35422/NOTE-WCAG20-TECHS-20120103/2724 – the original comment

The ultimate goal of the LVTF is that the appearance of all elements is user-configurable, but given that if that is realistic/possible it will be in Silver rather than 2.1, we should get their thoughts on what the intermediate step might be.

[DavidMacDonald]

@patrickhlauke I actually thought you meant delete it now... we have the authority to do that. I wanted to provide some context.

I think we all understand it would be imprudent to delete from WCAG2 ... I would support dropping the technique in WCAG 2.1, which would increase the WCAG 2.1 requirements and make anyone with inline links have to provide visual link artifacts. I'm gonna duck when that goes for public comment. But maybe it's worth it.

[patrickhlauke]

I'm gonna duck when that goes for public comment

I'll be ready with my asbestos trousers on...

[goetsu]

Hi, I don't agree that G183 must be deleted but I agree we need a note on it regarding hover effect on mobile that isn't possible.

G183 is here because if you use a color for link that have a certain color + luminosity that is different enough again text color, even with a color blindness you can still perceive a difference.
Hover / focus effect was added as a security for the edge cases like in the @yatil example

[fuzzbomb]

G183 is currently classed as a "sufficient" technique for SC 1.4.1. Can it be demoted to an "advisory" technique?

In Understanding Techniques for WCAG Success Criteria, one of the reasons for advisory techniques is:

in some circumstances they may not be applicable or practical, and may even decrease accessibility for some users while increasing it for others;

The issue of touch screens is pertinent here. In the 10 years since WCAG 2.0 became a recommendation, touch screens (without easy hover/focus) have become ubiquitous. Nowadays, desktop users (with a keyboard or mouse) can discover links by focus or hover, but smartphone users (with a finger) can't. That seems to match this reason for classing it as an advisory technique.

And who knows? This nugget from G183 may yet come to pass...

If assistive technology or Web browsers at some point all provide an option to underline all links on Web pages for users, this could be used instead of an author-provided link highlighting mechanism.

[yatil]

[W3C-hat off]

Considering that it is impossible to be compliant with WCAG when reading the technique literally (producing http://codepen.io/yatil/full/NAakoA/), I don’t think we can say it is advisory or sufficient. I think the Technique and its Examples violate the SC they are supposed to be demonstrating.

1.4.1 Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)

There are no exceptions. If there is an action, it must be indicated through means that are not color alone. It doesn’t say that a contrast ratio of 3:1 is sufficient to comply to the SC. Moreover, as the “luminosity of a color” is a property of the color, how can using luminosity be sufficient to conform to the SC?

Also, I find the advice confusing for implementors. “Do not use color alone” is a strong and unambiguous statement. “Don’t use color alone unless that color has a certain luminosity” muddies the water.

[mraccess77]

In my opinion there is only a very small number of colors that would allow text and links to have sufficient contrast to each other and also each have sufficient contrast with their common background. If someone did use that technique then it's not color but contrast that is distinguishing the links from text and that does not rely on color -- so it seems as acceptable as allowing bold or italics to be used visually. Since the focus state is already covered under SC 2.4.7 we are really only concerned with the non-focusable state.

[StommePoes]

There's also the thing where a pointer-using person is then apparently expected to carefully wave their pointer/mouse around bodies of text hoping to see the little hand to know that it's clickable. Oh but oops the developer put a click listener or (worse) cursor: pointer on the whole damn paragraph lol.

One could argue that forcing users to do a mouse-wavey thing to discover links (if 3:1 difference is still not sufficient for them to discern the links from plain text and they are a pointer user) specifically adversely affects people with several disabilities, no?

[patrickhlauke]

my understanding is that the "...but if it shows an underline on focus it's ok..." was done as a concession at the time to make sure vast swathes of the web wouldn't immediately be classed as failing. and many sites seem to still rely on this loophole. if the technique is changes/removed/demoted, will that cause a major outcry? (i mean personally i don't mind the outcry, as quite rightly the loophole does result in inaccessible content)

[detlevhfischer]

I agree that G183 (and note 1 in F73) should be scrapped (however, I am not quite clear about what it means "scrapping them for WCAG 2.1" -- if WCAG 2.0 Techniques remain valid, the same way as WCAG 2.0 SCs remain valid. Maybe I didn' pay attention or missed some telco where that was worked out).

[patrickhlauke]

@detlevhfischer yeah that's a concern here. I mean arguably techniques are informative, not normative...so even removing this technique does not alter the normative aspect of the SC. However, this blurs the line a bit as that informative technique was always used as a loophole/interpretation for the SC, so doing anything to it would, by the backdoor, alter the SC (or rather, the SC's applicability). @alastc @awkawk any thoughts?

[botic]

I see the problem with this loophole and it should be fixed in the future. But I strongly advocate allowing implementations like the following, where the intend of the subsequent link list is clear:

[patrickhlauke]

the general confusion/problem is that when you say "color" most normal humans will not immediately think "hue". and F73 by the backdoor redefines/defines "color" as meaning "hue", and then adds the additional clarification that if contrast is above 3:1 it counts as more than just a change in "color" as the change in lightness is above a certain threshold. and all of this is happening inside an informative technique, rather than normatively.

and then G183 builds on that escape clause specifically for links (but if the escape clause in F73 was sufficient, and contrast was above 3:1 so not just "color", why would there then need to be the addition of underlines on focus anyway? it's all a bit shakey...and again, all happening in informative/non-normative techniques)

[Myndex]

Just a footnote to this thread:

It is useful if not important to make a clear distinction between luminance, a measure of light, versus color as in hue and chroma.

Luminance is processed in the visual cortex separately from hue and chroma, and they have markedly different effects sensorily and cognitively depending on the perceptual context.

Luminance contrast is critical for details. Text, edge detection, these all require ample luminance contrast. However luminance differences are particularly poor for "coding" information. As a side note FAA standards limit luminance coding to three levels: black, mid grey, white.

Hue/Chroma contrast is nearly worthless for detail. It has a third the strength and a third the resolution of luminance, in fact in some combinations it can interfere with details like text. But hue/chroma is good for information coding. "Color coding" is ubiquitous.

Without getting further into the details, there is an important divide between understanding the use and functionality of luminance differences vs hue and chroma differences. For that reason they should be kept separate and referred to separately in SCs and guidelines.

[StommePoes]

When you're using a contrast-enhancement like WHC settings or using certain types of printers or screens, colour information is entirely stripped, and a 3:1, or a 4.5:1, or a whatever:1 difference is meaningless.

G183: Designers who are told they are failing the SC due to using colour alone to denote information visually can simply change the colour from one hex value to another and voilà! they are no longer relying on colour alone to denote information! Magic! [sparkle emoji]

[JAWS-test]

When you're using a contrast-enhancement like WHC settings or using certain types of printers or screens, colour information is entirely stripped, and a 3:1, or a 4.5:1, or a whatever:1 difference is meaningless.

That is correct, but SC 1.4.1 is not responsible for that. This is also true for the screen readers, which doesn't care about the contrasts either. But for all these cases there is SC 1.3.1, and SC 1.4.1 explicitly refers to it.

[patrickhlauke]

and 1.1.1 as well, at the most basic level. yes, they won't directly address WHC or similar, but those are not directly covered by WCAG in its current form anyway, i'd say (as they rely on user agents/OS' actually ignoring/changing what the author has specified as a styling - so unless you had an SC that says "must work even without any styling", it'd be tough to cater for)

[Myndex]

Hi Mallory @StommePoes and Patrick @patrickhlauke

The gist of my above comment is simply that luminance and hue/chroma (or saturation) should always remain separate in terms of standards definitions and user needs.

I'll wager 3:1 in skittles that you'll have a hard time seeing links in the first example below.

That said, a luminance difference of wcag 3:1 relative to a black text as a way to "code" the information that it's a link is barely perceptible even for the nearby text‚ in part because ratio math tends to over-state the ratio for very dark colors, but also because static luminance difference relative to a related and similar stimuli is very hard to perceive for a variety of reasons (contrast constancy is probably applicable)

What we are talking about here is something like #595a59 text next to #000 text on an #fff background.

Here is that specific example. Let's play find the links:

There are at least five links in that text, how long does it take to find them? If you are in dark mode, you'll probably find them faster than in regular bright BG mode. Regardless the link text is WCAG 3:1 contrast to the plain text, and it's clearly a terrible way to identify links. I know where they all are and I'm still having a hard time differentiating, oh but then I'm just an old guy with impaired vision... ...Oh wait....

Now look at this example:

These links are much more visible so as you might expect they fail WCAG 2.x.... The unvisited links are #03d and the visited links are #80a, both well under 3:1 yet far more visible... oh but it's color so it must be bad right? Not really, these are colors that CVD types see, because CVD types still see colors despite the undue burden of society labeling them as "color blind" (which by the way is a lie. And ableist. And if we could all stop using "color blind" and instead use "reduced color sight" or something that would be nice).

Here is how people with the most severe dichromatic CVD perceive these links:

Hmmm. The VAST majority of CVD types have NO PROBLEM (deutan/protan) differentiating the links from not links. Tritanopia has the most trouble but still easier than the 3:1 luminance version. And tritanopia is very rare (somewhere around 1 out of 35,000 people). Achromatopsia will have trouble with the links, but they also are extremely rare (1 in 100,000) and sadly they have a greater struggle with low vision and photophobia so they need AT no matter what.

Am I saying that 99.9998% of sighted people can distinguish these colored links better than the 3:1 luminance links?

Yes I Am.

Regarding system level contrast helpers: I don't know about WHC, but MacOS High Contrast does not impact the color link differentiation, and invert works as well.

What Does All This Mean

Mainly that the notion that color as in hue/chroma should be disregarded for informational use is too absolute. Those with CVD can still distinguish colors, but have a much more limited gamut. There are specific ways color (hue chroma saturation) can enhance accessibility, yet it is being disregarded in 1.4.1 and G183, and the promoted "fix" is anemic at best. As I stated in the survey, G183 is simply incorrect in multiple areas and could use a ground up rewrite.

Thank you for reading,

Andy

[patrickhlauke]

andrew, while these are all valid points, my point in general is that WCAG 2.0 and 2.1 have been normatively doing the "it's not 'use of color' if there a contrast ratio difference of 3:1" thing for ages, just not very explicitly. that has been the established definition for ages now, though it was hidden away. i've recently proposed changes to actually make this explicit. changing the more fundamental definition/understanding, and fixing the awkward SCs/techniques to have a different conclusion, is out of scope for current 2.x work, but certainly something that should be looked at more closely for 3.0

[StommePoes]

To me it sounds like 1.4.1 is pretty useless then, when it seemed initially geared for people who can see, but colour information does not reach them. The two places I've ever been hit with "visible information relies on colour so now you're screwed" has been WHC, and black and white printing.

1.1.1 almost never helps people who can see, since browsers don't expose alt text to anyone unless they're running text to speech, which the majority of us don't. And if 1.3.1 can deal with anything (and I agree it's really broad) then why keep 1.4.1 at all (looking ahead at future specs)? Why is there an SC specifically about colour (and then why does the Understanding go off-topic into things like Braille)?

[patrickhlauke]

why does the Understanding go off-topic into things like Braille

why indeed... #1500

[JAWS-test]

To me it sounds like 1.4.1 is pretty useless then

Despite all the errors in the understanding of 1.4.1, which hopefully will be fixed soon, I have always understood 1.4.1 to be about sighted people who cannot perceive colors or cannot perceive them as usual, but do not use AT. Therefore it is not useless. In EN 301 549 there is even a separate user group: "Usage without perception of colour" (WPC, Annex B, page 99)

[Myndex]

Hi Patrick @patrickhlauke Hi Mallory @StommePoes

Yes, I realize it's been there forever, and unfortunately is part of the several items that a "out of whack" for lack of a better phrase.

I am trying hard to not get "too" involved in WCAG 2.x SCs, because my focus is on bringing correct or best practices to WCAG 3, and this is one key area of my research as part of the total Visual Contrast for Readability and Accessibility.

I do however try to drop in information from the ongoing investigations — if it can not be reconciled with WCAG 2.x then at least for an indication of the direction the work is leading to. I "am" trying to think of ways that WCAG 2.x can "tip toe" toward perceptually correct standards.

A reason that we moved all of Visual Contrast to Silver is that it is a paradigm shift, and the concern is that is was too much of a shift to modify WCAG 2.x — the same is true for color (hue/chroma). In the examples above, I showed very specific colors that work, but the available colors are not intuitive, not related to any existing WCAG2.x math, and the color module has not been added to the APCA math yet, either, for a number of practical and developmental reasons.

Ans if you thought that luminance contrast was a big can of worms, hue/chroma/sat contrast is a barrel of monkeys drinking redbulls and vodka. Hue/sat is tied to luminance, and hue/chroma/sat can interfere with readability while improving discriminability — it is another conflict of best practices.

But an intermediate "tip toe" step could be to define a "CVD Safe" color set, with narrowly defined use cases, such as inline link text for 1.4.1, but again, I understand if that just is not doable within the WCAG 2.x paradigm.

So Why Am I Over Here Picking on Things?

I mention all of these things so we can all start to see a brighter future direction (see what I did there?), and I realize I may not be fully in sync with some of the 2.x changes, but if I can only get one thing across, it's the use of the term "Color Blind" and IMO one of the important "tip toe" steps is getting terminology right.

99.998% of those with CVD are not color blind. They only have a reduced color discrimination. Even the most profound deuteranope or protanope can still see hundreds of thousands of colors (far shy of the many millions of normal vision, but not devoid of color). Only the very rare achromatopsia is monochromatic, and that small group has other more serious vision problems that require AT.

• Instead of Color Blind, we need a new term that is not so completely incorrect and ableist. The medical terms for some disabilities are changed as often as every 30 years or so, It should not be too difficult to change colorblind. Some ideas here to float (work in progress):

  -Hue affected, short for hue affect disorder
  -Color Impaired, short for impaired color vision
  -Chroma deficient, short for chroma deficient perception
  -Hue limited, short for hue limited vision disorder
  -Color dark, short for diminished color vision
  -Chroma reduced, short for reduced chroma perception

Some things to think about that I hope add to the dialog...

Andy

[StommePoes]

A reason that we moved all of Visual Contrast to Silver is that it is a paradigm shift...

Yeah, that makes total sense.

99.998% of those with CVD are not color blind.

True, but I would hope neither 1.4.1 nor whatever new is coming down the line for 3/silver/whatever limits itself to CVD. I think I have full colour perception in general, yet 1.4.1 matters to me personally.

As a side note FAA standards limit luminance coding to three levels: black, mid grey, white.

I'm wondering if this can be helpful for the (in other tickets) somewhat related question of when the difference between, for example, a "filled star" vs an "empty star" (an example used on the 1.4.11 Understanding page) is considered a difference of "colour" vs "contrast". Because I don't go along with the technically-correct-but-impractical argument that it's "always contrast since black text on white is a contrast issue". Maybe it can become not a matter of WCAG contrast ratios but a simpler algorithm of "can this star be programmatically determined to be filled or not" (the "filled" being considered a non-colour visual indication). With only 3 levels, this should end up not only being simpler to separate contrast issues from other visual perception, but also working on a wider array of devices (COVID reeeeally brought out the black-and-white printed paper to my face these last months) and much less likely to leave a significant group of people out.

[bruce-usab]

I find the FAA note interesting. @Myndex can you provide the cite to that? That seems quite reasonable to me!

I will also confess that I am a fan of keeping some version of T183. How do folks feel about increasing the required contrast from 3:1 to 4.5:1?

FWIW, there exactly two shades of true grey that can provide 4.5:1 contrast against both black and white, 757575 and 767676.

[patrickhlauke]

How do folks feel about increasing the required contrast from 3:1 to 4.5:1?

that would change the normative requirement, no? [removed question about backwards compat, as it seems tightening requirements in newer ones is ok, it's going to other way around that won't work]

In general though, I'd say it's a bit late in the day to think about tightening requirements. my intent at this point was only to surface what has always been latently there since 2.0, just never made quite explicit enough.

[bruce-usab]

I very much agree that the allowance for using contrast has never been made quite explicit enough.

As to my asking about higher contrast: Mostly I am just trying to a get sense as to where the objections are coming from. I think it is a fair and reasonable technique. But I am now on the fence as to if 3:1 is enough of an ask. As @DavidMacDonald notes, there is also a requirement that text have a 4.5:1 contrast against its background. It may be the case that we settled on 3:1 so that the default blue (for links) were a pass.

@StommePoes — I am assuming WHC is Windows High Contrast. Please correct me if I got that wrong!

[StommePoes]

@bruce-usab Yes, WHC==Windows High Contrast, though I'm happy to let that stand in for the larger forced-colours idea in CSS which stems from it.

Mostly I am just trying to a get sense as to where the objections are coming from.

For one, both @yatil and @Myndex have posted some examples of technically-passing 3:1 contrast differences which, for people with zero visual impairments, are nearly impossible to determine links from non-links when inline with plain text. That's probably the main one.

The other is that while it seemed initially 1.4.1 wants authors to consider some other, non-colour-related visual representation of information when colour is used, the technique says simply a difference of contrast (rather than requiring an (additional) representation using thickness, shape, form, size, or adding visible text) is sufficient. Myndex makes a point that this CAN be sufficient for CVD users, however it leaves out those who have other reasons for not perceiving colours who generally are sighted. And maybe for WCAG 2.x that's just how it is. Hopefully 3/silver/whatever does something a bit different.

[Myndex]

Hi Bruce @bruce-usab

I will also confess that I am a fan of keeping some version of T183. How do folks feel about increasing the required contrast from 3:1 to 4.5:1?

I think part of what I am not getting across is the issue of identifying a link without impacting readability, which then is also considering the future compatibility with the work we are doing in Silver. This fails in both regards as it makes the text less readable, and is counter to the emerging Silver guidelines.

FWIW, there exactly two shades of true grey that can provide 4.5:1 contrast against both black and white, 757575 and 767676.

But also FWIW, that math is still wrong. Perceptual middle contrast is #aaa and not #777, and I have a live interactive demonstrator here:

https://www.myndex.com/SAPC/CommonBG_SAPC08

Move the large "background control" slider so that the black text and the white text is equally readable. Depending on ambient lighting and screen calibration, it should be close to #aaa, typically between #a0a0a0 and #b8b8b8 depending on polarity effects which are part of this series of experiments.

I find the FAA note interesting. @Myndex can you provide the cite to that? That seems quite reasonable to me!

Funny enough, discussed some FAA related guidelines in #675 last year, The FAA materials are largely referencing MilSpec and NASA research, and is fairly authoritative within their defined use cases.

I remembered it slightly differently, on review it is related to some older specs and ATC and not current flight deck specs:

In context, it is referring to a bright/dark pair of some color such as for enabled/disabled (think hover state). This idea should not be applied to black text on a white background as I demonstrated earlier. The psychophysical aspects relative to the high contrast needed for readability prevents this as an effective solution.

The most recent human factors book is stricter regarding color overall, probably due to the greater use of color EFIS, but also likely due to the Flight 1478 727 crash that was caused in part by one of the pilot's CVD and his misinterpretation of the glide slope PAPI and subsequent impact with terrain.

https://www.ntsb.gov/investigations/AccidentReports/Reports/AAR0402.pdf

Latest FAA Human Factors

Selected tidbits on color

For the flight deck, luminance coding or tint/shades of a color should not to be used FOR CODING per the latest flight deck human factors manual, which also limits the number of colors for color coding to six:

And other related FAA color:

Population incidence indicates deutan and protan are the primary concern:

Tritans are so rare it has been very difficult to find test subjects to even do research, so actual practical research is limited. But we are all tritan in our fovea, and elderly eyes yellow causing a loss of some blue response — the classical design guidelines regarding how blue should be used is helpful to all (blue on black is bad, pure blues on white are good).

Specific to WCAG 1.4.1:

Design for Mono and Bad Color Pairings

Cognitive/Discrimination

[Myndex]

Hi Mallory @StommePoes

True, but I would hope neither 1.4.1 nor whatever new is coming down the line for 3/silver/whatever limits itself to CVD. I think I have full colour perception in general, yet 1.4.1 matters to me personally.
AND
....however it leaves out those who have other reasons for not perceiving colours who generally are sighted....

The work we are doing is definitely not limited to CVD, and CVD is only one small part of the total puzzle. But you have me curious, which non-CVD color perception issues are you meaning here? Can you describe please?

I'm wondering if this can be helpful for the (in other tickets) somewhat related question of when the difference between, for example, a "filled star" vs an "empty star" (an example used on the 1.4.11 Understanding page) is considered a difference of "colour" vs "contrast". ....With only 3 levels, this should end up not only being simpler to separate contrast issues from other visual perception,...."

As I mentioned above to Bruce, I remembered the three level rule a bit differently, and it was an old standard and not part of the current human factors. Luminance coding should not be used (in general) I see a use case for "active/inactive" components to have a light/dark version of a color, but I'd see that as say, a bright green vs a dark green, and using colors in the middle of the luminance range, not "black text vs not quite as black text."

And I may have gotten off point as I tend to sometimes. The POINT is that luminance contrast and color (hue/chroma) are processed by different parts of the brain, and also serve different purposes. Luminance contrast is the key factor in edge detection, and resolving fine detail like fonts. But it is less useful for discrimination in terms of meaningful coding, and object recognition. Color as in hue/chroma however are very useful for coding meaning and object recognition.

Contrasts of size, shape, position, motion, state change are also good contrast types for coding certain types of meaning, nevertheless, all of these also can be affected by various impairments.

There is no one-size-fits-all in this area, and something helpful to one could be harmful to another. The ultimate solution is a better implementation of customization for all.

[Myndex]

Hi Patrick @patrickhlauke

...my intent at this point was only to surface what has always been latently there since 2.0, just never made quite explicit enough.

Yes sorry Patrick, I had never looked critically at G183 until this, and all this stuff jumped out at me which is why I brought it all up. Probably will just be fixed in Silver from the looks of what is needed.

Summary Comments

also to @StommePoes @bruce-usab

It is worth noting in an ironic sort of way that the CSS for at least some parts of W3's site technically fail here with links.

The unvisited links are essentially the same color as the surrounding text. There is an ultra thin underline made using bottom border, but the color is very light, coupled with the thinness is hard to see (certainly for me, young eye probably have no problem).

Then the visited links are blue, just like the common unvisited links. Visited blue links combined with the hard to see unvisited links is a cognitive failure for EVERYONE. If you expect unvisited links to be blue, and the only links you actually see are blue, then you will assume those are unvisited links, and may further not realize the actual non-visited links which are cleverly hidden.

Fortunately the hover-state helps to clarify, but hover states are not useful for touch screen use as noted.

Recap

Here's the upshot then I'm going to leave this alone:

• coding inline text links is a unique type of coding, and important as a core feature of the web.
  • It is a non-text coding for text itself.
  • because it exists directly on the text, it is constrained by the same limitations as those for text readability, meaning it needs to meet the same readability contrast.
  • other coding methods such as shape or size are not practical or interfere with readability, as can underlines, excessive bolding, or other style changes. Thus a balance is needed between identifying the link and not interfering with the readability of the text.
• Luminance coding in itself is ill advised and ineffective, in addition it interferes with readability contrast.
• Deutan and protan still distinguish many colors, such as blue vs yellow.
• design-wise for all users, pure blues should be the darkest color of a pair.
  • on a light or white background, pure blue text such as #00d is close to black, and does not hamper readability (in fact can reduce glare for some people by reducing the blue channel detail).
  • Blue #00d is far more distinct to 99.998% of sighted users than blue #069, but #00d fails the G183 luminance while #069 passes.
  • Blue #069 is only possibly, slightly more distinct to 0.002% of sighted users, while harming distinction to 99.998% of users.
• On a black of dark background with light text blue cannot or should not be used. But yellow can have the same usefulness.

And finally:

• Because of the uniqueness of an inline text link, the needs associated with readability require a balance with link identification.
  • of all the things that need distinction, inline link text in blocks of body text often call for the most minimally invasive approach.
  • excessive link identification in body text has a negative impact from a cognitive perspective by increasing the apparent chaos, distraction, and disorganization.
  • it is convenient to think of inline text links as the footnotes of our day, used to connect to the minutiae of supporting information without bogging down the reader needlessly. The fact a link exists is important, but not important enough to interfere with readability.
  • The fact an unvisited link exists is more important than indicating if that link has been visited. The case can be made that a visited link could be reduced in distinction to be helpful.

None of this is effectively addressed by G183, which may in fact be harmful in the manner it attempts to portray the issues.

Thank you all for reading and discussing this, if not for WCAG 2, this discussion is still useful for Silver development.

Andy

[alastc]

Not withstanding @Myndex's comments (which are more aimed at WCAG 3.0), I believe merging #1500 resolved this issue.