I find this line very difficult to parse:

If computing a name, or if computing a description and the current node is not hidden, compute the text alternative of the current node beginning with step 2. If computing a description and the current node is hidden, however, compute the text alternative of the current node by returning its inner text content. Set the result to that text alternative.

I tried rewriting it for clarity:

Compute the text alternative using the following steps:

• When computing a name, compute the text alternative of the current node beginning with step 2 (this should point to a named step rather than a numbered step).
• When computing a description:
  • If the current node is not hidden, compute the text alternative of the current node beginning with step 2 (ditto re: numbered step).
  • If the current node is hidden, compute the text alternative of the current node by returning the value of element.innerText.

Set the result to that text alternative.

The last line isn't changed as part of this PR, but it could benefit from further clarification too.

Referencing {{HTMLElement/innerText}} will reference innerText in the HTML spec

FWIW, I removed my "approved" review, since I rewrote a significant portion of this change, but if we get two other reviewers, I think it looks okay.

Looks good with @cookiecrook 's change.

Looks like there might be two places that we need to mention aria-label? There's another place that is adding the innerText language, but it doesn't mention aria-label yet.

I think it's just on Line 274. Where else are you seeing it?

@jcsteh - can you please take a look at this

Name/description calculation hurts my head. 🤯

Overall, I agree this simplifies things and makes sense for that reason. One thing that occurs to me: while the differences in output when descendants use different methods of hiding have been discussed, there will also be significant differences when the target node itself uses different methods of hiding. For example:

<div id="label" hidden>
  visible <span hidden>hidden</span>
</div>
<button aria-labelledby="label"></button>

Button label will be "visible hidden"

<div id="label" style="visibility: hidden;">
  visible <span hidden>hidden</span>
</div>
<button aria-labelledby="label"></button>

Button label will be ""

<div id="label" aria-hidden="true">
  visible <span hidden>hidden</span>
</div>
<button aria-labelledby="label"></button>

Button label will be "visible"

Currently, Firefox returns the same label for all of these: "visible hidden"

That said, I guess this is pretty similar to the "maybe not what authors expect" situation for descendants and consensus seems to be that this is an acceptable compromise. I just thought it worth raising in case it hadn't been considered yet (and is worthy of separate consideration).

We found something that might be a problem. In this example, only the display:none has an innerText, but I would have expected visibility:hidden innerText to remain intact.

<div id="dn" style="display:none">disp-none</div>
<div id="vh" style="visibility:hidden">visi-hidden</div>

Therefore, this PR will break labels where authors thought that visibility:hidden was an acceptable way to hide a label.

Thanks for the heads up. I'm not sure if it is possible to resurrect, we will need to talk it over at the next meeting. I may not be available for the one on the 16th due to a conflict though.

@jcsteh I'm not sure if you are expressing a block/concern in there, or if you are just noting potential implementation complexity.

@jcsteh I'm not sure if you are expressing a block/concern in there, or if you are just noting potential implementation complexity.

Sorry. Allow me to clarify:

1. I'm seeking to make sure that my understanding is correct; i.e. that the test cases I provided yield the results I expect.
2. I'm now a little lost as to the purpose of this change. When the proposal was to use innerText for all "hidden" targets, my understanding was that it simplified things (and was feasible to implement) across all implementations. As it stands now, that benefit is lost (because building a text alternative from a DOM subtree which isn't part of the a11y tree is complex and not well understood). So, what are we trying to solve here now?

@jcsteh I believe your understanding is correct. The follow up change was proposed by @aleventhal to account for an authoring practice he anticipates may cause breakage if we used innerText without exception.

I think both Aaron’s and Jamie’s points have merit, but they are at odds with each other. The HTML Priority of Constituencies urges us to regard Authors over Implementors in this scenario, but at what point does increased implementation complexity outweigh the perceived authoring benefit? Maybe a compromise can be reached.

Perhaps this topic is worthy of more follow-up discussion at an upcoming ARIA meeting. Ideally, @accdc, @joanmarie, @jcsteh, and @aleventhal should attend. I’d like to be there too.

This has been a very informative discussion, but I hope any final solution will error on the side of simplicity and making it easier for authors to understand of how to use aria-labelledby and aria-describedby to solve accessibility design issues. I urge careful consideration of keeping existing computational complexity just because of potential legacy usage and the problems with legacy user agent regression tests failing.

Is this proposal dead now?
At least for Chrome, we no longer need it. We found a way to work around our acc name implementation's complexity and follow the current spec without using innerText.

test.zip

As we spoke of earlier, I've attached an example that would need to be solvable by whatever we decide for this issue going forward.

@aleventhal wrote:

Is this proposal dead now?

No. From the ARIA call (last week IIRC?), we left this with Aaron to make a change suggestion on the PR that either didn't include innerText, or had some more exceptions to the innerText option.

@aleventhal should this be closed now?

Discussed in Feb 3 2022 call. Closing as overcome