Add delegatesLabel and a content attribute to specify the label element within a shadow tree

[rniwa]

During AOM F2F today, a common scenario of wanting to label a custom element but wanting that label to be delegated to a specific element within its shadow tree came up. In this case, when the label were to be activated, we want to activate the specific element within its shadow root instead, and the assistive technologies should be using the label for the same element instead of the entire shadow host or its shadow tree in its entirety.

We then came up with the idea of delegatesLabel which like delegatesFocus will delegate the label specified on a shadow host to a specific element within the shadow root. In order to define which element will get labeled on behalf of the shadow host, a content attribute (e.g. autofocus or labelfor) should also be added.

[michael-n-cooper]

APA says thanks for letting us know about this work. Do you need anything specifically from APA, or is this just FYI?

[rniwa]

APA says thanks for letting us know about this work. Do you need anything specifically from APA, or is this just FYI?

It's basically FYI but it would be good if you can comment if this will satisfy the use cases APA knows about.

[michael-n-cooper]

Ok, @AutoSponge will take a look at this.

[AutoSponge]

This appears to satisfy all of the use cases I can think of.

However, I anticipate matters of progressive enhancement/graceful degradation will restrict usage. Implementations in user agents without support for delegatesLabel would need to fall back to the host element's semantics and focus behavior or swap implementations behind a supports: 'delegatesLabel'-style query. For example, the degraded "date input" widget could accomplish all of the same behavior with :focus-within on a role=group in place of the input type=date.

APA should track progress and prepare a note to update heuristics such as "no interactive content descendant". See Allowed ARIA roles, states and properties.

Validators, such as validator.w3.org, may need extensive updates to address new element compositions. If user agent and AT implementations object to specific combinations of nested rules (e.g., button > button), implementors could create many accessibility issues unknowingly.

[joanmarie]

Is the proposed delegatesLabel specifically for aria-label (e.g. and not aria-labelledby); or is it more of a generic accessible name delegation?

[annevk]

I was under the impression this was specifically for the HTML label element so it could target a specific element within custom element's shadow tree.

[chrisdholt]

I was under the impression this was specifically for the HTML label element so it could target a specific element within custom element's shadow tree.

I think full support here would require more than simply support for the HTML label element as the label element itself does not work with ARIA radios or ARIA checkboxes (as an example).

I think additional support here is warranted for delegation of additional ARIA attributes. We have button web component which delegates focus to a native button so we can avoid reinventing the wheel while still getting all the benefits of custom elements, encapsulation, etc. While the label solves a big problem, it certainly doesn't solve every problem. Is there an issue tracking the delegation of additional attributes?

[annevk]

See #917 (though there has been other discussion about that too that I cannot find right now, perhaps it's in whatwg/html somewhere).

[leobalter]

I'm assigning this work to myself as discussed today at the AOM meeting. I don't have write permissions to do this formally in this github org, but this comment might be good enough for now.

My general understanding is that we don't have full consensus for this (yet) and the next step will be shaping the rough edges for a final workable solution, then specs.

I'll start this following the work on #917.

Thanks!

[keithamus]

WCCG had their spring F2F in which this was discussed. You can read the full notes of the discussion (#978 (comment)) in which this was discussed, heading entitled "ARIA Mixin & Cross Root ARIA" - where this issue was specifically discussed.

In the meeting, present members of WCCG reached a consensus to discuss further in breakout sessions. I'd like to call out that #1005 is the tracking issue for that breakout, in which this will likely be discussed.

[Westbrook]

With the advent of https://github.com/WICG/webcomponents/blob/gh-pages/proposals/reference-target-explainer.md it does sound like we need something like #1068 to support no ID referenced values in this way.

[Westbrook]

Seems covered by the Reference Target API.