label-input association across Shadow DOM boundary

[tomalec]

Currently, Shadow DOM make inputs and label elements inaccessible, if they are placed across the boundary.

Consider the cases:

1. <input> element is in shadow root (for example in a <custom-input> custom element). It is composed there with some styles and divs around, but there is no label for such input. Then I would like to create one in the light DOM.
   jsbin demo

   <label for="ccard">Card No</label>
   <card-input id="ccard">
   #shadowroot
       <input id="number-input">
   #/shadowroot
   </card-input>

2. <input> is in light DOM and we would like to add a label in its parent Shadow DOM
   jsbin demo

   <card-form>
   #shadowroot
       <label>Number<slot name="number"></slot></label>
       <label for="month">Month</label><slot name="month" id="month"></slot><label>Year</label><slot name="year"></slot>
   #/shadowroot
       <input slot="number">
       <input slot="month">
       <input slot="year">
   </card-form>

Now, the problem is to couple label with the input element, to get the native behavior of focus and other accessibility features.
Naturally without reimplementing it on my own.

I cannot do that as the assignment is done only via a string with an id of an element within the same tree.

---

For the first case, we could think of customized built-ins, but they are dead, we cannot assignShadow to an input element and it would be limited to custom elements only.

Even though I can (via inline script or custom element methods) find and match label and input, I'm still blocked, as control is read-only and there is no id of the element within the same tree I could give.

@robdodson made a nice a11y cast on how to hack it to make aria-label do the job, to make it work at least for screen readers. https://www.youtube.com/watch?v=rr3c62Wnaeo But:

• it doesn't solve the problem of actual <label> element which I would like to use for visual features and not limit myself to just stringified attribute.
• it requires a custom element and in fact, re-implementing label element feature in JS.

---

My naive solution to this would be to:

• solve the imperative case: make control writable, so I could pass a reference to an element from shadow/separate tree,
• solve the declarative case: let <slot> be a labelable element and delegate the search in distributed nodes, let shadow host be labelable, then it delegates the search in shadow root.

This one could be pretty tricky, as in fact it removes the need for labelable element, and opens a box of questions about cases like <label><shadow-host-with-control-and-label><input>.

[robdodson]

For what it's worth, AOM should help with this as well https://github.com/wicg/aom. It'll let you pass an object reference to an element which can be used as its label.

[annevk]

Thanks for filing this. A better place to file this would be at https://github.com/whatwg/html/issues/new as the DOM Standard doesn't really say how the label element needs to behave.

I suspect this would be problematic to fix as you want something that crosses the boundary (an extra complication might be that this also affects selectors). We generally decided that forms only work within the same tree. An input element inside a shadow tree also does not get submitted for instance. An alternative that might make sense and preserves the encapsulation boundary is that we allow a shadow host to be labeled, and that it can decide somehow who gets focus.

[tomalec]

Closing in favor to whatwg/html#3219