-
Notifications
You must be signed in to change notification settings - Fork 267
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
Looking for definitive clarification regarding 1.4.1 #1467
Comments
if the link text and static text are exactly the same color, then you're technically not failing any SC. there's no SC currently that says links need to actually be identifiable (visually) as such. if the links deviate but just one tiniest of fractions in color from the static text (e.g. static text is |
i believe this broadly falls under the "it's bad for everybody (sighted), so not an accessibility issue" (though paradoxically AT and keyboard users are at an advantage here as they'll be able to find links) |
The loophole here is that a dev can bypass 1.4.1 by just hiding links in content. My take is that by overriding the defaults (blue/purple), the developer has set a color for links and that color must be compared against the surrounding text. Not only a color-alone failure to distinguish (ex-tinguish?) links on its face, but also triggers G182: 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 and G182: Ensuring that additional visual cues are available when text color differences are used to convey information. It closes the loophole and seems to track with the overall intent. |
the author made sure NOT to use color to identify the links, the author did NOT use color differences to convey information. they chose not to identify nor convey information at all. hence those techniques don't touch this situation at all? |
I agree with @patrickhlauke this is not a fail of 1.4.1. Affordance is a big issue - so no disagreement that it impacts the user - but this is not caught by WCAG 2 as written. |
My argument is that the author chose to, and DID, use color to convey information (obfuscating links) and DID use lack of color differences to try to obfuscate the identity of the links. It is a use of color to change a visual affordance for a control, in particular with an intent to hide it. I understand this is a semantic discussion, but when the intent feels clear and we identify a discontinuity, we can take an opportunity to clarify. |
Obfuscating links doesn't seem like information but a lack of information. I wouldn't interpret this as a failure under WCAG - just a failure of UI design for humans (although it will work fine for screen reader users who aren't looking at the screen...) |
don't think you can use the opposite of something (not conveying information, not identifying something) as a rationale for bending this into a fail. could also say an author that removes audio from a video and replaces it with just white noise it trying to circumvent caption requirements, and therefore they fail caption SCs... |
The caption should be "white noise" (and darn you @patrickhlauke for baiting me). Anyway, I appear to be the lone voice arguing for the intent of the SC coupled with intent of a dev to game the SC as being sufficient to fail. I will leave it be. |
I would still submit that this particular situation should be called out, at least in the understanding doc, to mitigate future questions about this popping up again. |
they're gaming the SC by making links impossible to find for everybody? those kinds of situations are problems for all users and a more generalised usability issue, not just affecting users with disabilities |
+1 for this being a general user-hostile thing rather than a WCAG fail. There probably is an argument that is harder for some folks with cognitive issues, but then easier for keyboard/screenreader users. I don't see a problem with calling out this scenario, I've added 'needs assigning' as we need someone to tackle an update to the understanding doc. |
Would this fall/fail under 1.4.11? |
i don't see why/how, @erikkroes |
As far as I understand, a link is a "user interface component" for 1.4.11. I'm assuming contrast will then be measured against the background and surrounding text can not be considered an adjacent color? |
but a link is text (unless we're talking about image-based links), so "Non-text contrast" doesn't apply? |
Except for the name, the SC doesn't seem to focus on text.
Feel free to ping me on another channel if I'm clogging up the discussion or something. I truly appreciate the insight. |
I think 1.4.11 does not apply, in the black text and black links example, as the SC only talks about adjacent colors. And the UI component (the text of the link) has a 3+:1 contrast ratio against adjacent colors (the background), just not against colors of other elements on the page (here: the text). |
but the name is normative, and scopes the SC to apply to non-text. And the rest of the SC text, and the understanding document, doesn't give any examples of where the SC is applied to anything that is text. long story short, no, 1.4.11 does not apply to text. |
Thanks, both very insightful. I understand the title is normative but never thought to "apply" it to the SC. In this case the scoping clarifies a lot. |
I was also thinking this might fail under 1.4.11, but "User Interface Components" is clarified as To continue somewhat with 1.4.11 with the following author mentioned sentence:
This situation mentioned by Scott would probably be resolved to "Failed" when that sentence is applied to 1.4.1. 1.4.1 would sound like (if criterion text enhancements are permitted):
|
…case closes w3c#1467 Per the feedback in the thread, the use case of a hyperlink being styled to look no different than adjacent static text would not be a failure of 1.4.1 since there is no difference in color to compare against. This PR adds a note to call that out.
Just one other thought: What about failing this scenario on 1.3.1 (info and relationships)?
The link text is visually presented to the user as plain text, but it is a link. Though for 1.3.1, presentation is not restricted to visual presentation in normative text. (it is in understanding to visual and auditory presentation) Though for this specific example the link content is literally "a link"... |
the amount of peal-clutching around what is, in effect, an edge case that's very rare in the wild... |
Also I would like to suggest a small rewording that might help clarification. I am trying to add a reference to "presentation" in the glossary. From:
To:
|
a rewording on normative SC language would require a lengthy process that, at this stage, is not going to happen i'm afraid |
Concerning 1.4.1, I've been having multiple discussions lately on how to handle situations where links have had their default underline removed, and color globally changed to match the static body text of a web page.
Consider the following (inline styles used for example purposes):
Some argue that this would be an instance of an author purposefully changing the styles of links to instead visually present them via color alone, as the other visual identifier (underline) has been removed. If these links were a dark blue instead of black, they would definitely be called out in an audit.
However, the other side of the argument is that because the body text and the link text are the same color, there is no failure of use of color here, and thus color is not being used to promote the links as actionable vs the static text.
From my reviewing of github issues and related docs to 1.4.1, I can see this has been mentioned in 1272 as a current gap area. So I would ask that this issue be used to explicitly mention, at least in the understanding doc for 1.4.1, whether this scenario is or is not a failure.
Thank you
The text was updated successfully, but these errors were encountered: