Compute accessible names based on possibly partial accessibility tree

[kasperisager]

As outlined in w3c/accname#25 (comment), the accessible name computation expects to operate on the accessibility tree, not the DOM tree. Among other things, this ensures that relations created using aria-owns are correctly accounted for.

[kasperisager]

Also taking #298 into account, this does become a little more involved than I had hoped. In essence, there seems to be a need to interleave the various steps of the tree construction, name computation, and role resolution as they're all interdependent.

Another interesting thing is a case like this:

<button aria-labelledby="foo"></button>
<div id="foo" hidden>
  Hello world
</div>

While the <button> element is included in the accessibility tree, the <div> element isn't. Yet, we need to determine the name of <div> element as it's being referenced by the <button> element. It therefore doesn't really seem to be the case that the name computation should operate on the accessibility tree after all 🤔

[kasperisager]

This needs more refinement.

[Jym77]

Another case I've found today, somewhat related to the button example:

<h1><span aria-hidden="true">Foo</span></h1>

Name#fromDescendants does not filter out aria-hidden descendants (or hidden descendants). Of course, we need to already know the accessibility tree to know that the span is not exposed 😕
That node has no accessible name in Chrome of Firefox but has some in Alfa 😖

This creates false negative in https://act-rules.github.io/rules/ffd0e9#failed-example-2 and a couple other test cases for this rule…

[Jym77]

Which, I'm afraid, makes this a bug 🙈

[kasperisager]

That seems more related to w3c/accname#30 than the current issue and is something we can solve by adjusting step 2A:

alfa/packages/alfa-aria/src/name.ts

Lines 524 to 528 in 46aace5

	// Step 2A: Is the element hidden and not referenced?
	// https://w3c.github.io/accname/#step2A
	if (!state.isReferencing && !isRendered(element, device)) {
	return empty;
	}