- From: Charles Pritchard <chuck@jumis.com>
- Date: Sat, 03 Sep 2011 11:46:21 -0700
- To: Alex Russell <alex@dojotoolkit.org>
- CC: Dimitri Glazkov <dglazkov@chromium.org>, Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>, Dominic Cooney <dominicc@chromium.org>, Shane Stephens <shans@google.com>
On 9/2/2011 6:39 PM, Alex Russell wrote: >> Similarly, WCAG is a series of principles for designing usable, high quality >> applications. >> >>> ARIA presents a set of semantic roles that don't exist in HTML, and >>> for those, alignment with custom element implementations is >>> outstanding. Components that express those semantics can use ARIA to >>> help communicate what they "mean", taking the burden off of the users >>> of the components to understand and manage the role/state groups. >>> >> When working with accessibility, it's super-set of HTML: >> img { role: 'img'; }; >> img[alt=""] { role: 'presentation'; } >> >> >> Yes, I'd like to see Components express aligned semantics, such as >> button:aria-pressed, >> in the shadow DOM. It's the same method we use with the Canvas subtree. > Pseudo-classes as a state mechanism need a lot more examination, > AFAICT. It's a non-extensible vocabulary, it doesn't appear to be > scriptable, and as a result, we haven't been able to use them to > handle things like states for animations (which should be transitions > between states in a node-graph). > > +shans I meant to short-hand the specs in the "HTML element to Accessibility API Role Mapping Matrix": http://dev.w3.org/html5/html-api-map/#api-role As evolved from: 2010: http://www.paciellogroup.com/blog/misc/HTML5/aria-html5-proposal.html 2009: http://dev.w3.org/html5/markup/aria/ I didn't mean to introduce a new state mechanism. CSS selectors already work with ARIA. With transitions, and generated content, CSS is quite flexible. This would work fine with transitions: div[aria-checked="true"] { content: 'Checked'; color: red;} div[aria-checked="false"] { content: 'Not Checked'; color: black; } I suspect we're talking about different things. >> How should ATs be notified/detect that there is a shadow DOM? > Focus works as it always has. It can move inside the shadow. Does the following statement make sense?: ATs that walk the DOM should check for element.shadow [currently webkitShadow], prior to looking for element.childNodes. >> I'd imagine the accessibility tree simply contains the appropriate data, >> but for ATs using simple DOM, and getAttribute, should they now check for >> a .shadow attribute on elements in addition to their usual heuristics? > That'll work for components with a public shadow, which I think will > be most of them. Components can also note state by setting role/state > directly on the outer component. What of components that contain multiple roles? Would those components, necessarily, require a public shadow? There was some discussion about allowing multiple children on the shadow. Perhaps this would be a good use case for it. >>>> "data-*" works for arbitrary metadata, and "aria-*" for UI semantics. >>>> >>> Yes! And for low-complexity tasks, they're perfect. For larger, >>> reusable components that need bundled behavior (Closure, JQuery UI, >>> Dijit), the task of setting up and managing all of this can be made >>> easier for users and developers of components by giving them a place >>> to hang behavior, shadow DOM, and data model concerns from. >>> >> We're certainly experimenting, with the Canvas tag and subtree. > The component approach turns this around, by letting you construct a > logical tree that might have<canvas> elements in the shadow, meaning > you don't need a "hidden tree" per sae. I like to think that it encapsulates current practice. I'm all for it. We still need a canvas subtree, to operate with the canvas 2d spec on drawFocusRing. >>>> 4. >>>> Let's look at the button example: >>>> >>>>>>> <button becomes="x-awesome-button">Weee!!</button> >>>>>>> Becomes: >>>>>>> <x-awesome-button>Weee!!</x-awesome-button> >>>>>>> >>>> For the sake of ATs, that should include ARIA semantics: >>>> <x-awesome-button role="button" tabindex="0"></x-awesome-botton> >>>> >>>> Now the OS and ATs think of that as a button, in every way that<button> >>>> would be. >>>> The UA, though, does not; it leaves it up to the scripting environment. >>>> >>> There's a lack of terseness here that's sort of concerning. One >>> possible way forward might be to use "role" as a shorthand for >>> "becomes" and allow components to register for roles which they >>> implement. Hmmm. >>> >> These extended attributes are something to be managed via script. You would >> not expect someone to author ARIA states into their static markup, though >> you would include roles. >> >> I do think shorthand is valuable. As I understand it, ARIA tries to stay out >> of the way. >> There is no current CSS+ARIA profile, it could be helpful if there were. > I think this gets back to the idea of "how does a component advertise > it's state?", and as far as I know, there's no unified approach in the > web platform. ARIA exists outside of the existing HTML pseudo-class > system. Anyone who wants to target states with CSS needs an extensible > vocabulary, and so a lot of stuff gets stuffed into CSS class names > too. Sort of mess today, and I'd love for us to find a way to unify > these theories of state. CSS selectors make this easy enough. ARIA has an extensible vocabulary, and CSS has an easy query language. ARIA is intended to advertise the state of a component. ATs need that information. It was designed to be extensible and non-intrusive. Yes, items are stuffed into CSS class names currently, as CSS selectors did not work with ARIA for some time. For compatibility, I end up with: <div class="ariaExpanded" aria-expanded="true" /> But, that's common for legacy support. For modern browsers, I can drop the class name. > >> I'm concerned (though I've not investigated), that adding additional >> behavior to role would be against the traditional non-interference of ARIA >> on host semantics. CSS on the other hand, certainly changes host semantics. >> >> "becomes" as an attribute representing a CSS+ARIA profile, could make some >> sense. It should give precedent to aria role over the tag name. >> >>>> It'd be darn-handy if the UA would enable additional markup, such that: >>>> <x-awesome-button role="button" style="appearance: button"> would >>>> inherit >>>> default events for buttons, >>>> >>> In our world, you'd just subclass from HTMLButtonElement in your >>> component definition to do this. >>> >>> Problem solved = ) >>> >> It's like that in C++ as well, for most of the browser vendors. >> >> There's just the issue with all-or-nothing/isolation of behavior. >> >> Thus the fears about accessibility of custom components: once you step >> outside the compiled browser behavior, you lose most of the work vendors put >> into the UA. > This is the problem that every JS-built component has today. Web > Components are a no-op as far as this is concerned. > >> How about:<x-awesome-button becomes="button">; incorporating both ARIA and >> HTML/CSS default events. > It's unclear why you need both. If x-awesome-button is built as a > Button subclass, it's all good. If you had<button > becomes="x-awesome-button">, then you might get some fallback behavior > for old UAs which might be a win, but tag nesting can get you there > too. Fallback behavior is a good thing. If element.tagName != 'BUTTON', and the element is a button, element.getAttribute('role') should return 'button'. >> This is something you'd only use in dynamic dom / shadow dom. Setting >> becomes would also set the role attribute on the tag. >> >> The static dom should still have<button>, or in the worst case,<div >> role="button">. > Not sure I understand this point. Can you clarify? When a document is laden with ARIA, most of that ARIA should be generated during run-time, by the scripting environment, the UA, and/or the AT. > >>>> For instance, when a user presses down, on the button, the UA would >>>> actually >>>> set the aria-pressed property >>>> if onmousedown does not run event.preventDefault(). There's precedent for >>>> this with textarea css resize. >>>> >>>> 5. >>>> Mozilla has gone ahead and allowed<input type="file"> to be completely >>>> embedded, receiving .click() delegates. >>>> <x-awesome-button role="button" >>>> onclick="this.getElementsByTagName('file')[0].click()"><input type="file" >>>> /></x-awesome-button> >>>> >>> I'm not sure I understand this point. Internally, browsers >>> differentiate from generated click events on security-sensitive >>> components and "real" click events. Are you suggesting we need >>> something to help handle this case? >>> >> I meant only to show that there is now precedent for completely hiding an >> interactive target element, such as input type="file". >> That example should have had:<input type="file" style="display: none;" />. >> >> As I understand it, that kind of construct:<div role="button"><input >> style="display: none;" /></div>, >> is a preview of what Web Components will handle. It would help to handle >> delegation of security-sensitive events. >> >> It'd really be helpful to be able to forward events, such as .click(). > In the WebKit implementation of shadow-DOM, we already handle such > forwarding correctly. Events that bubble out do "appear" to have come > from the component, not the item in the shadow DOM. How does this work on a complex element, containing multiple roles? It's important that event.target has an appropriate role. -Charles
Received on Saturday, 3 September 2011 18:47:01 UTC