search

w3c / accname

Accessible Name and Description Computation
https://w3c.github.io/accname/
61 stars 23 forks source link

Clarification of behavior for "native host language text alternative element" in step 2A #148

Open jaragunde opened 2 years ago

jaragunde commented 2 years ago

This is the relevant piece of text I would like to discuss, in step 2A:

If the current node is hidden and is not directly referenced by aria-labelledby or aria-describedby, nor directly referenced by a native host language text alternative element (e.g. label in HTML) or attribute, return the empty string.

While we have discussed a lot about the meaning on the clause referencing aria-labelledby/describedby in #57, I don't really understand what the other part means, about "directly referenced by a native host language text alternative element". I can think of this example:

<label for='box' hidden>foo</label>
<input id='box'>

In the example above, all main user agents produce an empty accessible name, so they wouldn't be following the spec text, or the text might not refer to this case.

A more convoluted example:

<label aria-labelledby="someHiddenElementElsewhere"><input></label>
<div id="someHiddenElementElsewhere" hidden>foo!</div>

This produces the accname "foo!" for the input in Chrome and WebKit, and empty in Firefox. But I'm not sure that the "directly referenced by a native host language text alternative element" text is meant to address this case, I see it more as a combination of steps 2B and 2E working together.

I would appreciate any thoughts on this. Thanks!

scottaohara commented 2 years ago

Interesting that with the second example the input gets its name. Not necessarily opposed to that, but seems an error correction since <label> would generally be an element that is prohibited by author naming via aria attributes.

i do see value in having a hidden <label> to name a form control. but i don't think that's 'expected' to work right now?

jaragunde commented 2 years ago

i do see value in having a hidden

Not expected to work (certainly not implemented), but UAs may already be hiding the label next to the control by default, to prevent double-speech of the label + the control. We certainly do that in Chromium in the most basic cases (checkboxes and text controls, IIRC). Screen readers do their fair share of correction, too.

That was an aside, anyway... In your opinion, that piece of text refers exactly to this, a hidden label being used to name a control?

aleventhal commented 2 years ago

I believe <label> should just be the inverse of aria-labelledby. It should work the same way. If the root is hidden, the name is still computed for the related control.

scottaohara commented 2 years ago

Related issue to make this clear in HTML AAM has been made. will try to get a PR done asap