- From: Alex Russell <alex@dojotoolkit.org>
- Date: Fri, 2 Sep 2011 15:00:30 -0700
- To: Charles Pritchard <chuck@jumis.com>
- Cc: Dimitri Glazkov <dglazkov@chromium.org>, Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>, Dominic Cooney <dominicc@chromium.org>
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. As someone who helped add ARIA support to a large framework, let me suggest that the goal here isn't to supplant what works, but to provide backbone and hooks into the parts of the system that don't. 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. Where ARIA exposes behavioral, cross-cutting roles, there should be no change in a world with Web Components. > "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. > 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?" > 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. > 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. > 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 = ) > 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? > ... > > This e-mail was heavy with examples, and my examples lately have been a > little loose. Let me know if there is any confusion on these.
Received on Friday, 2 September 2011 22:01:40 UTC