- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Mon, 22 Dec 2008 12:09:23 -0500
- To: David Bolter <david.bolter@utoronto.ca>
- Cc: "wai-xtech@w3.org" <wai-xtech@w3.org>
On 20 Dec 2008, at 10:26 AM, David Bolter wrote: > > Hi all, > > This might be an ARIA 2.0 thing. > > I'm just throwing this out there. Maybe it is my Saturday morning > coffee > talking but I got to thinking about DHTML inline edits, and I started > thinking of ways we might come up with a more general solution for > things that appear to transform themselves. Decidedly beyond 1.0. In the small, we will be dealing with the case you started with in the API-binding task force when the HTML5 "content editable" property has to be compared with @role="textbox." But ARIA 1.0 is wrapped pretty tightly around the [common core across APIs of] stuff that ATs already understand in the installed-code domain. So here there are mostly-rather-local widgets where some small structure of data are dynamic but the 'interface(s)' -- the pattern of methods and how they are engaged from the UI device suite -- stays static and is statically knowable by the one 'role' value. Objects that are like the 'transformers' toy of yore that present a whole new look and feel _locally, independent of the context_ are beyond the realm of what the AT have adaptation strategies for, and we aren't going to launch into that domain in 1.0. caveat: as I understand the roadmap, YMMV Al PS: The best analytical framework I can offer you for exploratory research to create the architecture for a more general approach is in our comments on the Multimodal-Interaction architecture and interfaces doc. http://lists.w3.org/Archives/Public/www-multimodal/2007Jun/att-0002/ Accessibility_Notes_on_MMI_Architecture.html and follow whatever the Ubiquitous Web Aps WG does with personalization. Maybe the highly-autonomous subdomains in a web page will do their own adaptation and view control. But the calculus of getting the view to be something the user can use is the same whether you are talking about a schema for HTTP request parameters or <object> parameters. We still need shared vocabularies to get the content and the user communicating. > > > aria-transforms=[aria role(s)] > > So in the case of an inline edit, one could mark the span like this: > > <span role="button" aria-transforms="textbox">change this text</span> > > Thoughts? Is it the coffee? I was also thinking about an > aria-hastextbox, akin to a haspopup, but that is a less general > solution > IMO. > > cheers, > David >
Received on Monday, 22 December 2008 17:10:06 UTC