- From: Charles Pritchard <chuck@jumis.com>
- Date: Fri, 02 Sep 2011 15:58:58 -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>
On 9/2/11 3:00 PM, Alex Russell wrote: > On Fri, Sep 2, 2011 at 1:40 PM, Charles Pritchard<chuck@jumis.com> wrote: > >> On 9/2/11 12:10 PM, Alex Russell wrote: >> >>> Since Dimitri has already said everything I would, and better, I just >>> want to very quickly second his point about where we are today vs. >>> where we fear we might be: non-trivial apps have *already* given up on >>> HTML. Suggesting that there's an un-semantic future that will be >>> *caused* by the component model is to fight a battle that's already >>> lost. >>> >>> The only question we need to answer now is: how do we repair the >>> situation? >>> >>> In spending the last 9 months thinking and working through the issues >>> Dimitri presents below, our strongest theory now is that there *is* a >>> market for semantics, that it *does* organize around winners (e.g., >>> Microformats), and that we're missing a mechanism for more directly >>> allowing authors to express their intent at app construction time in >>> ways that don't either pull them fully out of markup/html (see: >>> Closure, GWT, etc.). >>> >>> Instead of imagining total anarchy, imagine a world where something >>> like jquery-for-WebComponents comes along: a "winner" toolkit that a >>> statistically significant fraction of the web uses. Once that intent >>> is in markup and not code, it helps us set the agenda for the next >>> round of HTML's evolution. >>> >>> >> Alex, Dimitri: >> >> 1. >> I've found ARIA to be an appropriate microformat for new components. >> That is what it was designed for, after all. >> > ARIA is how we envision components developed in this world will > communicate with assistive technology. Nothing in Web Components is > designed to supplant or replace it. > I suggest looking at ARIA as more than a method for communicating with assistive technology. It's a means for communicating UI component states. 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. How should ATs be notified/detect that there is a shadow DOM? 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? >> "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. It seems like "event.preventDefault()" is an important hook to keep in mind. Is Web Components, in some manner, calling for a registerDefault method? >> 2. >> ARIA 1.0 may not be sufficient, but I do think it's been designed to be >> forward compatible, and "meta" compatible with HTML5. >> I can, for instance, use: role="spreadsheet grid" even though "spreadsheet" >> is not an ARIA 1.0 role; thus forward compatibility, and semantic lenience. >> > Nothing we're doing reduces the utility or need for ARIA. It works > *great* with these component types, and to the extent that we can > align them, I'm excited by how much easier it's going to be for > component authors to be, allowing them to focus on concerns like a11y > instead of "how do I get this thing to fly in the first place?" > I agree, I think it'll work great, and be easier. I'm hopeful there will be lessons to apply to an ARIA 1.1 spec. ARIA 1.0 has gone through a lot of work, but it hasn't gone through the rugged real-world testing of hundreds of thousands of programmers developing custom components. Authoring a spreadsheet component in ARIA is a mixed-bag. There are great items, lots of expressiveness, but also some areas that feel lacking. The spreadsheet widget metaphor has been around a long time, but it's open-ended in ways, much like rich text editing, and so, only by authoring, do we get an idea of the vocabulary. contentEditable could be wrapped as a web component. Rich text styles have long been in accessibility interfaces. >> 3. >> Let's look at how jquery "fails" to support ARIA, though it's an easy fix. >> Many jquery widgets have ARIA hooks in place. But what about jquery itself? >> $('#div').attr('role', 'button') vs $('#div').role('button'); >> $('#div').attr('aria-pressed','true') vs $('div').pressed(); >> Those later examples are what first class ARIA support would look like, in a >> JS framework. >> > The widgets themselves are the pattern that we'd like to bolster. What > low-level frameworks do is unchanged by any of this. > Makes sense. Low-level frameworks should pick up some of these semantics, so they may more easily work with Web Components and other ARIA-laden structures. > >> 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'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. How about: <x-awesome-button becomes="button">; incorporating both ARIA and HTML/CSS default events. 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">. >> 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(). Consider a "target" attribute, in addition to "becomes": <div becomes="file button" target="input"><input style="display: none;" type="file" /></div> That's certainly easier than setting up all of the click and focus handlers. It does have the negative effect of disabling file on non-supporting non-scripted environments. Something like this would still work, for such targets: <div becomes="file button" target="input" style="content: '' replaced;"><input type="file" /></div> If Web Components were integrated with CSS generated content, the content style could be improved: <div becomes="file button" target="input" style="content: component;"><input type="file" /></div> When the subtree is simple, the markup could be as well: <div becomes="file"><input type="file" /></div> At that point, we have reached similar proposals/solutions to these use cases, relying on the existing CSS generated content spec. <input type="file" style="content: url('myimage.png') replaced;" /> -Charles
Received on Friday, 2 September 2011 22:59:21 UTC