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

[Jym77]

Looks good. Many small editorial clean up.

[Jym77]

Suggested change

This rule - specifically, the [label in name algorithm][] that this rule relies on - assumes that content within parentheses can be ignored. ("Parentheses" are also known as "round brackets".) This is important becuase the algorithm's treatment of parentheses is to remove them and all characters within them. This assumption is almost always true in English. Exceptions include links with names such "Dune (1984 film)" and "Dune (2021 film)". This assumption is known to be often false in languages other than English, such as German (where parentheses indicate dual states) and Arabic (where parentheses are often used as quotation marks). Violations of this assumption will, in real-world scenarios, more often result in a false negative for this rule rather than a false positive.

This rule — specifically, the [label in name algorithm][] that this rule relies on — assumes that content within parentheses can be ignored ("Parentheses" are also known as "round brackets"). This is important because the algorithm's treatment of parentheses is to remove them and all characters within them. This assumption is almost always true in English. Exceptions include links with names such "Dune (1984 film)" and "Dune (2021 film)". This assumption is known to be often false in languages other than English, such as German (where parentheses indicate dual states) and Arabic (where parentheses are often used as quotation marks). Violations of this assumption will, in real-world scenarios, more often result in a false negative for this rule rather than a false positive.

[dan-tripp-siteimprove]

I manually applied this suggestion in commit 4002eb2

[Jym77]

Suggestion: it may be nicer, both here and for references, to name the clauses and use a dfn element around the name. Something like:

Suggested change

	1. <span id="visible-inner-text:for-text-clause-2">if the [text node][] is not [visible][], is [rendered][], and contains only [whitespace][], its visible inner text is `" "` (U+0020 SPACE);</span>
	1. (<dfn id="visible-inner-text:text-whitespace>Whitespace</dfn>): if the [text node][] is not [visible][], is [rendered][], and contains only [whitespace][], its visible inner text is `" "` (U+0020 SPACE);

Obviously, it needs to be done on all clauses for consistency to make sense. But in a fairly complex definition like this one, it can also help discussing it.

[dan-tripp-siteimprove]

I am willing to do a little bit of this. Maybe not a lot. :)

I just roughly followed your suggestion for this particular clause in commit dee8fcd .

I hesitate to repeat it for all other clauses, because:

1. There are no links to those other clauses yet. I think that "adding IDs for the future" is more trouble than it's worth. If this was a blog post with millions of readers, that would be different.
2. If I "named" the clauses (rather than referred to them by number eg. clause 1, 2, etc.), then some of the names would be long, contrived, and/or misleading. eg. clause 5: "if the computed display property of the element has an outer display type of block, or an inner display type of table-caption..."
3. We've brainstormed how to get more people to make more contributions to ACT rules. Such as having "example-only" rules, or similar. I think that processes on points such as this make a difference.

What do you think?

[Jym77]

Suggestion: Maybe move that to a Background section at the end of the definition? It looks weird starting the definition with a parenthesis.

[dan-tripp-siteimprove]

"It looks weird starting the definition with a parenthesis." - fair point, and I just removed the parenthesis in commit 060a723.

"Maybe move that to a Background section at the end" - I think that would, for a certain percentage of readers, constitute "burying the lede". I suppose the question is: what is that X%? Your guess is as good as mine or better. Even if X is small, I sympathize with those readers a lot. When there is a new thing being introduced, and it's similar to other things, the possibility of "deceptive similarity" arises, and that is a high reading effort for the X%. If I'm saying that this section is better at the start (and I am), then I guess that's equivalent to saying that I suspect that the benefit for the X% of having this section at the start outweighs the cost for the (100-X)% of having to read through it. This isn't an argument, exactly. But have I at least framed the question fairly?

[Jym77]

Note: You can also try and name the bullet, which can be convenient for a complex definition like this one, and makes it easier to define anchors.

Suggested change

	1. <span id="visible-inner-text:for-text-clause-2">if the [text node][] is not [visible][], is [rendered][], and contains only [whitespace][], its visible inner text is `" "` (U+0020 SPACE);</span>
	1. **(<dfn id="visible-inner-text:text-whitespace">Whitespace</dfn>):** if the [text node][] is not [visible][], is [rendered][], and contains only [whitespace][], its visible inner text is `" "` (U+0020 SPACE);

The bolding and parenthesis should make it visually obvious that it is not part of the definition. Obviously, it needs to be done on all items in a list if it is done on any.

[dan-tripp-siteimprove]

I was listening to a podcast which made the point that in early web (1995-2000) there was a diversity of reasonably capable browser rendering engines - 10 or 15 IIRC - whereas now, in 2026, there are roughly three. One reason for the consolidation is the complexity of the standards they need to support. That requires thousands of person-years to write the code. Every new feature X of CSS (or whatever) has been cool and justifiable on its own, but the net effect has been this landscape where it's impossible for the next Firefox to have a chance. Apologies if I'm being dramatic, but down this road are many bad or even dystopian outcomes, IMO. I think there is a similar trade-off at work here. So I favour dumb simplicity, even when the new feature X ("name the bullet" in this case) is, on its own, cool and justifiable. We could summarize my philosophy as "dumb simplicity to avoid dystopian consolidation".

[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.