How is the text alternative for a label element determined?

[JAWS-test]

<input id="test">

<label for="test">
  <span aria-labelledby="alb">span1</span>
  <span aria-label="al">span2</span>
</label>

<span id="alb">alb</span>

What is the name of the input?

• https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html: span1 al
• Chrome: alb al
• Firefox: span1 al
• IE 11: span1 span2
• Accname:
  • either: span1 span2 (step 2.D)
  • or: alb al (step 2.F)

I suspect that "alb al" is correct, so only Chrome does it correctly.

On the other hand, if we want aria-label to be allowed to be used within a label element, but not aria-labelledby, an appropriate exception should be inserted in step 2.B (then the output of Firefox would be correct): "and the current node is not already part of an aria-labelledby or label traversal"

[sinabahram]

One question. Why only Chrome, instead of Chrome and IE, since I’m reading that as Chrome and IE 11 do it correctly, since “span1 span2” was also valid per step D? I don’t agree with Firefox’s computed label here.

[JAWS-test]

One question. Why only Chrome, instead of Chrome and IE,

only one of both variants can be correct. I suspect Chrome, because I suspect that for label not only the text content should be used, but the text alternative, which results recursively from all descendant elements

[sinabahram]

I understand. Thanks for that. I completely blanked for a second and was just in a world where of course IE does that because of when it was last updated so it’s obvious that the answer of “alb al” is correct, but that it makes sense why IE says what it does. At any rate, the Chrome calculated label is definitely the right one in my opinion.

[accdc]

Hi,
The algorithm used should be the same as though aria-labelledby were being used instead of a matching for and id attribute, so both should result in the same thing.

In this case, the WhatSock computation is wrong and I need to fix that. Chrome is correct being "alb al".

I'll add this to my todo list for tomorrow to fix. :)

[JAWS-test]

@accdc

The algorithm used should be the same as though aria-labelledby were being used instead of a matching for and id attribute, so both should result in the same thing.

• this is not in the specification and should be added
• If this is true, then not Chrome would be correct but Firefox and your tool because of traversal: see example 1.

[accdc]

I see your point. We're going to have to talk that one out in our next meeting.

[accdc]

Hi, since the sound quality was horrible, I'll write out what I meant to ask during the call.

Specifically, it would be helpful to get feedback from @aleventhal, @cookiecrook, and @joanmarie about this topic, since it does impact the way the algorithm works as documented.

At present, AccName does not consider an explicit label, such as with matching for and id attributes, to function in the same manner as an aria-labelledby id reference iteration.

This means that a label may also include 1 or more aria-labelledby references within it, as long as they are not chained together.

So, the first question is, should this be allowed, when the functional behavior of a label works in the exact same manner as though it were being referenced origionally using aria-labelledby from the root node (input element)?

If no, it will change the AccName algorithm as it currently stands, because it will need to account for implicit labels such as when the label element wraps a form field, and also when role=label is used for the same purpose on supported ARIA widgets in the future.

Please let me know your thoughts.

Thanks,
Bryan

[cookiecrook]

The other thing to consider (and potentially note in the spec) is that the computed AccName is not always what the screen reader user will hear, even if the user agent exposes it correctly to the API. The screen reader itself can present something different. Sometimes this is on purpose, and more often it's a bug or oversight, but it does happen.

There may be some overlap here with the work @mcking65 and @zcorpan are attempting with ARIA-AT. Step 1: Is accessibility info making it to the API as expected? Step 2: Is the info being adequately conveyed to the user?

[cookiecrook]

@accdc I edited your comment to loop in the others mentioned, but can you clarify your pronouns? There are a number of references to "this" and "it" that make it difficult to understand exactly what you are asking.

[accdc]

Thanks, yes indeed.

To clarify, should the desired behavior, when processing the label element for a form field, function in the exact same manner as an aria-labelledby id reference if applied to the same element?

If yes, both of these examples should produce the same accessible name of "Label", and not "Label Content".

<input id="test" />
<label for="test"> Label <i aria-labelledby="extra"></i> </label>
<span id="extra">Content</span>

And

<input id="test" aria-labelledby="lbl" />
<span id="lbl"> Label <i aria-labelledby="extra"></i> </span>
<span id="extra">Content</span>

According to the AccName algorithm, the process for root node must only have one id ref traversal. So, should these be treated differently, or the same?

[accdc]

It's true that screen readers may report something different, but what I'm trying to determine is what user agents need to do under the hood for the accessibility tree, and to get agreement on this. This will be important for ensuring interoperability going forward.