Add support for binding to an element's own dom attributes about polymer HOT 11 CLOSED

This isn't working with class or aria-* tags

from polymer.

Can you please be more specific? Maybe give us an example of what you are trying to do?

This issue refers specifically to a feature that does not yet exist.

from polymer.

I'm trying to create a basic menu system in Polymer, with tags like <menubar>, <menubar-item>, <menupane>, <menupane-item>, etc.

I have attributes which correspond to the current state of the menu system. My attributes make sense to me, but additionally, I need to make this menu system ARIA-compliant. There's a spec on how to do this, with constraints on attributes and DOM structure: http://www.w3.org/TR/wai-aria-practices/#menu

it would be rather great if I could use data binding on custom elements to keep the ARIA tags up to date. If I could just declare "aria-expanded={{...}}" and "aria-haspopup={{..}}" and "aria-activedescendant={{..}}", etc. I don't need any of these properties to be settable or even observable, I just want a declarative way to define them.

I could get data binding by putting them elements on the shadow DOM, but

1. It's a big mystery as to what happens when aria attributes are in the shadow DOM. It's not part of the ARIA Spec. Some people have experimented with this on the internet and produced initial reports.
2. It's not in the spirit of ARIA to have ARIA information hidden in the shadows. It should be in the light DOM.

So I will likely have to code it up imperatively.

from polymer.

@jganetsk Please use code blocks for html tag names: <menubar>, <menubar-item>, <menupane>, <menupane-item>. Github treats them rather literally for markdown and they didn't show up for me.

You can add attributes you would like to be on instances of polymer elements by adding them to the <polymer-element> that defined them:

<polymer-element name="menu-bar" aria-expanded="false">
...
</polymer-element>

ARIA attributes are natively understood with ShadowDOM. This is exactly how Chrome handles <input type="date">and other native elements with ARIA attributes.

As for ARIA information in ShadowDOM not "being in the spirit" of ARIA, I disagree with that assertion, but I would leave that up to the Chrome Accessibility experts. We've been in multiple meetings with them before, and if I remember correctly, they were happy to have Custom Elements and ShadowDOM take some of the burden off of developers with the verbosity of ARIA completeness.

@alice, @dmazzoni-google, any comments to add about ARIA + ShadowDOM?

from polymer.

I'm very much a fan of custom elements taking ARIA burdens off of my shoulders. That's the very motivation behind custom elements here. But your example is not entirely appropriate in my case. In your example, your aria attributes are exactly where one would expect them to be... on the elements corresponding to inputs. In my example, however, since ARIA attributes for menus are very much tied to inter-component relationships (rather than internal component details), ShadowDOM is just a complication. To create elements inside of the ShadowDOM just to get data binding to work is annoying. Is it verbose to expose all this ARIA data? Is it nice to hide all of that in the ShadowDOM? Yes, but I don't think that's such a big deal.

http://blog.paciellogroup.com/2012/07/notes-on-web-components-aria/

from polymer.

Yes, ARIA attributes that correspond to IDs of other elements will not work between ShadowRoots because the IDs inside them are scoped.

This seems like a detail that could be fixed in ARIA v2 by supporting the whole range of selectors for those cases instead of just IDs (which seems rather brittle anyway).

In any case, this is just a feature request issue, so we'll keep this use case in mind as we develop this.

Thanks for the input.

from polymer.

Just a side note, <template> is where data binding is evaluated. It is not an implicit property of being in ShadowDOM.

In your index.html, this would work just the same

<!-- polymer is loaded above this -->
<template bind>
  <menu-label id="foo"></menu-label>
  <menu-bar aria-labeledby="{{ label }}"></menu-bar>
</template>
<script>
  document.querySelector('template').model = {label: "foo"};
</script>

from polymer.

Just addressing the issue of whether having ARIA attributes inside Shadow DOM is in the spirit of ARIA:

I think that having ARIA information in Shadow DOM (with the exception of IDREF across Shadow DOM boundaries) is fine - this is actually how the <input type="date"> element works in Chrome already. Have a look at http://jsfiddle.net/2WDsG/ in Developer Tools with Shadow DOM turned on, and you'll see something like

<span role="spinbutton" aria-valuetext="blank" aria-valuemin="1" aria-valuemax="12" aria-help="Month" part="-webkit-datetime-edit-month-field">mm</span>

in the Shadow DOM.

The way we've been looking at ARIA with respect to Custom Elements is that a similar philosophy should work - i.e. that the ARIA should be considered an implementation detail, and can go on any element that can take focus, whether inside the Shadow DOM or out.

(Edit: oh, I see Daniel made this example already - this is what I get for trying to write comments after getting off a 15 hour flight!)

from polymer.

@azakus If data binding occurs only inside of templates, it's confusing that the data binding syntax {{ ... }} is also used to wire up event handlers declaratively on polymer-element: http://www.polymer-project.org/polymer.html#declarative-event-mapping It led me to believe that data binding works on attributes there as well

@azakus @alice In this spec for ARIA practices of menus http://www.w3.org/TR/wai-aria-practices/#menu the phrases "DOM child" and "descendant" are used several times. I'm just confused now, because I don't know if these mentions refer to the composed DOM or to the light DOM. Or, perhaps I should build my menu framework such that it works around these rules, making DOM structure irrelevant, using aria-owns and other things?

@alice I have found that my needs for Shadow DOM here is minimal. I don't really need that many rectangles inside of rectangles. The custom menu and menu item elements themselves are enough. I'm not interested in creating Shadow DOM elements just as a place to stash my ARIA info inside of. I don't mind that the ARIA info is exposed to the world. But should I be? Is ARIA info clutter, and stashing into Shadow DOM the answer? Is this going to be good practice, moving forward?

@azakus Since you brought up that this is a feature request... let me tell you what I really want: as much declarative programming as possible. I want to use this data binding syntax everywhere. I'm still new to this stuff, and I'm learning that binding is intimately tied in with templates. I, however, feel like I already have too much imperative code, in the form of changed watchers, that I'd rather write declaratively.

from polymer.

On Mon, Dec 16, 2013 at 8:14 PM, jganetsk [email protected] wrote:

@azakus https://github.com/azakus @alice https://github.com/alice In
this spec for ARIA practices of menus
http://www.w3.org/TR/wai-aria-practices/#menu the phrases "DOM child" and
"descendant" are used several times. I'm just confused now, because I don't
know if these mentions refer to the composed DOM or to the light DOM. Or,
perhaps I should build my menu framework such that it works around these
rules, making DOM structure irrelevant, using aria-owns and other things?

ARIA predates web components by a lot, so this isn't really specified well
now.

In practice, browsers expose the composed DOM to assistive technology, so
if there's a descendant relationship between two nodes in the composed DOM,
many ARIA features should work.

Unfortunately, it's not possible for ARIA that requires an IDREF, like
aria-labelledby, aria-owns, or aria-activedescendant, to cross the shadow
DOM boundary. This may be addressed in a future spec, but i'd expect that
will be a while from now. Until then, I think the best solution is to try
to implement ARIA "composite controls" either entirely within shadow DOM,
or entirely outside.

@alice https://github.com/alice I have found that my needs for Shadow
DOM here is minimal. I don't really need that many rectangles inside of
rectangles. The custom menu and menu item elements themselves are enough.
I'm not interested in creating Shadow DOM elements just as a place to stash
my ARIA info somewhere. But should I be? Is this going to be good practice,
move forward? Is ARIA info clutter, and stashing into Shadow DOM the answer?

I think it depends on what you're doing. I think that if you're building a
reusable custom UI widget, stashing the ARIA inside the shadow DOM is
potentially a great idea, as it isolates the accessibility implementation
from the rest of the page and minimizes the chances of outside changes
accidentally breaking it.

If you're not building a full custom control, I don't think it's going to
be good practice. i don't think it's worth it just for encapsulation, but
that's just my opinion.

from polymer.

Closing this issue due to age and the release of version 1 release of Polymer - please feel free to re-open if this is incorrect.

from polymer.