Wcag: Looking for definitive clarification regarding 1.4.1

[scottaohara]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

Would this fall/fail under 1.4.11?

[patrickhlauke]

i don't see why/how, @erikkroes

[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?

[patrickhlauke]

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

[erikkroes]

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]

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]

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]

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.