- From: Alex Russell <alex@dojotoolkit.org>
- Date: Fri, 2 Sep 2011 18:39:51 -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>, Shane Stephens <shans@google.com>
On Fri, Sep 2, 2011 at 3:58 PM, Charles Pritchard <chuck@jumis.com> wrote: > 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. And Web Components is designed explicitly to work with it. > 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 > How should ATs be notified/detect that there is a shadow DOM? Focus works as it always has. It can move inside the shadow. > 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. >>> "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. > 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. Agreed. >>> 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. > 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. > 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? >>> 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. > 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 Saturday, 3 September 2011 01:40:47 UTC