New Rule: inline link in paragraph is distinguishable be4d0c

[carlosapaduarte]

New rule

Blocked: waiting for decision on how to handle states in rules

Need for Final Call:
This will require a 2 weeks Final Call << new rule, or substantial changes affecting a large number of test cases, if in doubt, use this. >>

---

Pull Request Etiquette

When creating PR:

• Make sure you requesting to pull a branch (right side) to the develop branch (left side).

After creating PR:

• Add yourself (and co-authors) as "Assignees" for PR.
• Add label to indicate if it's a Rule, Definition or Chore.
• Close the issue that the PR resolves (and make sure the issue is referenced in the top of this comment)
• Optionally request feedback from anyone in particular by assigning them as "Reviewers".

How to Review And Approve

• Go to the “Files changed” tab
• Here you will have the option to leave comments on different lines.
• Once the review is completed, find the “Review changes” button in the top right, select “Approve” (if you are really confident in the rule) or "Request changes" and click “Submit review”.
• Make sure to also review the proposed Final Call period. In case of disagreement, the longer period wins.

[kasperisager]

Some initial feedback. Looking good so far! 👌

[kasperisager]

What's meant by "different"? Are two images with the same URI different, whether it be a data URI or a URL? Do they have to contain different byte sequences? Do they have to subjectively differ in what they depict?

[carlosapaduarte]

We've added an assumption to the definition.

[WilcoFiers]

OK, so I don't know if I caught it all, but I caught a bunch. :-)

[WilcoFiers]

Why is this limited to p elements? Wouldn't this apply just as well to td or li or even just div elements? It seems to me like you didn't quite capture the essence of what you need to test. I think we should come up with a definition of inline links.

[carlosapaduarte]

The initial version used "block of text" which we found to be ambiguous. So we opted to focus this rule on paragraphs (it's even in the name). When we get this done, we can then move to another "blocks of text".

[carlosapaduarte]

We're including li and td but leaving out div because you can have all content of a page being a descendant of the same div.

[WilcoFiers]

This is assuming the rest of the text has a single color.

[carlosapaduarte]

That is correct. If the rest of the text has more than one color then color can't be a distinguishing factor. Need to add that assumption to the text of the expectation.

[WilcoFiers]

This needs a definition that describes what the color of text is.

[carlosapaduarte]

Even if the text is all of the same color?

[WilcoFiers]

I don't understand this assumption. The expectation tests for color.

[ShadowBB]

The expectation is indeed testing for color, but it needs to be a contrast ratio of at least 3:1 for the expectation to be met.

If we leave this assumption out of it; there could be a scenario where the link is not(!) a different color from the rest of the text and this rule would fail it even though it should not fail the SC. (Because you should only fail this SC if you communicate something with color without communicating it in a different way.

Does that help you understand this assumption?

[patrickhlauke]

indeed, if the link is the same color as the surrounding text, this rule is not applicable (it's an odd gap in WCAG since in those cases it's deemed that the link is indistinguishable for all sighted users, not just those with color deficiency/vision impairment that requires at least a 3:1 contrast - though paradoxically keyboard/AT users are advantages because THEY can get to the links without any problem)

[WilcoFiers]

Instead of having this definition use three other definitions, I think this should be a single definition. I don't think we currently have a use for those three as separate definitions. Even if at some point in the future we need it, we can split it out then.

[carlosapaduarte]

Even if don't have another use for these defintions, it is much easier to read the definitions if they are split like this. Don't you think that it makes it worth to have them split?

[ShadowBB]

I also prefer the split up version, but it's mainly a personal choice.

[WilcoFiers]

The distinguishing style definition compares two elements, here you are comparing the link element to text nodes. I don't think that works. Do you mean to compare the link element to the parent element of the text node? If so, there are a bunch of problems with the distinguishing style definition that needs to be worked through. For example:

<style>
  * { box-shadow: #F00 0 0 5px; color: black; }
  a { text-decoration: none; }
style>
<p>Lorem ipsum <a href="">dolar sit ameta> consectetur.p>

This link is still distinguishable, because it's shadow is an inline one, whereas the shadow of the rest of the text is on the block.

[carlosapaduarte]

Updated the expectation (and assumptions) for

• comparing elements instead of element and text nodes
• usage of border and box-shadow as distinguishing factors

Rule updated based on changes requested

[DagfinnRomen]

Some editorials.

[DagfinnRomen]

I do not see the need to remove the underline from examples 3 - 6. By keeping the underline, the test cases focus on the relevant parts of the (in)applicability.

I would suggest adding an inapplicable test case with a link that is not distunguised using colour. I see that this is handled as an assumption and may not need its own test case?

[kasperisager]

I think this could be made a little more unambiguous.

[carlosapaduarte]

What exactly do you think it's ambiguous here?

[kasperisager]

content (such as an image or text) inside [...]

"Content" by itself is pretty broad and open to interpretation. Given that the rule explicitly refers to "content [...] that identifies [the link] as a link", on second thought I don't think that's an issue though.

[...] immediately before or after the test target [...].

In visual order or in tree order?

[kasperisager]

The terms "color" and "background color" are not defined. I imagine we'd want to use the definitions of "foreground color" and "background color" from #833?

[kasperisager]

The expectation is currently unclear on at least two important points:

• How to deal with short-/longhands? We inconsistently refer to both a shorthand (border) and a longhand (box-shadow) property. I'm thinking we'd want to only ever refer to longhands as these are what conformant implementations of CSS must expand to anyway (https://drafts.csswg.org/css-cascade/#shorthand and https://drafts.csswg.org/cssom/#concept-declarations-specified-order).

• How to deal with semi-transparent border and box shadow colors in which case alpha compositing comes into play? One of the points about the definitions of "foreground color" and "background color" as defined by New rule: Text nodes have minimal contrast #833 was to avoid having to explicitly deal with alpha compositing at the rule level. If we refer to specific CSS properties, there's not really a way around this as I see it though.

[carlosapaduarte]

The (foreground and background) color definitions in #833 might return multiple colors. Initially, I thought that would be a problem for this rule. But given that there is an assumption stating that if multiple colors are in use then color can't be a distinguishing factor then that problem goes away and I believe I can rewrite the expectation using #833 definitions.

[carlosapaduarte]

Agreed with using only longhand properties. Replaced border-color by the corresponding longhand properties.

[danistr]

Agree with the comments so far. Approve probably when applied

Updated based on requested changes

[daniel-montalvo]

I think @joao-vicente was referring to @danistr , your input would be very much appreciated since you requested some changes.

From my side, just a couple of things that called my attention.

[daniel-montalvo]

Maybe I am missing something, but why are the head and title elements needed for Passed example 2 and not for passed example 1. If there is the need to have specific styles, they could be added using the

Hello world

'>

<style>
  a {
    color: black;
  }

  a:hover {
    text-decoration: none;
  }
style>

<p>Hello <a href="https://example.com">worlda>p>

[Jym77]

The ACT rule never considered the pointer change as good enough… If we do, we can basically stop testing on hover…

[kasperisager]

Well, it's still possible to do crazy things like this:

<style>
  a {
    color: black;
  }

  a:hover {
    text-decoration: none;
    cursor: default;
  }
style>

<p>Hello <a href="https://example.com">worlda>p>

Now the cursor doesn't change on hover 😔

Edit: This is already being discussed here: w3c/wcag#1761