Siteimprove
Compute accessible names based on possibly partial accessibility tree
As outlined in https://github.com/w3c/accname/issues/25#issuecomment-522275511, 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.
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 🤔
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…
That seems more related to https://github.com/w3c/accname/issues/30 than the current issue and is something we can solve by adjusting step 2A:
https://github.com/Siteimprove/alfa/blob/46aace5cbc0f6aa4dbcf38fc272a82bacc878714/packages/alfa-aria/src/name.ts#L524-L528