accname can reference generic with label in a labelledby comp, but is underspecified

[cookiecrook]

Bryan wrote:

I think by Bryan's explanation, the dialog's computed label should be "All about ➡⬅" even though it's clear the author intended it to be "All about Bananas."

Actually no, it would be: "All about ➡Bananas⬅"

The reason is for the following:

1. The first aria-labelledby traversal starts on the dialog and references the element with id="h".
2. The algorithm then traverses all child nodes normally, regardless of additional aria-labelledby references > which are ignored if encountered.

In your example, the aria-labelledby="i" is ignored and the content of the span is traversed in the order that the nodes appear as expected, starting with the unicode character then the image alt and then the second unicode character.

JC: I think this needs more clarification in the AccName spec. Spawning new issue.

Originally posted by @accdc in #209 (comment)

[rahimabdi]

@cookiecrook Do we also need a separate ARIA issue for this since role generic/none elements can be named conditionally?

If yes, perhaps we can include an ARIA spec note in section 5.2.8.6 that aria-label/aria-labelledby are permitted for generics as part of a "child recursion process within AccName" (@accdc 's clarification in #209 (comment).)

[accdc]

Hi,
As requested this is the code sample I was describing.

<a href="#" id="test">
<b>$</b><b>100</b><i aria-label="." class="backgroundImage"></i><b>99</b>
</a>

Years ago this resulted in the accessible name of "$100.99".

This apparently has been changed because it no longer does this in Chrome and Edge, however it still works as expected in Firefox.

[accdc]

As a bit of background, this may seem like an arbitrary difference or authoring error as mentioned in the meeting, but it’s not that simple.

About 6 or 7 years ago we did a lot of work on this part of the algorithm after we reached agreement in the WG, where the algorithm would return the explicit labels of all elements that were not embedded widgets in accordance with the spec if they included aria-label. This was added to the mainstream browsers and passed all checks.

Later, as part of a client engagement due to a lawsuit for a financial institution where they were liable because their financial data was not being accurately conveyed to non-sighted screen reader users, I worked with their devs to correct the issue. It was complicated because the devs had limited control over their code and could only make minor changes due to platform limitations, and the only way to fix the issue was to employ the naming computation where label was returned as part of the algorithm process. The use of role=text was never an option because it never made it to mainstream implementation.

Later, when the work of explicit naming for generic elements was discussed in the ARIA spec, I asked if this would have any impact on the recursive naming computation because that was going to cause problems, and I was assured it would not.

This is why I find this frustrating, because it’s like having the rug pulled out from under a process that has already been solving specific problems for years.

It is a vast oversimplification to say, “well just don’t do that”, because sometimes you have to.