Rule update: Name from content included in accessible name (2ee8b8)

[annethyme]

This pull request has been split out from #430.

Closes issue:

• Visible label is part of accessible name (2ee8b8): Non-text content is ambiguous #377 - "label and name from content mismatch" lacks a definition of non-text content
• "label and name from content mismatch" needs to also fail split up labels [2ee8b8] #451 - "label and name from content mismatch" needs to also fail split up labels

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

[annethyme]

Discussion on "character" definition taken from the PR (#430) that this one has been split out from:
#430 (comment)

@JKODU:

character seems like a generic definition that we can refer to elsewhere? Perhaps - https://developer.mozilla.org/en-US/docs/Glossary/Character

I see you drawing some distinction away from grapheme, then may be this should not be called character?

@kasperisager:

The issue is that computers don't really deal in graphemes. A language such as JavaScript, for example, represents strings of "characters" as sequences of UTF-16 code points, while other languages, such as C and Go, represent strings of "characters" as sequences of arbitrary bytes. The term "character" therefore has lots of different meanings in different contexts.

[ShadowBB]

Splendid work.

The first 2 examples should be inapplicable examples. Apart from that I will approve this.

[Jym77]

Another fun example, related to #976:

<div role="link" aria-label="next 
   
   page">Next page</div>

As far as I understand accessible name computation, the extra spaces and newline should be removed from the accessible name when it is flattened and thus this should pass the rule even though the name from content is not included in the aria-label.
More elaborate cases with aria-labelledby reading several other elements can also be achieved.

Update

[jeeyyy]

Reviewers, I have updated this rule. Please review again. I am aware of the failing test status check, but this should not stop from reviewing.

[carlosapaduarte]

editorial changes needed

Updated

[Jym77]

How do you compute "visible descendant text content"?

<button>
  <span id="foo">foo</span>
  <span id="space"> </span>
  <span id="hidden" style="display: none">foobar</span>
  <span id="bar">bar baz</span>
  <span id="off-screen" style="position: absolute; left: -999px;">Hello</span>
</button>

What is the "visible descendant text content" of this button?
For this rule purpose, the intend is probably that it should be foo bar baz but

• Why should we include the invisible span id="space" but exclude the invisible span id="hidden" or span id="off-screen"?
• Even within the span id="bar", why do we include the invisible space character?

[Jym77]

I've been talking with @kasperisager about this (and my related issues with the definition of visible, see #977).

One way out of it would be to have a definition of "rendered node" (or similar) in the line of:

a node is rendered if removing it from the DOM tree changes the rendered content.

That way, the span id="space" above would contain a rendered text node (with text content " "). But the span id="hidden" and span id="off-screen" would not.

Similarly, an example like #977 (comment)

<p style="background: #white; text-shadow: black 0 0 0px">
  <span style="color: rgba(0,0,0,0); ">Some text in a human language</span>
</p>

where the text is technically not visible (only the shadow is) would still have a rendered text node.

---

The drawbacks with that are:

• Some nodes like above can be invisible but still have rendered text nodes descendants. That's a bit weird but fairly OK (and anyway a consequence of whitespace being invisible).
• If the shadow above is made more blurry, it gets harder and harder to read its content, to the point that it gets hard to argue that the text content should be used (e.g. to consider it as a WCAG label).
• Something like <span style="background: red; color: red;">Foo</span> has a rendered text node because the span stretch for the same width as the text.

(because of these tricky cases and the weird interaction with visible, the definition of rendered can probably use examples…)

All these are pretty edge cases and they can be handled by an assumption in the line of

This rule assumes that no text node is both rendered and not visible.

(likely needs an explanatory note with examples like spaces)
(essentially, "don't use spaces for layout!")

---

With an assumption like that, this rule can use "visible descendant text nodes" or something similar to grab what is needed.

[Jym77]

Still needs to be done.

[carlosapaduarte]

Just a couple of editorial. But I think the point raised by @Jym77 needs to be addressed also.

[WilcoFiers]

Closing due to inactivity.