moved from whatwg/dom#530

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>.