Custom delegation attributes

[bennypowers]

From the explainer:

<span id="foo">Description!</span>
<x-foo aria-label="Hello!" aria-describedby="foo">
  <template shadowroot="open" shadowrootdelegatesarialabel shadowrootdelegatesariadescribedby>
    <input id="input" autoarialabel autoariadescribedby />
    <span autoarialabel>Another target</span>
  </template>
</x-foo>

Consider if the author of x-foo already implements a label attribute.

<x-foo label="Hello!">

and they would like to use that value as the aria-label.

What about this api (imperative)

this.attachShadow({ mode: 'open', delgatesAriaLabel: 'label' })

or declarative (assuming #3)

<template shadowroot="open" delegates="label:arialabel">

[leobalter]

I'll mention this when syncing back with the AOM group.

My understanding is for the delegates* options to remain as booleans, based on delegatesFocus, and probably the consecutive delegatesLabel.

There is much we can optimize here on how we use but I need to understand what the implementation constraints are to keep the working path.

[mrego]

<x-foo label="Hello!">

What's the use case here?

As author of the custom element how are you using that label attribute? I guess you're somehow getting it from the shadow host and setting it somewhere in your shadow tree, why not do the same and set it also for aria-label in some of the internal elements?

Could you provide an example?

[bennypowers]

Sure, consider shoelaces' input, which uses the label attribute to label the control in the shadow root

https://shoelace.style/components/input?id=labels

[mrego]

In that case the web component itself is dealing with this.label internally and creating a label with it and so on.

Wouldn't the web component just set aria-label too on the internal input element?

That custom attribute is defined by the web component author, so I don't see why we need some kind of magic outside the web component like delegates="label:arialabel" for this? Maybe I'm missing some use case or not understanding this properly.

[clshortfuse]

I have a working use case of [label] vs [aria-label]:

Demo: https://clshortfuse.github.io/materialdesignweb/components/textinput.html

[label] refers to the label that floats above the input box (or in the outline region). [aria-label] is when the user does not want to place a visible label, but wants it to stay accessible. This is not uncommon with search boxes:

Placeholder is sometimes used as a label fallback, but that's not always proper. The placeholder is more a hint than a label. For example, my search box should probably be scripted as this:

<mdw-input type=search aria-label=Search placeholder="cat pictures" icon=search>

Visually, users can infer search based on the icon and its location. But for screen-readers, they need the aria-label.

In interest of thoroughness, here's what with a [label] tag instead of [aria-label] would look like:

[nolanlawson]

I tend to agree with @mrego that I don't really see how this use case aligns with cross-root aria delegation/reflection. The main issue here is that there is no actual crossing of ARIA roots – a label attribute is being passed in to the host, and that host can do whatever it wants with it, without referencing across shadow roots.

So e.g. for this example:

this.attachShadow({ mode: 'open', delegatesAriaLabel: 'label' })

There's no need for something like delegatesAriaLabel, because the host can just do:

connectedCallback() {
  this.shadowRoot.querySelector('input').ariaLabel = this.label
}

Is there a specific ask for the cross-root ARIA API? And how would it be an improvement over the above manual assignment of ariaLabel?

[nolanlawson]

Closing per discussion in cross-root ARIA F2F breakout, @bennypowers considers this issue covered by other proposals/issues.