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]