[whatwg/dom] label-input association across Shadow DOM boundary (#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](http://jsbin.com/liniser/1/edit?html,output)
    ```html
    <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](http://jsbin.com/gojusak/2/edit?html,output)
    ```html
    <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>`.
 
 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/530