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

Looking for definitive clarification regarding 1.4.1 #1467

Closed
scottaohara opened this issue Sep 30, 2020 · 25 comments · Fixed by #3286
Closed

Looking for definitive clarification regarding 1.4.1 #1467

scottaohara opened this issue Sep 30, 2020 · 25 comments · Fixed by #3286

Comments

@scottaohara
Copy link
Member

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):

<p style="color: #000;">
  I'm a paragraph of content with 
  <a href="#" style="color: #000; text-decoration: none;">a link</a>
  to navigate to a new page!
<p>

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

@patrickhlauke
Copy link
Member

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 #000000, links are #000001) then you can fail it for color alone (through the unspoken, introduced more by the backdoor "color is actually hue" bit, though what's the hue of black? if can be anything...)

@patrickhlauke
Copy link
Member

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)

@aardrian
Copy link

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.

@patrickhlauke
Copy link
Member

patrickhlauke commented Sep 30, 2020

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?

@mraccess77
Copy link

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.

@aardrian
Copy link

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.

@awkawk
Copy link
Member

awkawk commented Sep 30, 2020

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...)

@patrickhlauke
Copy link
Member

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...

@aardrian
Copy link

aardrian commented Oct 1, 2020

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.

@scottaohara
Copy link
Member Author

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.

@patrickhlauke
Copy link
Member

intent of a dev to game the SC

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

@alastc
Copy link
Contributor

alastc commented Oct 2, 2020

+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.

@erikkroes
Copy link

Would this fall/fail under 1.4.11?

@patrickhlauke
Copy link
Member

i don't see why/how, @erikkroes

@erikkroes
Copy link

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?

@patrickhlauke
Copy link
Member

but a link is text (unless we're talking about image-based links), so "Non-text contrast" doesn't apply?

@erikkroes
Copy link

Except for the name, the SC doesn't seem to focus on text.

Visual information required to identify user interface components and states

Feel free to ping me on another channel if I'm clogging up the discussion or something. I truly appreciate the insight.

@yatil
Copy link
Contributor

yatil commented Oct 23, 2020

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).

@patrickhlauke
Copy link
Member

Except for the name, the SC doesn't seem to focus on 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.

@erikkroes
Copy link

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.

@rvantonisse
Copy link

rvantonisse commented May 30, 2023

I was also thinking this might fail under 1.4.11, but "User Interface Components" is clarified as ...perceived by users.... Black on black will make users perceive no difference.

To continue somewhat with 1.4.11 with the following author mentioned sentence:

where the appearance of the component is determined by the user agent and not modified by the author

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):

Color is not used as the only visual means of conveying information,
indicating an action, prompting a response, or distinguishing a visual element,
where the visual appearance is determined by the user agent and modified by the author.

scottaohara added a commit to scottaohara/wcag that referenced this issue Jul 17, 2023
…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.
@rvantonisse
Copy link

Just one other thought: What about failing this scenario on 1.3.1 (info and relationships)?

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

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"...

@patrickhlauke
Copy link
Member

the amount of peal-clutching around what is, in effect, an edge case that's very rare in the wild...

@rvantonisse
Copy link

rvantonisse commented Aug 22, 2023

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:

Color is not used as the only visual means of conveying ...

To:

Color is not used as the only means in visual presentation for conveying ...

@patrickhlauke
Copy link
Member

Also I would like to suggest a small rewording

a rewording on normative SC language would require a lengthy process that, at this stage, is not going to happen i'm afraid

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.

9 participants