Rule 2ee8b8 ("Visible label is part of accessible name"): introducing a new "label in name algorithm".

[dan-tripp-siteimprove]

<< Describe the changes >>

Closes issue(s):

• closes Visible label is part of accessible name (2ee8b8): screen reader pronunciation help in name that is not in label #2051, closes Visible label is part of accessible name (2ee8b8): symbolic text should not be considered a visible label #1989, closes Visible label is part of accessible name (2ee8b8): should common abrevations be accepted? #1619, closes Visible label is part of accessible name (2ee8b8): extra spaces in name might be OK. #1615, closes Visible label is part of accessible name (2ee8b8): Expectation seems to have unintended consequences #1458
• does not handle: "Visible label is part of accessible name" [2ee8b8]: does the "label" necessarily contains all the visible text content? #2040 Visible label is part of accessible name indicates that inputs are not applicable because the label is not contained in the input #1500 "label and name from content mismatch" needs to also fail split up labels [2ee8b8] #451

Need for Call for Review:
This will require a 2 weeks Call for Review

---

Pull Request Etiquette

When creating PR:

• [ x] Make sure you're requesting to pull a branch (right side) to the develop branch (left side).
• [x ] Make sure you do not remove the "How to Review and Approve" section in your pull request description

After creating PR:

• [ x] Add yourself (and co-authors) as "Assignees" for PR.
• [ x] Add label to indicate if it's a Rule, Definition or Chore.
• [x ] Link the PR to any issue it solves. This will be done automatically by referencing the issue at the top of this comment in the indicated place.
• [ x] Optionally request feedback from anyone in particular by assigning them as "Reviewers".

When merging a PR:

• Close any issue that the PR resolves. This will happen automatically upon merging if the PR was correctly linked to the issue, e.g. by referencing the issue at the top of this comment.

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 Call for Review period. In case of disagreement, the longer period wins.

[WilcoFiers]

@dan-tripp-siteimprove Since this is being worked on still by @kengdoj, can we set this to draft?

[dan-tripp-siteimprove]

@dan-tripp-siteimprove Since this is being worked on still by @kengdoj, can we set this to draft?

Done

[Jym77]

This looks good. I like the details and the many new examples that explicit the decisions we've taken.

[Jym77]

The conditional here sounds a bit weird 🤔
Notably, a text node that is not visible, rendered, and contains more than whitespace (e.g. in <span style="visibility: hidden">Hello</span>) would not trigger it and therefore have an empty string as visible inner text (rather than a whitespace).

[dan-tripp-siteimprove]

Interesting question. I don't know the answer. But I'll note that I copied this definition from sanshikan so if it needs fixing here, it probably needs fixing there too.

[Jym77]

OK, doing some archaeology, this is due to the fact that whitespace are not visible per our definition…

<button aria-label="hello world"><span>hello</span><span id="space"> </span><span>world</span></button>

The span#space is not visible (and neither is its child text node). So the first bullet doesn't apply. Without the second bullet, the visible inner text of the button would be helloworld, not matching the accessible name of hello world due to spacing…
I guess we need to add an example to show that.

[dan-tripp-siteimprove]

Done in b2df021

[dan-tripp-siteimprove]

This raises another question: what should we do with this?
<a aria-label="Download specification" href="#"><span>Download</span><span style="visibility: hidden">x</span><span>specification</span></a>
According to the current definition, because of the clause "contains only [whitespace][]", the visible inner text of the <a> element is "Downloadspecification". Visually it looks like "Download specification". So I wonder if we could remove the clause "contains only [whitespace][]". What do you think?

[Jym77]

Good point 🤔 But if the span was invisible due to absolute positioning out of viewport, it shrould be removed:

<a aria-label="Download specification" href="#"><span>Download</span><span style="position: absolute; left: -9999px">x</span><span>specification</span></a>

I guess the true condition is whether it creates a CSS box that lies somewhere between the ones of the rest of the text taking part in the computation (and isn't fully contained in them), or something like that 🙈
Or maybe we just make the special case for visibility: hidden and assume that these is already a corner case and that it won't create too many true problems (We've been using that definition in Alfa for two years and I don't remember seeing a problem caused by it, so it may be safe to assume that it is a good enough approximation).

[dan-tripp-siteimprove]

This has given me a lot to think about. I'll try to bring it up in our next one-on-one meeting.

Changes done

[dan-tripp-siteimprove]

@daniel-montalvo - respectfully - in commit 2f42547 I think that you accidentally broke something. So I just fixed it in commit 74d7017 .

When I wrote Passed Example 9, I did not include whitespace on purpose. Your commit added whitespace, and breaks it. Specifically: the new whitespace makes this "passed" example fail the rule.

I've put both versions on a test page here, for convenience.

This happened before in commit 5617755 and I fixed it in 5aa55e6 .

I wonder if we have a process or tools problem here. Is there an assumption somewhere - implicit or explicit - that ACT examples are whitespace-insensitive? I think that for this rule, that assumption will get broken often.

[Jym77]

This is good. Whatever left over comments or disagreement are very minor and shouldn't block this any further :-)

[Jym77]

What I was trying to say is in the line of "(technical): ellipsis is not in the Letter or Number unicode classes; (philosophical): and this is a good thing for us because ellipsis matches WCAG definition of 'non-text content' and is ignore by the SC". So "(b), which is indeed the correct behaviour for WCAG" (not really referencing (a) which is not needed in that case).

That would be different from "X for close" which is ignored under (a) only.

[dan-tripp-siteimprove]

@Jym77

What I was trying to say is in the line of "(technical): ellipsis is not in the Letter or Number unicode classes; (philosophical): and this is a good thing for us because ellipsis matches WCAG definition of 'non-text content' and is ignore by the SC". So "(b), which is indeed the correct behaviour for WCAG" (not really referencing (a) which is not needed in that case).

🤔 thank you for the clarification, but I still don't see how to improve the sentence in question for all readers. The suggestion you made on May 21 was to turn this line of Passed Example 15:

This passes for two reasons: 1) because the ellipsis ("…") is [non-text content][], and 2) because the ellipsis is neither a letter nor a digit and so is filtered out by the [label in name algorithm][].

... into this:

The ellipsis ("…") is neither a letter nor a digit and so is filtered out by the [label in name algorithm][]; this is correct because it is [non-text content][].

Maybe why I'm struggling with that is because I don't have a problem that the pertinent line of the algorithm:

1. For each character that either a) represents non-text content, or b) isn't a letter or a digit: replace that character with a space character.

... calls an imaginary function called isNonTextContent(), the implementation of which is hand-wavey. I get the impression that you breathe a sigh of relief in this example when you see that !isLetterOrDigit("…") evaluates to true, so we can short-circuit the OR operator and avoid calling the hand-wavey isNonTextContent("…").

You're not wrong. But I suppose I'm making a guess that most readers will think like me:

• they'll read the algorithm, where it says ~ "(a) or (b)",
• they'll notice that "…" results in a "true" for both (a) and (b), and they won't be troubled by the hand-waviness of (a) generally, because for the ellipsis it's clear enough,
• they'll see that as "passing for two reasons".

Hence my wording.

Also I wonder if you're thinking of the SC more than I am. I'm thinking only of the rule. But you're right, there is something interesting going on here, where the rule implements the SC in a nifty way.

I'm starting to wonder if we should tackle all of this in Passed Example 15. What if we turn it into this:

According to a step-by-step reading of the [label in name algorithm][], this example passes for two reasons: 1) because the ellipsis ("…") is [non-text content][], and 2) because the ellipsis is neither a letter nor a digit. The ellipsis is an example of where those two categories overlap. The WCAG Success Criterion says to ignore non-text content, and the algorithm implements that effectively in this case. The determination of "non-text" often requires a judgment call, but in this example it doesn't, because it is caught by the algorithm's "isn't a letter or a digit" condition, which is objective.

That's a little wordy, but does it get us closer to any place worth going?

[Jym77]

@dan-tripp-siteimprove I guess I'm getting uneasy as this seems to indicate that (b) (not a letter nor digit) is include in (a) (non-text content), which makes the condition "(a) OR (b)" redundant and collapse to (a).

Do we have examples of stuff that are rejected because of (b), but not because of (a)? I guess not as it would be incorrect (for WCAG) to reject them if they are text-content… Then should we rephrase the algorithm from "(a) OR (b)" to "(a), notably (b)"? ("For each character that is non-text content, including but not limited to every character that is neither letter nor digit, …")

[dan-tripp-siteimprove]

@Jym77

Do we have examples of stuff that are rejected because of (b), but not because of (a)?

I'm thinking of the dollar sign. For example, <a href="#" aria-label="50 euros">$50</a>. I believe that "$" is considered "text" by WCAG, because "text" is defined as "expressing something in human language" and "human language" is defined as "language that is spoken ...." That <a> passes the rule (in the rule's current state) because the algorithm filters out the "$". It's bad accessibility because the page author put "euros" in the aria-label and they should have put "dollars" or had no aria-label. I think it probably fails the SC, and the intent of the SC. But it passes the rule and I think that we in ACT tolerate a false negative like this.

If that <a> example isn't ideal because "$" is before the "50", and "dollars" is after it: I could come up with another example such as <a href="#" aria-label="50 degrees">50%</a>.

I couldn't find any commentary in WCAG which confirms my claim that the dollar sign is text. But the Understanding doc doesn't seem to say anything that contradicts my claim either. I "ctrl+f"ed for "symbol".

Then should we rephrase the algorithm from "(a) OR (b)" to "(a), notably (b)"? ("For each character that is non-text content, including but not limited to every character that is neither letter nor digit, …")

If I'm correct above, then I think that we shouldn't do that particular rephrasing. But let me know what you think.