Wcag: Delete Technique G183 (hover)

[guyhickling]

Could we delete Technique G183 from the WCAG Techniques, and delete references to it from the Understanding document for SC1.4.1 (Use of color)?

This technique requires a visual effect on hover over a link, in addition to the 3 to 1 colour contrast. It was created when mobile phones were in their infancy and were not used for web display. In an age where over a half of all internet access is now done from touch screen mobile phones and tablets, this technique promotes and encourages a solution that does not work for users of those devices, since touch users cannot hover over links. I.e. it is no longer accessibility supported by at least half the devices people use.

Failing deletion, could we at least deprecate its use by adding Notes at the top of the G183 Technique document, and in the references to it in the above Understanding document, to warn against its use and why? But deletion, I think, is the best course.

[JAWS-test]

See https://github.com/w3c/wcag/issues/201

[detlevhfischer]

good point, support deletion or deprecation

[mraccess77]

I do not think we should remove it. It does require > 3 to 1 contrast of link text from surrounding text AND at also indication on focus and hover. Thus, color (hue) is not be relying upon. We need a technique to guide people in solving this issue. WCAG does not require underline and > 3 to 1 contrast is a way that meet WCAG 2.x as written.

[patrickhlauke]

G183 introduced the "color is hue" redefinition by the backdoor. if this was truly the intention of 1.4.1 Use of Color, it should be defined normatively in WCAG's glossary and also referenced/mentioned in the understanding for 1.4.1. so, it retrospectively redefines this as "it's ok when it's not just hue that's used, as long as the contrast is high enough", and it does all this in non-normative/informative documentation, and not even in the understanding for 1.4.1 itself...

(see also the lengthy back and forth on https://github.com/w3c/wcag/issues/201)

[guyhickling]

Please note that this issue 1118 has not been raised due to colour contrast considerations (which is further problem). I raised it because the world has moved on since this technique was created. The "...providing additional visual cues" part of G183 can no longer be met on hover by more than half of the devices in use today (i.e. touch screen devices). And that proportion is increasing all the time as people use mobile devices more. We need to keep up with the current situation.

@mraccess So in my view G183 doesn't "guide people in solving this issue" because it isn't solved when half the audience cannot use hover.

I understand the point, raised in issue #201, about worries there might be pushback against deprecation from websites that have used this technique in the past. But we could say that about deprecation of anything. As long we go on encouraging the technique, developers will continue to use it. When 90% of computers are touch screen, W3C will still be promoting a technique that is irrelevant and misleading. Someone has to stop it, some time.

What happens in real life? Consultants and testers doing only a WCAG audit no doubt pass this technique. But consultants that do wider ranging "accessibility audits" include WCAG non-compliances and any other accessibility issues they find. They will fail links that rely on this technique. So this is not a new thing for developers. My own audit reports do this, and I have never received pushback from IT teams about it. But I would much prefer to be able to say "...and W3C deprecated this technique in 2020."

Patrick, thank you for mentioning the issue #201 you raised back in 2016, which I have now read through. As you rightly pointed out there, having a cue on hover is no good for people who can't distinguish the colours so won't realise there are any links to hover over! That is another good reason for deprecation or deletion. But I think that discussion then became somewhat sidetracked by the colour considerations so nothing was done.

In summary, this a question of, do we move with the rest of the world, or continue to promote an old-fashioned technique that no longer works?

[johnfoliot]

Guy writes:

In summary, this a question of, do we move with the rest of the world, or
continue to promote an old-fashioned technique that no longer works?

There is also the potential follow-up response that deletion may make
conformant sites today non-conformant tomorrow by OUR action, and not the
site owners, which is potentially a huge problem.

It's not so much that we're promoting this, but for more than a decade we
DID say it was an acceptable technique. We can back off of that with a
warning about the fact that at 2020 the experts have concluded that it is a
dated technique, and does not meet all the needs of all users in the
non-normative Techniques document, but I'm less inclined to just toss it
wholesale into the trash bin of time, at least at this point in time.

JF

On Tue, May 5, 2020 at 8:51 PM Guy Hickling [e-mail]
wrote:

Please note that this issue 1118 has not been raised due to colour
contrast considerations (which is further problem). I raised it because the
world has moved on since this technique was created. The "...providing
additional visual cues" part of G183 can no longer be met on hover by more
than half of the devices in use today (i.e. touch screen devices). And that
proportion is increasing all the time as people use mobile devices more. We
need to keep up with the current situation.

@mraccess So in my view G183 doesn't "guide people in solving this issue"
because it isn't solved when half the audience cannot use hover.

I understand the point, raised in issue #201
https://github.com/w3c/wcag/issues/201, about worries there might be
pushback against deprecation from websites that have used this technique in
the past. But we could say that about deprecation of anything. As long we
go on encouraging the technique, developers will continue to use it. When
90% of computers are touch screen, W3C will still be promoting a technique
that is irrelevant and misleading. Someone has to stop it, some time.

What happens in real life? Consultants and testers doing only a WCAG audit
no doubt pass this technique. But consultants that do wider ranging
"accessibility audits" include WCAG non-compliances and any other
accessibility issues they find. They will fail links that rely on this
technique. So this is not a new thing for developers. My own audit reports
do this, and I have never received pushback from IT teams about it. But I
would much prefer to be able to say "...and W3C deprecated this technique
in 2020."

Patrick, thank you for mentioning the issue #201
https://github.com/w3c/wcag/issues/201 you raised back in 2016, which I
have now read through. As you rightly pointed out there, having a cue on
hover is no good for people who can't distinguish the colours so won't
realise there are any links to hover over! That is another good reason for
deprecation or deletion. But I think that discussion then became somewhat
sidetracked by the colour considerations so nothing was done.

In summary, this a question of, do we move with the rest of the world, or
continue to promote an old-fashioned technique that no longer works?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/w3c/wcag/issues/1118#issuecomment-624402150, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJL4463GTJS734BFUCBDZLRQC7ARANCNFSM4MXN3OMQ
.

--
​John Foliot | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com
"I made this so long because I did not have time to make it shorter." -
Pascal

[guyhickling]

Thank you very much John, for your reply. However because the Techniques are non-normative, I don't think keeping or removing any one technique actually changes the state of conformance of a website. That is measured purely by whether the website passes the SC or not. It seems to me that any website using this technique already fails SC1.4.1 since it has relied purely on colour alone for the half of the user base that don't have hover ability, and failed to pass hover-triggered information to them!

It may help to consider when website owners will likely meet with this question. If given a website like that to audit, some consultants including myself fail it - but that's ok because if the owners have asked us to audit it, they are usually planning to fix the defects found. This particularly one then becomes just one fix among many. They don't worry about what caused the defects to be created in the past, or whether some change in technology made it non-compliant, they just go ahead and make all the changes asked for now because they want compliance now.

[mraccess77]

Given the 3:1 contrast of link text is all that is required to meet the requirement -- while the technique doesn't support people on mobile, following the technique does help people on PCs and mobile with the 3:1 -- it just helps PC users more on hover and focus and it allow you to pass the criterion. What additional things would you like to add to help mobile users with focus or hover? Both iOS and Android now support keyboard interfaces and mouse pointers although I would not expect users to have those available.

[patrickhlauke]

Given the 3:1 contrast of link text is all that is required to meet the requirement

...which is something the "use of color" SC normatively, or in the understanding at least, should really mention...

but also, we have good examples of where 3:1 contrast isn't actually all that visible and makes it almost impossible to detect by sight what is/isn't a link... https://codepen.io/yatil/full/NAakoA/

[guyhickling]

What additional things would you like to add to help mobile users with focus or hover?

@mraccess77 thank you for that. Without the hover ability, mobile and tablet users are effectively in the same position, as regards seeing links, as any desktop PC user who comes across a link that relies on colour alone. The standard Technique for that is G182, so logically the same solution would need to be applied. I.e. ".....a visual cue in addition to color for each place where color alone is used to convey information."

That most often means a structural cue, so it comes back to bold, underlines, italics or other font changes. Or, if the context obviously indicates the existence of links, that would be sufficient indication of links as well. For instance I would never fail an obvious main menu, sidebar menu or similar cases where things are obviously links because they didn't have a structural cue.

If we are going to allow colour contrast as the additional cue, I think it should be at least 4.5 to 1 between the link text and surrounding text. Dare I say, even suggest 7 to 1? - if that can be managed while keeping the 4.5 contrast between the link and plan text against page colour. Certainly 3 to 1 is much too low for people with very poor eyesight to distinguish which words are links in a body of text, as shown by Patrick's example just now. In the WCAG that ratio is usually used for such things as field borders where shape is also an indicator.)

[guyhickling]

@patrickhlauke - when you first showed that example, I looked through it and thought you'd made a mistake as there seemed to be no links at all. This second time round, now I realise there are many! It just goes to show how difficult it is to see them at 3 to 1 contrast!

[patrickhlauke]

(that example courtesy of @yatil )

[guyhickling]

Sorry, yes, @yatil 's example. It's a good one.

[mraccess77]

I don't disagree on the issue - I've pushed hard for an accordance criterion that does not rely solely on contrast in the WCAG 2.2 but it has been a complex topic and people have very strong opinions.

[yatil]

As reiterated several times: Either edit the SC to say “don’t use color alone unless there’s a 3:1 contrast ratio” or say “don’t use hue alone” or remove the Technique. The technique is (re)defining what color means just to make itself sufficient.

Clients and developers are regularly confused by it and having it provides nothing in terms of accessibility but a convenient loophole for people who want to do the least amount of accessibility.

In my personal opinion this technique should have never been published as sufficient because it muddies the water with having non-normative additions to the SC.

[patrickhlauke]

if i find the time, i'll make a PR that bubbles this up at the very least to the understanding doc...one level further up than hidden away in a single technique that all of a sudden redefines what the entire normative requirement is. it'll still be non-normative, of course...but can be argued to then at least make the "understanding/meaning" of what the AGWG meant (retrospectively) "color" means clearer...

[bruce-usab]

Thanks @patrickhlauke, it will be interesting to see which way this detail breaks. I get that sufficient contrast is not using color alone but it is not the least bit intuitive.

[JAWS-test]

I have already created PRs for the 3:1 exception at 1.4.1 some time ago: https://github.com/w3c/wcag/pull/1020/files and https://github.com/w3c/wcag/pull/1033/files

[patrickhlauke]

cross-referencing this PR https://github.com/w3c/wcag/pull/1500 which wants to pull the whole "3:1 ratio is more than use of color, as hue/lightness are different aspects" one level up from an in-passing note in F73 to the actual main understanding for 1.4.1

[erikkroes]

Is there a conclusion on this?

[patrickhlauke]

I think that if https://github.com/w3c/wcag/pull/1500 gets merged/accepted (and we make the "it has contrast ratio of 3:1 or greater" the official interpretation of what's required for conformance), then G183 can be kept but reworded to make it clear that the contrast ratio part is what's important, and then explain that the addition of a further visual cue (like the underline) on focus and hover is an extra nice-to-have, but not required (and that yes, the underline won't be of use in cases like touchscreen use).

this won't then overnight/retrospectively invalidate the approach (speaking to the concerns raised here by @johnfoliot https://github.com/w3c/wcag/issues/1118#issuecomment-624745884), since sites will that followed the technique's lead as an acceptable approach to pass use of color will still have the 3:1 ratio part, which will be the key conformance part, and they'll also have the underline, which is the "above and beyond but not required" part.

[alastc]

This general issue (color/hue/luminance, and G183) are up for survey this week. I think if PRs #1500 and #1553 are agreed this issue can be closed.

[alastc]

PR #1500 was merged, there is more discussion on #1553

[alastc]

Hi everyone,

The group met and discussed this technique today, the agreed response was:

---

The working group considered this issue and applied some updates in PRs #1500 and #1553 to clarify what passes the success criteria and what is needed for the technique.

---

I'll also add (myself) that, whilst everyone recognises that there are some very poor possibilities with links, this was a technique that overcame objections against 1.4.1 in WCAG 2.0. The concept of using contrast as an additional indicator is also necessary for non-text colour contrast.