add help text to link-in-text-block rule

[shanisebarona]

Add help text with more context to link-in-text-block rule.

Suggestion: Sufficient color contrast ratio of 3:1 is necessary to distinguish link text color from surrounding text color.

[WilcoFiers]

Thank you for the suggestion. I think this rule need some work TBH. The W3C took the position a while back that a 3:1 contrast between the link and it surrounding text would be sufficient. That's not how we understood this criterion when we wrote the rule. Now that a 3:1 contrast ratio is explicitly permitted I think the rule needs some revision.

Out of curiosity, this rule is experimental and so isn't on by default. What are you running axe-core with that has this rule enabled?

[shanisebarona]

The rule is currently in Accessibility for Insights for Web as a "needs review" check.

[DaveTryon]

@WilcoFiers, as discussed offline, we're picking this up with the following proposed approach:

1. Replace the current link-in-text check with 4 pseudoClass checks--in each case, fall back to the non-pseudoClass colors if colors can't be found in the pseudoClass

• link-link-in-text-block mirrors link-in-text-block but checks the link pseudoClass
• link-hover-in-text-block mirrors link-in-text-block but checks the hover pseudoClass
• link-visited-in-text-block mirrors link-in-text-block but checks the visited pseudoClass
• link-active-in-text-block mirrors link-in-text-block but checks the active pseudoClass

2. Add the new checks to 'all' array of the link-in-text-block rule
3. Update tests appropriately

The net result should be that the link-in-text-block rule is able to account for each of the pseudoClass types, then provide a meaningful answer.

Two observations on this approach:

1. Looking at https://www.w3.org/WAI/WCAG21/Understanding/use-of-color, a 3:1 contrast ratio (G183) is just 1 of 4 possible ways to satisfy the requirement. G14 would satisfy the requirement equally well. If someone were to adopt G14, this rule would essentially be a false positive.
2. A very strict reading of https://www.w3.org/WAI/WCAG21/Understanding/use-of-color might require that we have a 3:1 contrast ratio between each pairing of pseudoClass options. We're not currently planning on checking for this, but only checking that the colors for each pseudoClass provide a 3:1 contrast ratio against the colors of the surrounding text block. In an extreme case, imagine that someone specified the same colors for each pseudoClass. As long as the colors had sufficient contrast to the surrounding text, the rule would pass (even though the link colors would never change in response to user action).

Please feel free to comment on the proposed approach and/or the mentioned observations.

[DaveTryon]

@WilcoFiers, I've some experimentation with pseudoclasses, and have determined that there are 3 'tiers' where colors can be set, and we'll need to account for this in the revised rule. The tiers are:

Tier	pseudoClasses	Description
High	hover or active or focus (mutually exclusive)	Classes that reflect the user's current interaction
Middle	link or visited (mutually exclusive)	Classes that reflect the user's previous interactions
Low	base class or containing text block	Classes that are agnostic of user interaction

When we expand this matrix, we end up with the following checks:

Check	Order of checking colors
link-hover-visited-in-text-block	hover, visited, base class, text block
link-hover-link-in-text-block	hover, link, base class, text block
link-active-visited-in-text-block	active, visited, base class, text block
link-active-link-in-text-block	active, link, base class, text block
link-focus-visited-in-text-block	focus, visited, base class, text block
link-focus-link-in-text-block	focus, link, base class, text block
link-visited-in-text-block	visited, base class, text block
link-link-in-text-block	link, base class, text block

Of course, this still only covers G183 and ignores G14...

[DaveTryon]

I just figured out that G14 is already handled in elementIsDistinct, so please ignore my comments on that. There's also a focus pseudoClass that fits into the High tier (I've updated the table in the previous comment)

[DaveTryon]

We've hit a snag with this. We revised the code to use window.getComputedStyle, but we've discovered that this API intentionally disregards pseudoclasses. In fact, we even found a chromium test that will fail if this behavior changes.

We're not sure on how to best move forward on this. Creating a mechanism to emulate CSS handling might work, but that doesn't feel like the right solution. @WilcoFiers, we'd love to get your thoughts on what might make sense here.

[straker]

I'll let @WilcoFiers know you ran into trouble and he'll reach out to you with more directions at a later time (he's currently unavailable)

[WilcoFiers]

@DaveTryon @straker I get the impression there's still confusion about the necessary changes. Lets get on a call and sort it out. That'll be more efficient than this back-and-forth we've been doing. Please e-mail me your availability.