Consider: hidden <label> can still name associated form control

[scottaohara]

See also: w3c/accname#148

The intent here is to clarify in HTML AAM that a hidden <label> element which is associated with a form control should still take part in the accName calculation

e.g.,

<label hidden for=f>foo</label>
<input id=f>

the input should still have a name of "foo"

[stevefaulkner]

@scottaohara is this aspirational?

[scottaohara]

was discussed in the ARIA WG as something that isn't unreasonable to assume, and that there was desire for it re: accName spec as well.

[stevefaulkner]

yeah I agree it would be good, needs implementations no?

[sivakusayan]

Should this apply to any "Host Language Label element" (using language from the AccName spec)?
For example, if we had markup like the following:

<!-- Pretend this isn't a layout table -->
<table role="table">
  <caption aria-hidden="true">Caption</caption>
  ....
</table>

would it be expected that the table has an accessible name of "Caption", or would it be empty? There is a similar question that could be asked for fieldset and legend, and other similar cases.

[aleventhal]

I think it's an unintentional bug in Chrome that a hidden does not name the control it points to. I see it as being the same thing as a hidden node being pointed to by aria-labelledby. There's no reason to treat it differently.

[scottaohara]

i do wonder about @sivakusayan's example though.

i agree there are probably use cases for setting an element to display: none / visibility: hidden, but still want that element to contribute to the accname without having to use ARIA.

But if someone were to go ahead and put aria-hidden=true on a label, caption, legend... would it still name the element? that seems like possibly a good idea for users - but it defies the explicit use of aria-hidden=true by the author. If doing that, it's borderline saying that aria-hidden=true is not supported on those elements (if they are the only means of naming the associated form control, table, fieldset). i'm not saying that's good or bad. it's just an interesting wrinkle.

i guess the coutner argument there is that <span id=f aria-hidden=true>this works</span><input aria-labelledby=f>

so. meh?

[aleventhal]

Good question @sivakusayan. I suppose if we do nothing then we don't have to figure out the answer!

[scottaohara]

ok, fun fact:

<fieldset>
	<legend hidden>test</legend>
	<legend>i want this as the name</legend>
	<label>ex <input></label>
</fieldset>

chrome presently returns no name for this legend. though visually "i want this as the name" renders correctly as the legend of the fieldset.

[scottaohara]

bringing over jist of slack convo to here:

but maybe if this was just limited to labels and form controsl with an explicit association, this would make sense. but if this then has the trickle down effect of making it nebulous if other hidden elements should still participate in the name computation, it gets messy/unpredictable.

maybe it's enough that if you want to get a name from content that is specifically hidden form the a11y tree, that aria-labelledby. At least that is (fairly) straight forward guidance that then won't need a lot of special rules to determine if something is hidden because it needs to be the accname, but the author didn't want it visible for whatever reason. Or, is it hidden because the author needed to remove it (for reasons) and the only thing that was available to them was hiding the elment with CSS, or whatever.

To get something out of this, maybe it could be explicitly stated (here and accName) that naming content from hidden nodes can only be done with aria-labelledby?

The counter to this is someone figures out the various different corner cases (see fieldset example in my previous comment) where the hidden element should not provide the name.

[aleventhal]

Alright, let's add text to help authors know they should use aria-labelledby when the native markup name source is hidden. Or something along those lines.

I'm glad to not destabilize current implementations which are surprisingly consistent.

[adampage]

I recently worked on some WPT tests for the “hidden not referenced” portion of the accname spec, and the results are up on wpt.fyi. I haven’t fully digested this thread yet, but it already smells like an additional <label>-focused test could be helpful there, nevermind any spec clarifications that might come out of this. /cc @cookiecrook

[scottaohara]

from today's ARIA WG call, since this keeps coming up, probably best to add a note to HTML AAM that overtly states that if a label element is removed from the accessibility tree (e.g., hiding it) then it will not longer be able to provide a name to the input element that remains actually exposed by the browser

if someone really wants to hide a label and associate it with the input, then aria-labelledby is the way to do that, since it can reference a hidden element for force the browser to look into that element and retrieve its text.

[pkra]

Related WPT PR: web-platform-tests/wpt#44183

[accdc]

Yes please, explicitly clarifying that a hidden form field label element cannot be a valid label would be helpful.

[adampage]

I’ve also added some new WPT tests in web-platform-tests/wpt#44965 in support of #533.