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 #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 #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 ***@***.***> 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 <#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 <#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 <#1118 (comment)>, 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.