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]

@botic that is still perfectly valid (my justification here would be that color is not the only visual indication, as it's clear from context that these are actionable items/links...though admittedly even that is a - non-normative - interpretation, and one that i don't think is even explicitly present in the understanding docs currently)

[alastc]

We have fairly baked-in the use of luminosity-based contrast as a visual indicator, from understanding non-text contrast:

"The Use of Color success criteria addresses changing only the color of an object (or text) without otherwise altering the object's form. If a controls indicator of state (e.g. button background) varies only by color this is acceptable if the luminosity contrast ratio between the colors of the states differ by at least 3:1, or if there is another indicator of state. For example, a text link that only differs from adjacent text using color and there is no other visual indication that the text is linked (e.g. the link underline is removed) needs to ensure that the link color meets the 3:1 luminosity contrast ratio relative to the non-linked text color in order to meet the related Success Criteria 1.4.1. "

It makes the non-text contrast SC more feasible, otherwise some visually-obvious indicators would fail (this was tested/discussed with the LVTF & AGWG towards the end of the 2.1 publication).

I think a revision of the content due to touch-screen usage is warranted, but the range of colours that work 3 ways is pretty narrow, is it a loophole people try to use?

[patrickhlauke]

the technique is a loophole that's used for justification, mostly (curiously, had a discussion about this very topic with a client the other day, where in the end i conceded that yes, they're following the letter of the non-normative advice here, but it's still a lousy experience for users). "it's fine that visually it's hard to see what's a link and what isn't, because i set underline on focus and that's kosher". yes, it's fine when things actually take focus, but when they're not in focus, it makes it impossible to work out what is static and what is linked text.

[mraccess77]

I agree it's a loophole and something that's a problem for users. It would be great to get consensus on it.

It's not clear that WCAG 2.1 changes this because the new SC 1.4.11 seems to focus on the contrast of a content in a state and a component and not between adjacent controls with different states or adjacent components. I would flag 1.4.11 if there was not sufficient contrast between a selected tab contrast and non-selected tab contrast in the same tab strip if there was no other signifying non-contrast identifier -- but I'm not sure how far we would take this. to apply to links Ultimately I would like to see an SC that required visual indication of interaction without having to use the mouse or keyboard -- but I'm not sure we arrived at such a criteria yet as a group.

[mraccess77]

I'd agree with others that for links that are part of a paragraph of text the contrast is the discussion point -- when links are not part of surrounding text such as in a list or in a nav menu there are other contextual clues that point them as interactive and this is less of a user issue. Also it's not the contrast that is being used to communicate a difference -- because there is nothing to compare that with. Within a paragraph of text it's often the contrast that is the only thing to differentiate.

[goetsu]

Maybe the solution would be to delete G183 and keep the note 1 in F73. It will reduce the visibility of this loophole while maintaining conformance for those who use the loophole to conform

[yatil]

[w3c-hat remains="off"]

Again, this is not a loophole in WCAG. The technique violates WCAG in both G183 and F73 for both, WCAG 2.0 and 2.1 (because the SC didn’t change). 1.4.1 says “Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.”

A link indicates an action. Changing only the color, even if it results in a contrast change, is still using color alone to indicate the link. It would be something different if the SC said: “Hue is not used as the only visual means of…”. But the SC does not make the distinction. There also is no exception defined in the SC itself. When WCAG talks about color, it always means all aspects of color. When WCAG mentions lightness contrast, the word “color” is strictly avoided, for example in 1.4.3 Contrast (Minimum) does not mention color.

And to be the pedantic German that I can be if I need to, the issue is in the title of G183 itself: “G183: Using a contrast ratio of 3:1 with surrounding text and providing additional visual cues on focus for links or controls where color alone is used to identify them” – The title admits that color alone is used, which is forbidden by 1.4.1. It is Schrödinger’s technique. Color alone is used to identify links and something else, a property of color, is used to distinguish links from body text.

As the techniques are examples of how to implement WCAG, G183 does only do that if you have an undocumented and non-normative understanding of what “color” means. That ambiguity makes it harder to test, teach and convey accessibility. Are there other things in other SCs that can be interpreted similarly, incorporating a non-native definition of a term, to make them less effective? 1.4.1 is one of the shortest, clearest, easy to convey SCs that we have. Finding contradictory “techniques” in the resources for that particular SC from a place of authority is confusing.

There are two ways to solve this conundrum: Align the techniques with WCAG as is written (which would, in this case, mean to remove or significantly alter them) or explicitly spell out the exception in WCAG 2.0 and 2.1. I don’t think there is a lot of value in discussing different interpretations of the word color as long as WCAG does not normatively define color as only referring to hue.

[alastc]

[Chair hat on.]

Digging into the background @awkawk provided, the group agreement from the WCAG 2.0 time was:

because G183 requires a relative luminance (lightness) difference of 3:1 or greater with the text around it, the link is visually identifiable by its contrast with the surrounding text, not by its color( hue) difference. This is similar to SC 1.4.3, which requires a minimum contrast ratio between text and its background. And when this technique is used with links, the link hue is often the same as the surrounding text, only darker.

However, since this technique applies only to links and other interactive controls, the working group felt that additional feedback would be helpful to confirm that the contrasting text is interactive, but that is was acceptable for this additional feedback to be provided only on focus or hover.

This technique is an edge case for what the working group felt was acceptable for text

So it does rely on the difference between hue & color, even if that isn't normatively explained.

I think a key change since then (that Patrick raised earlier) was that the previous agreement assumed pointer & focus styles help, which is not the case anymore for touch devices.

So assuming the group wants to change this I can see two routes:

1. Stop using the difference between hue & luminance in 'use of color'. Remove G183, look for other techniques which might need updating (e.g. remove the note in F73). This would apply to WCAG 2.0 & 2.1, and would probably be seen as changing what conformance means for current & historic sites.

2. Make a point with 'accessibility supported' that many devies now do not have pointer/focus styles to fall back on, so G183 only applies where touch devices are not supported. A more gradual retirement path.

Any other options?

[patrickhlauke]

FWIW, some quick thoughts:

1. I would argue that in common parlance/understanding, people don't necessarily make a hard distinction between hue and luminance when saying that two things are of a different colour. It almost feels more like a pedantic gotcha ("ah, you said they're a different colour, but in fact their hue is the same, but one is just lighter than the other")
2. The boundaries between input methods are increasingly blurry, but most developers still don't realise/think about that. I still encounter many devs who think "touch" is the exclusive domain of mobiles and tablets, ignoring the fact that there's a large class of touch-enabled laptop devices / 2-in-1s, and even desktop touchscreens. Also, the inverse is true: you can pair a mouse with a mobile/tablet, or your mobile device may have some form of joystick/thumbstick type input...all of a sudden, the SC would argubaly NOT fail in those situations.

In short, I think a clean break would be best. Maybe, as more of a transition, is there a way to mark a technique as deprecated, with a clear warning and rationale at the top? (and listing it in the SC's understanding/how to meet as such)

[mraccess77]

I mentioned it on the call - but I'll add it here -- when I think about color and luminance I ask myself the following: If a the page was put into grayscale do I have the information I need? In grayscale what is the difference I see between the two elements I am comparing.

For color alone I would not be able to make the determination in grayscale. With something that relies on difference in luminance I would still be able to tell that difference in grayscale. Put another way -- if you were to print this off on a black/white grayscale printer -- would you have the information you need? People do seem to understand this concept because people are more familiar with a print out. This takes away the complexities of telling people that green and red can have the same luminance or different luminance depending on saturation and hue color qualities which complicates the topic.

[yatil]

@mraccess77 I am almost unable to make the determination in grayscale in this example (which uses gray colors according to G183) and I have 20/20 vision, with glasses: http://codepen.io/yatil/full/NAakoA/

If I remove my glasses I’m unable to determine any links. I can squint to read the text (barely) but I would need to hunt for links using the mouse.

[mraccess77]

@yatil I agree this combination of 5a5a5a and 000000 has a 3:1 ratio but is almost unnoticeable. It's my feeling though that this combination is one of the edge cases where the luminosity algorithm is not perfect in catching. That is I have seen some combinations that have 6:1 but seem like low contrast and I have seen others that are 4.5:1 that are hard to see. While overall the algorithm is pretty good there are some cases that are problematic in real life situations. There is nothing normative in WCAG 2.0 flag it on other than this sufficient technique and failure technique combo -- which themselves are not strongly rooted to the SC of either WCAG 2 or 2.1. I think you are asking to make the requirement stricter -- which I agree is the way to go for users -- but without normative support I fear we could loose the technique altogether and have no contrast difference minimum under WCAG 2 which would put users in a worse situation.

[yatil]

@mraccess77 I don’t see where I would make the requirement stricter. Color is not defined as being only applicable to hue in WCAG.

I fear we could loose the technique altogether and have no contrast difference minimum under WCAG 2 which would put users in a worse situation.

No. If that technique is not there, it is clear that underlines are required, which is a vast improvement for users.

I don’t have any more time to discuss this. If color means hue, that needs to be defined in the spec or at least in the Understanding documents somewhere. At least for the German-speaking part of the word color includes everything and not just two of three aspects.

[awkawk]

On the call we discussed this and I'd like to clarify a few points: 1) G183 doesn't create anything, and certainly not a loophole. As a sufficient technique, G183 offers one way to meet 1.4.1/Use of Color, but there are certainly others. Where it is of interest is that it is establishing an area that the working group feels is safe for developers/designers to use in meeting 1.4.1. 2) The Working Group understands that 1.4.1 doesn't specify 3:1 as a ratio, but for the past 10 years G183 and F73 have expressed the WG opinion that 3:1 is sufficient as a ratio for differentiating link text from non-link text. 3) The WG has clarified its view on color vs. hue in https://www.w3.org/TR/WCAG20-TECHS/F73.html. I don't think that everyone enthusiastically supported this but the WG did have consensus on it (https://www.w3.org/2002/09/wbs/35422/20080911misc/results#xlinkcolo). David made a comment that I think would help if we added to the understanding document. 4) We discussed on the call that 1.4.11/Non-text contrast clarifies that 3:1 is the ratio that is to be used to indicate the presence of user interface components (such as links). 1.4.1 says that you can't rely only on color, 1.4.11 identifies the ratio. 5) I think that G183 could be modified to remove steps 3 and 4 of the procedure and it would then be aligned with F73. This wasn't done when written because the group isn't looking to encourage this practice, even if it isn't regarded as a failure.

My gut from the call is that the WG still supports this, but feels that this should be further clarified. I'm going to take a look.

[patrickhlauke]

just on point 4 there

We discussed on the call that 1.4.11/Non-text contrast clarifies that 3:1 is the ratio that is to be used to indicate the presence of user interface components (such as links). 1.4.1 says that you can't rely only on color, 1.4.11 identifies the ratio.

the presence of the user interface component is fine (though as the interface component is text here, 1.4.11 doesn't arguably apply? we're not talking about the focus outline here, but about the text itself). differentiating the text which is a link from text which is isn't a link is the problem. and the two colours (the link text colour and the static text colour) are not necessarily "adjacent", as there's white (or whatever background the page has) between them? this is all a bit stretched/borderline, i'd say...

and on point 1., there are some (me included) that don't feel this technique is "safe for developers/designers to use", particularly in the context of mouse/touch users

[awkawk]

"Visual information required to identify user interface components and states"

This includes the focus state as well as the ability to identify components, which includes links.

For G183, I agree that it isn't a great technique from a touch perspective, which is part of why I have suggested getting rid of steps 3 and 4 in the procedure, although that might also happen in a different technique.

[patrickhlauke]

This includes the focus state as well as the ability to identify components, which includes links.

but we aren't talking about focus state here. quite the opposite in fact: that unfocused links are difficult to distinguish from static text if they're missing any other visual indicator other than color.

also: removing steps 3 and 4 (from the testing process?) in G183 makes the core issue even worse for all users? as then you're just relying on color (luminance) difference, and not even (by the backdoor) suggesting that at least on focus it should have some additional visual indicator?

anyway, like Eric, i think i've said my piece here. i fundamentally disagree that saying a low contrast difference of 3:1 on non-adjacent colours (because the two colours aren't butting up against each other) is sufficient to distinguish two things in different states (static text versus a link, but i would argue similarly for an inactive vs active button). but i see that this is likely going nowhere.

[awkawk]

This includes the focus state as well as the ability to identify components, which includes links.

but we aren't talking about focus state here. quite the opposite in fact: that unfocused links are difficult to distinguish from static text if they're missing any other visual indicator other than color.

That is what "the ability to identify components" refers to.

[detlevhfischer]

I support Eric‘s and Patrick’s argument here (should have spoken up in Telco but was too distracted). Could we not retain G183 while signposting it as deprecated - so those who have used it to reach conformance have no rug pulled under them while authors looking for advice today realise this is not recommended?

[patrickhlauke]

That is what "the ability to identify components" refers to.

you can perhaps identify them (that one is different from another) when the colours are adjacent. not when they're separated by more white/background colour. in the context of 1.4.11 i would argue the "identify" was "you can actually perceive that there's something there, and for that it needs to have a contrast of 3:1", not "you can differentiate them, even if they're apart..."

anyway, stick a fork in me, i'm done :)

[awkawk]

@detlevhfischer - not really. The techniques represent the view of the WG, so either the WG thinks it meets 1.4.1 or it doesn't.

@patrickhlauke it isn't that I don't understand what you are saying. Based on this being an accepted technique at present, the WG position is that G183 is ok for 1.4.1. That can co-exist with the idea that we think that there is something more that might be done by an author or that might be changed in a future version.