Target size: "non-target text": interpretation

[dan-tripp-siteimprove]

When SC 2.5.8 says "constrained by the line-height of non-target text", does "non-target text" mean a) text that is not part of the target currently being evaluated, or b) text that is not part of any target?

I'm thinking of an example like this: <p><a href="#">x</a> <a href="#">y</a></p>

If we're evaluating the first link ("x"), then the text "y" does meet definition (a) and does not meet definition (b).

[patrickhlauke]

in your example, both "x" and "y" have the same line height (and as a result, the same target area height), so it's a bit irrelevant?

[dan-tripp-siteimprove]

Thank you for this - you've revealed a more interesting question, which we should probably clear up first: what is an example of a target being "constrained by the line-height of (any) text"?

I gather, from the Understanding document, that the goal is to cover cases of reflowing text. But I don't see how the "constrained" clause does that. Or, more to the point: what a concrete example of such constraining would be.

In the two examples below, "x" seems not to be constrained in this way, because AFAICS, "x" as a target is the same size in both examples.

<p style="font-size: 10px; line-height: 5px"> filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler <a style="font-size: 20px" href="#">x</a> filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler </p>

<p style="font-size: 10px; line-height: 40px"> filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler <a style="font-size: 20px" href="#">x</a> filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler </p>

[dan-tripp-siteimprove]

I'm sure I'm missing something, but maybe I'm not the only one. So if we arrive at some examples here, I could turn them into a PR for the Understanding document, for the people like me.

[mraccess77]

I very much would like to know how to calculate line-height and whether the documentation is referring to the CSS property or some other factor. I opened an issue but it was moved to discussion without any discussion on the aspect related the line height question. https://github.com/w3c/wcag/discussions/3829

[alastc]

what is an example of a target being "constrained by the line-height of (any) text"?

I feel like this is (or should be) very simple, but one of us is missing something. Please forgive me if starting from basics comes across as patronizing, I just think we need to find the missing assumption.

Tweaking your initial example: <p>x <a href="#">y</a></p>

• The paragraph has a determinable line-height for the text within it.
• The "x" is non-link text.
• If you made the link inline-block and increased it's height to 24px, it would increase the line-height of the text (codepen).
• Therefore the height of the link on "y" is "constrained by the line-height of non-target text".

does "non-target text" mean a) text that is not part of the target currently being evaluated, or b) text that is not part of any target?

It means text that is within the same block (for line-height purposes) as the link, but it is not a link.

Text is defined a "sequence of characters that can be programmatically determined, where the sequence is expressing something in human language", so things like full-stops can be ignored for that purpose.

Where the understanding doc says:

Inline: The success criterion does not apply to inline targets in sentences, or where the size of the target is constrained by the line-height of non-target text.

Perhaps we could add: "Constrained means that increasing the height of the link would increase the apparent line-height of adjacent text."

[dan-tripp-siteimprove]

I think we're getting close to the source of my confusion. Thank you for approaching this step-by-step.

If I was from another planet and I looked up "constrained by" in the dictionary, I would find that "X is constrained by Y" could mean one of: i) X has a maximum which is determined by Y. ii) X has a minimum which is determined by Y. iii) both.

In all of (i) (ii) and (iii), the direction of causation is from Y to X. i.e. Y is the cause and X is the effect.

Substitute X = "the link", and Y = "the non-link text".

You wrote "If you made the link inline-block and increased it's height to 24px, it would increase the line-height of the [non-link] text".

That sentence is true. Your codepen verifies it. In that sentence, "the link" is the cause and "the non-link text" is the effect. i.e. X is the cause and Y is the effect. That's the opposite direction of causation compared to definitions (i) (ii) and (iii). That's where it fell apart for me. On my planet - where definitions (i) (ii) and (iii) reign - your "therefore" doesn't follow. What do you think?

[mraccess77]

@alastc do I understand that the way to test this is to change the CSS height property and set display to inline-block of the interactive target and then determine if the line height of the surrounding text increases?

In terms of line-height is there a way to check for this change programmatically such as by looking in developer tools? Sometimes line-height is not set and it may be hard to determine visually that something has changed (e.g. if you are not able to see).

[alastc]

@dan-tripp-siteimprove I'm not arguing with your logic but: If increasing the line-height is an undesirable side-effect of increasing the link height, then not being able to increase the link height without the side-effect is what makes it "constrained".

We had some back and forth on that wording at the time, that was the most understandable we could find.

Happy to add a little explanation in the understanding doc, did the text above help?

@mraccess77 That example is the easiest way I could think of to show the problem, there may be other ways to do the same thing. It should be possible to determine the line-height programmatically, but I couldn't see a way to find that in the browser tools from a quick look.

However, I'm not sure how useful that will be, in this scenario you'd be finding links which are exempt. If you were automating this wouldn't you want to exclude links which are in a container with non-link text?

[mraccess77]

@alastc said " If you were automating this wouldn't you want to exclude links which are in a container with non-link text?"

That's the question I've been trying to find out - is it enough to just pass links if they are in the container as text? Or do we actually need to determine the impact on line-height or is that a guarantee when links are with text?

When you say "container" does that mean block level element? Is that they share a block level element - excluding any inline element ancestors? Having some specific test steps would be great to ensure inter-rater reliability here.

[dan-tripp-siteimprove]

@alastc Yes, that changed everything. I'm all for adding something in the Understanding doc. If you don't have some wording in mind already, may I propose that it start something like this:

The condition of the target being "constrained by the line-height of non-target text" does not mean that the line-height of non-target text imposes a hard limit on the height of the target. It means that the line-height of non-target text imposes the following soft limit on the height of the target: if the target is made too tall, then there will be the undesirable side effect of....

What's next? Should I make an issue, or a PR?

[dan-tripp-siteimprove]

Let's see if I understand this yet:

1. <p>x <a href="#">y</a></p> "y" meets the inline exception, because Alastair said so here.

2. <p><a href="#">x</a> <a href="#">y</a></p> "y" doesn't meet the inline exception, because regarding the definition of non-target text, Alastair wrote "it is not a link".

3. <p><a href="#">x</a> filler <a href="#">y</a></p> "y" meets the inline exception, by the same logic of Example 1.

(For Example 1 and 3 above, for now we should ignore the fact that the inline exception won't make "y" pass or fail the SC. "y" will pass the SC regardless, because "y" has no other targets within a 24 px diameter. In these examples I'm focusing on the inline exception.)

I think the world might benefit from these examples (and more) of what does and doesn't meet the inline exception. I hope I can help with that.

[dan-tripp-siteimprove]

Through this old issue I found this google doc which is a treasure trove of "in scope" and "out of scope" examples of the inline exception. It seems to me that the world would benefit if all of those examples were added to the Understanding doc. @alastc seemed to be thinking along these lines when he wrote "There are a couple of scenarios that could be interpreted in either direction (e.g. bullets and numbers in lists), that we’d need to outline in the understanding doc." I could make a PR for this, but it would be rather large. Any thoughts?

[dan-tripp-siteimprove]

@dav-idc

[dan-tripp-siteimprove]

Lately when a customer argues about the inline exception, I send them a link to the google doc. Obviously that's not ideal. I'd rather send them a link to the Understanding doc.

[dan-tripp-siteimprove]

Adding to my troubles, I discovered that the google doc seems to contradict itself in these places:

• The statement "Ordered lists with numbers / letter would count as text, therefore are always excepted." seems to contradict the "In scope (not part of exception)" column's fourth example [1].
• The statement "Indicators for ordered/unordered lists are considered text" seems to contradict the "In scope (not part of exception)" column's fourth [1] and fifth examples [2].

[1] Screenshot:
[2] Screenshot: