Write tests for input elements supplying name by aria-labelledby

[extra808]

Regardless of how an input element is named (implicit or explicit <label>, aria-label, aria-labelledby, etc.), or its input type, if another element references it using aria-labelledby, that name should be supplied.

Example, both elements, button and input, should be read as "Check A" by assistive technologies:

<button aria-labelledby="check-a"></button> <input id="check-a" type="checkbox"> <label for="check-a">Check A</label>

Related WebKit (on macOS) bug: 284774

[cookiecrook]

I haven't seen this pattern attempted before... @scottaohara @accdc @MelSumner do you agree?

In any case, writing a test to make sure all engines do the same thing seems reasonable to me.

[cookiecrook]

We'll also make sure the specs (AccName and/or HTML-AAM) explicitly acknowledge this expectation...

[cookiecrook]

mentioned in the ARIA WG meeting to get some more thoughts on this.

[MelSumner]

@cookiecrook I looked at the WebKit issue, which has a CodePen attached.

It took me a while to understand what was going on here, but I think in the end, the browser IS doing the correct thing.

If the button is saying that it's accessible name comes from an input element, and that input element has a state, having all of that information read out is expected behavior, I think.

If the author only wanted the label of the input element to be the accessible name of the button, then an id attribute should be placed on the label element and that's the value the button should reference.

It seems troublesome to expect otherwise.

[scottaohara]

we briefly talked about this in the call last week, and while not common, i have seen people try to do this before. use aria-labelledby on one element to try and reference the name of another element. what wasn't clear from this but was displayed in the codepen demo is that webkit isn't calculating the name in the way that was expected, and the value attribute of the checkbox is instead being used - and that does seem wrong. i can appreciate wanting to expose something, but the value attribute isn't always written for human understandability.

i've taken @extra808's simplified example in the initial post here, reversed it since otherwise we'd need to start at the last item and work backwards, and annotated it:

<label for="check-a">Check A</label>   
   <!-- label that names the checkbox.  expected name to provide: "Check A" -->

<input id="check-a" type="checkbox" value="1">  
  <!-- input named by its associated label element. Name = "Check A"  
          value is not an attribute meant to be exposed to the a11y tree -->

<button aria-labelledby="check-a"></button> 
  <!-- aria-labelledby points to the prior checkbox input with ID check-a
          that input has a name of "Check A" from its associated label element.
          However, Webkit (on macOS, NOT iOS) is giving this button a name of "1" from the input's value attribute,
          rather than using the accName of the input, supplied by its label element association -->

To compare:

• Webkit on macOS Safari 18.0.1 gives the button the accName of "1"
• Webkit on iOS 18.1.1 gives the button the name of "Check A"
• Gecko gives the button the accName of "Check A"
• Chromium gives the button the accName of "Check A"

Prior to testing this, I would have expected different browsers might handle this differently, and that arguably the guidance here could have revolved around trying not to chain together naming mechanisms like this. But per the above results, it seems that Safari on macOS is the odd one out. So it seems there is mostly alignment (that we should make a wpt for to solidify)

[MelSumner]

@scottaohara ok, with your context it makes sense. Thanks for clarifying.

I agree that there should be alignment.

[extra808]

Using the value of an input, instead of its node contents or name, in the aria-labelledby computation is supposed to be limited to those where the user can change the value.

https://w3c.github.io/accname/#comp_embedded_control

Users can't change the value of an individual checkbox or radio button.

I'm not going to test all form input elements but I did want to see how text inputs and selects are handled in practice.

aria-labelledby referencing inputs

The accessibility inspectors in Chrome, Firefox, and Safari for macOS are generally in agreement that the value (or text node of the selected <option>), not the accessible name, of such elements is supplied to aria-labelledby on a button. Safari (18.2 for macOS, 18.2.1 iOS) uses the name, not the value, when the input's name comes from aria-label, I think this is incorrect.