fix(link-name): pass landmark content as link text

[WilcoFiers]

To figure this one out I tested the following code:

<label for="bar" id="foo">
	<a href="/" id="baz">
		<div role="alert" aria-label="Goodbye">Hello</div>
		<div role="textbox" aria-label="mars">earth</div>
		<div role="img">people</div>
	</a>
</label>
<input type="button" aria-labelledby="foo" id="bar" />

The surprising thing is that AT gave different names than the browsers do. The button works fairly consistently, but most AT seem to have something in place to deal with this a[href] > article:not([aria-label]) scenario. Here are my test results:

(either aria-labelledby or explicit label)

Browser (+AT)	Link	Button
Chrome name	Goodbye mars	Goodbye mars
NVDA + Chrome	Hello mars	Goodbye mars
JAWS + Chrome	Hello slash	Goodbye mars
Firefox name	Goodbye mars earth	Goodbye mars earth
NVDA + Firefox	Hello mars	Goodbye mars
Safari name	Goodbye mars people	Goodbye mars
VO + Safari	Goodbye earth mars	Goodbye mars
JAWS + IE	Hello earth people	Goodbye mars

Versions: Firefox 82, Chrome 86, Safari 14, IE11, VO (MacOS) Catalina, JAWS 2020, NVDA 2020.3

Results are completely all over the place, so to avoid false positives what I've done is chosen the most optimistic scenario, which is that when looking for name from content of an element that isn't a label, all descendants should be considered, even elements that are named from author, except if the element that is named from author has an accessible name already through some other means.

This PR does not guarantee the outcome will work everywhere. Instead it avoids the false positive. I'm opening a ticket to look at this more closely when we're not days away from a code freeze.

Closes issue: #1461

Reviewer checks

Required fields, to be filled out by PR reviewer(s)

• Follows the commit message policy, appropriate for next version
• Code is reviewed for security

[WilcoFiers]

Even when subtreeDescendant is true, we need to return an empty string for things that aren't nodes.

[straker]

Are we marking what the browser's accessibility tree says or what screen readers with those browsers say?

[WilcoFiers]

the browser's name in the acc tree.

[straker]

We should add the example code you used as a test case for this change so we can make sure future changes affect it.

done

[goodwitch]

Hey @WilcoFiers is this really a common situation. I was just chatting about this with Michael Fairchild...and he wonders how common that issue is?

It seems like having a textbox wrapped by a link would be super rare (and also invalid if this were entirely HTML, but the mix of html/aria means it’s probably technically valid code and would pass 4.1.1)

What am I getting at? If screenreader or browser devs see this code reported in an issue, they might say “yeah, that’s not valid and such an edge case, I’ll put this at the lowest possible priority to fix”.