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

[kengdoj]

Maybe include additional description, like:

Suggested change

	Similar to the previous example.
	Similar to the previous example. The [label in name algorithm][] inserts whitespace.

[dan-tripp-siteimprove]

@kengdoj regarding "Passed Example 8" - I agree that something should be added. However to say that the algorithm "inserts" whitespace could be misleading. The words "insert whitespace" appear in the previous example to explain what the algorithm doesn't do. At any rate, I just made commit bac2432 as an attempt to fix this. Let me know.

rule updated