Note: It's probably a good idea to generate a random ID for your label element that is unique to each instance. That way if you're in a browser that doesn't support Shadow DOM you won't end up with duplicate IDs being referenced by the for= attribute.
Hello Rob, sorry if the following question is already posted: Consider the following set up - two custom elements (rendering Name) (rendering ) The actual and HTML elements are both in their own shadow DOM. So, is there a way to achieve the following: clicking the to focus the ? (As you know with pure HTML elements this can be done by using the "for" attribute, pointing to the ID of the .)
very interesting. it seems like we're still missing a feature of labels... tapping them sometimes toggles values (check box, radio) or sets focus (inputs)... a while back I took a stab at a custom label element that tried to solve that problem. it also listened for focus events to it's target to support styling based on focus.
yep that's another awesome feature that we're missing out on :( A custom-element label would be great but I wish I didn't have to reinvent existing elements just to get one or two features. Hopefully future iterations of Custom Elements will allow this.
So I take it there's no way to have a label element in the HTML document itself and have that relationship automagically go into the Shadow DOM itself? Can the script in the component see/read if anything in the main document is somehow "pointing" to it and grab that text to populate its own visibly hidden label or aria-label ?
No, labels in the main document can't automagically affect stuff in the Shadow DOM. Yes the element could do something like that and I considered that approach. However, you'll also need to create a Mutation Observer to watch that label and update your own internal label anytime the external one's text changes. It felt a little too clunky so I opted for the custom label= attribute instead.
I don't think a distributed label will actually be able to label content in the Shadow DOM. Also if you're using for= you'd have to know the ID of the element you're labeling so that feels kind of like it would violate the encapsulation model.
Hi Rob: how about nested components like paper-input? For example, how to label this with shadow dom (describe native input with section1)? Identification In fact, chrome accesibility inspector does not resolve any of these aria attrs from paper-input-behavior: aria-describedby: paper-input-add-on-1 paper-input-add-on-2aria-labelledby: paper-input-label-3 From polymer shop app all these decorators are built-in components, there is not any reference to paper elements, so I assume that shadow dom has a very very big problem with a11y. If you look at shop-checkout element, you can see there are a lot of boilerplate code, only to decorate each input in the form, just the opposite to custom-elements. My working solution (using polymer 1.0: shadow dom v0) is to force use shady dom when user request a11y, otherwise use shadow dom (no a11y by default). By the way, great work with a11y polycasts!!!!
Note: It's probably a good idea to generate a random ID for your label element that is unique to each instance. That way if you're in a browser that doesn't support Shadow DOM you won't end up with duplicate IDs being referenced by the for= attribute.
Hello Rob,
sorry if the following question is already posted:
Consider the following set up
- two custom elements
(rendering Name)
(rendering )
The actual and HTML elements are both in their own shadow DOM.
So, is there a way to achieve the following:
clicking the to focus the ?
(As you know with pure HTML elements this can be done by using the "for" attribute, pointing to the ID of the .)
Very insightful! On top of the main topic, I learned about aria-labels!
I had been wondering about this for a while. Thanks!
I love your videos, everything is so clear and perfect!
very interesting. it seems like we're still missing a feature of labels... tapping them sometimes toggles values (check box, radio) or sets focus (inputs)... a while back I took a stab at a custom label element that tried to solve that problem. it also listened for focus events to it's target to support styling based on focus.
yep that's another awesome feature that we're missing out on :( A custom-element label would be great but I wish I didn't have to reinvent existing elements just to get one or two features. Hopefully future iterations of Custom Elements will allow this.
love all the cat art
So I take it there's no way to have a label element in the HTML document itself and have that relationship automagically go into the Shadow DOM itself? Can the script in the component see/read if anything in the main document is somehow "pointing" to it and grab that text to populate its own visibly hidden label or aria-label ?
No, labels in the main document can't automagically affect stuff in the Shadow DOM. Yes the element could do something like that and I considered that approach. However, you'll also need to create a Mutation Observer to watch that label and update your own internal label anytime the external one's text changes. It felt a little too clunky so I opted for the custom label= attribute instead.
Are these approaches preferred over passing the label element into the light dom? Then it would be progressive enhancement right?
I don't think a distributed label will actually be able to label content in the Shadow DOM. Also if you're using for= you'd have to know the ID of the element you're labeling so that feels kind of like it would violate the encapsulation model.
2:04 is there a way to do the opposite - affect an element outside the shadow DOM? For example change background-color of its parent element?
nope. That would violate the scoping model.
Hi Rob:
how about nested components like paper-input?
For example, how to label this with shadow dom (describe native input with section1)?
Identification
In fact, chrome accesibility inspector does not resolve any of these aria attrs from paper-input-behavior:
aria-describedby: paper-input-add-on-1 paper-input-add-on-2aria-labelledby: paper-input-label-3
From polymer shop app all these decorators are built-in
components, there is not any reference to paper elements, so I assume
that shadow dom has a very very big problem with a11y. If you look at
shop-checkout element, you can see there are a lot of boilerplate code,
only to decorate each input in the form, just the opposite to
custom-elements.
My working solution (using polymer 1.0: shadow
dom v0) is to force use shady dom when user request a11y, otherwise use
shadow dom (no a11y by default).
By the way, great work with a11y polycasts!!!!
Yeah I actually have a PR to start to address some of this. github.com/PolymerElements/paper-input/pull/549
#RIPPolycasts :D All joking aside, great video this was very helpful.
TFW you copy-paste your code and forget to edit the name of your end tag. This is the reason XHTML exists. ;)
yeah I noticed that after the fact. whaaaaatever :D
Apple's MacBook
Microsoft's IDE
Google's Browser
Did anyone else notice it ?