label-input association across Shadow DOM boundary #3219
Comments
For what it's worth, AOM should help with this as well wicg/aom. It'll let you pass an object reference to an element which can be used as its label. |
Thanks for filing this. A better place to file this would be at whatwg/html/issues/new as the DOM Standard doesn't really say how the 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 |
If the AOM would be able to cross the boundary (which I hope it will), with for example Also, we are doing it imperatively and consciously. We are already crossing the boundary earlier, by getting the reference to the labelable in the (open) shadow: const labelable = host.shadowRoot.querySelector('input'); // <- we are breaking boundary already here and that's nothing new.
label.control = labelable; // <- that would be something new, but there boundary was already crossed.
Could you give an example?
But <label for="control">Label</label>
<form>
<input id="control">
</form>
👍 I believe that would be a great to have such a primitive to build web components that are able to extend the platform in area of labelable elements |
|
I would love this last suggestion
…On Thu, Nov 9, 2017, 3:02 PM Tomek Wytrębowicz ***@***.***> wrote:
I suspect this would be problematic to fix as you want something that
crosses the boundary
If the AOM would be able to cross the boundary (which I hope it will),
with for example .labeledby = referenceToLabelingNode, it would be
consistent to allow the same for <label> element as well. For a11y as
well as for the cases w/o the need for AT.
Also, we are doing it imperatively and consciously. We are already
crossing the boundary earlier, by getting the reference to the labelable in
the (open) shadow:
const labelable = host.shadowRoot.querySelector('input'); // <- we are breaking boundary already here and that's nothing new.
label.control = labelable; // <- that would be something new, but there boundary was already crossed.
an extra complication might be that this also affects selectors
Could you give an example?
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.
But <label> element for given labelable, does not have to be in the same
<form>, does it?
http://jsbin.com/nacihovumo/edit?html,output
<label for="control">Label</label>
<form>
<input id="control">
</form>
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.
👍 I believe that would be a great to have such a primitive to build web
components that are able to extend the platform in area of labelable
elements
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3219 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABBFDWWjn6Er2rGWWMWgMhOHfChcX-nwks5s04RzgaJpZM4QYw-3>
.
|
|
cc @whatwg/a11y |
Some questions we have encountered in figuring out the story in AOM:
|
n.b.: as currently specced, you would not pass a reference to an element, but to an attribute AccessibleNodeList? labelledBy;This also wouldn't create the association between the label element and its labelled control for activation behaviour. |
In my opinion, there are already too many ways to affect label of a control (for a11y and activation), introducing another one could make it even more confusing.
It looks consistent to me to no longer associate it. Similarly to when you set a
I'd say |
So the attribute would be deleted from the node? i.e. <label for="some-id">Banana</label> <!-- before -->
<label>Banana</label> <!-- after --> |
|
The way I imagine it: <label for="foo">Label</label>
<script>
const label = document.querySelector('label');
label.control = elementWithoutID;
// label.htmlForElement = elementWithoutID;
assert(label.getAttribute('for') === elementWithoutID.getAttribute('id'));
assert(label.getAttribute('for') === null);
// <label>Label</label>
label.control = elementInSameTreeWithID;
// label.htmlForElement = elementInSameTreeWithID;
assert(label.getAttribute('for') === elementInSameTreeWithID.getAttribute('id'));
assert(label.getAttribute('for') === 'bar');
// <label for="bar">Label</label>
label.control = elementFromDifferentTree;
// label.htmlForElement = elementFromDifferentTree;
assert(label.getAttribute('for') === null);
// <label>Label</label>
</script> |
|
TPAC F2F note: This will be discussed along with WICG/webcomponents#179. |
|
Rough consensus at TPAC F2F: This can be spec'ed using a delegation mechanism for a label or as a part of making custom element a form control. |
|
Various ideas that were thrown out:
|
|
@rniwa <label for="lightId">Foo</label>
<div id="shadowHost">
</div>
<script>
shadowHost.attachShadow({delagateLabelable: 'shadowId'})
.innerHTML = '<input id="shadowId">';
</script>What should in such case be the value of
|
|
I think we can spec it to be either the actual label element or empty. I don't think making it the shadow host makes much sense since that's not all what's labeling the input element. |
Originally, when we started writing this component, we wanted to give an example of making the component _accessible_ and using semantic HTML. However, we've kind of been brought to a halt on this because apparenty a11y gets VERY complicated when it comes to ARIA attributes that try to reach for elements across the ShadowBoundary. We don't really want to present people with something that's inaccessible, because it won't be good for their users and it won't give them good solutions or best practices. So... for now we're stashing our work. If we can come up with something that makes the Custom Select Component accessible, we'll return to our efforts here. Until then, we'll probably do some cleanup in the SuperTokens examples or in the package that we have not yet released. For anyone looking at this code, please bear in mind that it is incomplete. Feature-wise, it's probably at least 75% done if you wanted to take it for a spin. If you don't care about a11y, it is still very possible and easy to finishe building out this component. Future Note: Can't use `onblur` for the combobox. We need to use a different kind of listener so that users can select options by clicking them. For A11y Issues, See: - https://nolanlawson.com/2022/11/28/shadow-dom-and-accessibility-the-trouble-with-aria/ - whatwg/html#3219
Originally, when we started writing this component, we wanted to give an example of making the component _accessible_ and using semantic HTML. However, we've kind of been brought to a halt on this because apparenty a11y gets VERY complicated when it comes to ARIA attributes that try to reach for elements across the ShadowBoundary. We don't really want to present people with something that's inaccessible, because it won't be good for their users and it won't give them good solutions or best practices. So... for now we're stashing our work. If we can come up with something that makes the Custom Select Component accessible, we'll return to our efforts here. Until then, we'll probably do some cleanup in the SuperTokens examples or in the package that we have not yet released. For anyone looking at this code, please bear in mind that it is incomplete. Feature-wise, it's probably at least 75% done if you wanted to take it for a spin. If you don't care about a11y, it is still very possible and easy to finish building out this component. Future Note: Can't use `onblur` for the combobox. We need to use a different kind of listener so that users can select options by clicking them. For A11y Issues, See: - https://nolanlawson.com/2022/11/28/shadow-dom-and-accessibility-the-trouble-with-aria/ - whatwg/html#3219
Originally, when we started writing this component, we wanted to give an example of making the component _accessible_ and using semantic HTML. However, we've kind of been brought to a halt on this because apparenty a11y gets VERY complicated when it comes to ARIA attributes that try to reach for elements across the ShadowBoundary. We don't really want to present people with something that's inaccessible, because it won't be good for their users and it won't give them good solutions or best practices. So... for now we're stashing our work. If we can come up with something that makes the Custom Select Component accessible, we'll return to our efforts here. Until then, we'll probably do some cleanup in the SuperTokens examples or in the package that we have not yet released. For anyone looking at this code, please bear in mind that it is incomplete. Feature-wise, it's probably at least 75% done if you wanted to take it for a spin. If you don't care about a11y, it is still very possible and easy to finish building out this component. Future Note: Can't use `onblur` for the combobox. We need to use a different kind of listener so that users can select options by clicking them. For A11y Issues, See: - https://nolanlawson.com/2022/11/28/shadow-dom-and-accessibility-the-trouble-with-aria/ - whatwg/html#3219
Originally, when we started writing this component, we wanted to give an example of making the component _accessible_ and using semantic HTML. However, we've kind of been brought to a halt on this because apparenty a11y gets VERY complicated when it comes to ARIA attributes that try to reach for elements across the ShadowBoundary. We don't really want to present people with something that's inaccessible, because it won't be good for their users and it won't give them good solutions or best practices. So... for now we're stashing our work. If we can come up with something that makes the Custom Select Component accessible, we'll return to our efforts here. Until then, we'll probably do some cleanup in the SuperTokens examples or in the package that we have not yet released. For anyone looking at this code, please bear in mind that it is incomplete. Feature-wise, it's probably at least 75% done if you wanted to take it for a spin. If you don't care about a11y, it is still very possible and easy to finish building out this component. Future Note: Can't use `onblur` for the combobox. We need to use a different kind of listener so that users can select options by clicking them. For A11y Issues, See: - https://nolanlawson.com/2022/11/28/shadow-dom-and-accessibility-the-trouble-with-aria/ - whatwg/html#3219
Currently, Shadow DOM make inputs and label elements inaccessible, if they are placed across the boundary.
Consider the cases:
<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
<input>is in light DOM and we would like to add a label in its parent Shadow DOMjsbin demo
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
assignShadowto aninputelement 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
controlis 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:
<label>element which I would like to use for visual features and not limit myself to just stringified attribute.labelelement feature in JS.My naive solution to this would be to:
controlwritable, so I could pass a reference to an element from shadow/separate tree,<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
labelableelement, and opens a box of questions about cases like<label><shadow-host-with-control-and-label><input>.The text was updated successfully, but these errors were encountered: