Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change technique G183 from sufficient to advisory? #2310

Open
patrickhlauke opened this issue Apr 13, 2022 · 9 comments · May be fixed by #2508
Open

Change technique G183 from sufficient to advisory? #2310

patrickhlauke opened this issue Apr 13, 2022 · 9 comments · May be fixed by #2508

Comments

@patrickhlauke
Copy link
Member

Since https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html now states that a difference of contrast of 3:1 or higher is sufficient to pass the 1.4.1 Use of Color SC, should technique G183: Using a contrast ratio of 3:1 with surrounding text and providing additional visual cues on hover for links or controls where color alone is used to identify them be changed from being sufficient to being advisory? Or at least reworded to make clear that it's the 3:1 contrast part that's sufficient, and the extra underline on hover is advisory only?

@awkawk
Copy link
Member

awkawk commented Apr 13, 2022

@patrickhlauke since there are places that require conformance with WCAG 2.0 and not 2.1, I think that we need to be careful what we do here.

@patrickhlauke
Copy link
Member Author

patrickhlauke commented Apr 13, 2022

Maybe just removing reference to G183 altogether from the 2.1 (and going forward, 2.2) understanding for 1.4.1?

@awkawk
Copy link
Member

awkawk commented Apr 13, 2022

I think that would suggest that a 2.1 SC changes a 2.0 SC, and I don't think that will work.

I'd be happy to see step 2 in the procedure removed though, as I don't think that it does anything. I know that some people point out that you can mouse hover links on a laptop/desktop but not on mobile, but you can long-press on a link on mobile and that certainly provides additional verification that something is a link. The fact that F73 doesn't require that step to not fail the SC supports the argument that the additional step is not required and that G183 is sufficient not not minimally sufficient.

@alastc
Copy link
Contributor

alastc commented Apr 27, 2022

So the action is to remove references to hover and step 2 from the procedure?

@patrickhlauke
Copy link
Member Author

either removing it altogether, or clarifying that that step is optional and not required for conformance, but a nice to have. and maybe making it clearer in the preceding prose again that the extra underline is only a best practice and not required... (seems a lot of faff compared to just removing the technique though...)

@patrickhlauke patrickhlauke self-assigned this Apr 27, 2022
@patrickhlauke
Copy link
Member Author

patrickhlauke commented Jun 4, 2022

@patrickhlauke since there are places that require conformance with WCAG 2.0 and not 2.1, I think that we need to be careful what we do here.

coming back to this ... note that technique G183 is already different in 2.0 https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G183 compared to 2.1 https://www.w3.org/WAI/WCAG21/Techniques/general/G183

In the 2.0 version, it says (emphasis added)

With this technique, a relative luminance (lightness) difference of 3:1 or greater with the text around it can be used if additional visual confirmation is available when a user points or tabs to the link.

Whereas in 2.1, it says (emphasis mine)

To meet success criterion 1.4.1: Use of Color a relative luminance (lightness) difference of 3:1 or greater with the text around can be used. This technique goes beyond the success criterion and asks for visual highlights when the user hovers over each link, such as an underline, a change in font style such as bold or italics, or an increase in font size.

So the 2.1 version of the technique is already saying (in a slightly confused way) that the "on hover" part goes beyond the requirements of the SC ... so it kind of defeats its own purpose here to an extent (and it already shows that the 2.1 interpretation is slightly different from the 2.0 interpretation at the time)

Wonder if prefacing the second step in the test procedure with "Optionally..." may be all that's needed. Will have a closer look, and possibly add more emphasis in the other parts of this for 2.1 as well to stress that the hover part is optional...

@patrickhlauke patrickhlauke linked a pull request Jun 4, 2022 that will close this issue
@yatil
Copy link
Contributor

yatil commented Oct 17, 2022

And that is why you don’t let techniques define normative SCs.

@mbgower
Copy link
Contributor

mbgower commented Mar 30, 2023

You know, I swear that this technique used to say it took an underline on focus too... But versions in both versions do not contain that...
This is orthogonal to this specific change but I REALLY think it behoves us to have a change history on any techniques that are updated.

@mbgower
Copy link
Contributor

mbgower commented Mar 30, 2023

Yeah, here it is #1272

Here's the challenge I'm struggling with... As we change an existing technique like this, we risk altering what the visually distinguishing things are which are used to identify a control, which then means an alteration to what is required for 1.4.11 Non-text Contrast.

As an example, I'm doing a lot of work with teams on what visual cues clickable tiles need to be clear as being UICs. At the same time we're dealing with those questions, I'm seeing other link-like UICs that also are deviating in different ways, which are based on some of these changing guidelines for what a link needs to not be considered relying on use of colour.

I think an SC like 1.4.11 Non-text contrast that lets us assess these evolving conventions is interesting, but I do think some kind of record of how our own general techniques have evolved would really help people understand some context.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants