- From: Charles McCathieNevile <chaals@opera.com>
- Date: Tue, 24 Mar 2009 11:30:53 -0400
- To: "Maciej Stachowiak" <mjs@apple.com>
- Cc: joshue.oconnor@ncbi.ie, "John Foliot - WATS.ca" <foliot@wats.ca>, Wai-Ig <w3c-wai-ig@w3.org>, wai-xtech@w3.org, "'HTMLWG'" <public-html@w3.org>, "WebAIM Discussion List" <webaim-forum@list.webaim.org>, Gawds_Discuss <gawds_discuss@yahoogroups.com>
On Mon, 23 Mar 2009 03:44:25 -0400, Maciej Stachowiak <mjs@apple.com> wrote: > > On Mar 22, 2009, at 2:48 PM, Charles McCathieNevile wrote: > >> >>> This seems unhelpful to me. Content rendered to canvas does not need >>> four different representations to assistive technology, it needs one >>> good one. >> >> Actually, I think it needs two - as noted in >> <http://www.w3.org/mid/op.uq4ivliowxe0ny@widsith.local> >> >> [[[ >> It boils down to the difference between what I want to hear when >> skimming, and what I want available if I am looking in detail at the >> content - just like a search results page doesn't present a whole page, >> but a simple snippet, whereas the whole page is what you want if you go >> to it. >> ]]] > > As also mentioned in the cited email, aria-describedby seems to handle > this need adequately. The interaction between aria-describedBy, the content of the element, and the title attribute can collectively handle this I think. > I'll add though that I'm not sure this is necessary in all cases or that > it is a canvas-specific need. An interactive control area made out of > DIVs may have as much (or as little) need for an additional summary as a > <canvas>. Absolutely. >> I think this identifies the complexity of the problem well. It is >> probably true that canvas is not a sensible way to build some things >> (text editors spring to my mind...) in order to easily make them >> accessible, but there are a lot of things that can be generated which >> could be auto-generating the fallback as well, using aria and simpler >> accessibility methods. >> >> Some of this work could probably be shifted to the browser, by >> specifying the accessibility API for the canvas itself - if this is a >> simple canvas tree then it is likely to be missing some of the info >> that would be required for orientation when you are accessing it via >> the accessibility API... > > I can tell you how this works in Cocoa, which has pretty good > accessibility APIs nowadays. By default, NSView objects (which represent > various controls) have a corresponding AXObject that holds the > accessibility info. It is possible to customize it. In addition, if you > are doing custom drawing, you can build your own AXObject tree that > represents the contents inside to assistive technologies. Note that no > attempt is made to tie these AXObjects to drawing commands, there is no > requirement to use any specific kind of model for your drawing, you just > build this separate tree and must coordinate it with your custom-drawn > content). > > I think Henri's suggestion (<canvas> contains a DOM subtree marked up > with ARIA) actually follows this model quite closely. The difference is > that, because DOM objects don't necessarily imply rendering and already > have a well-established API for accessibility via ARIA roles and > properties, there doesn't need to be a separate tree of accessibility > objects. Thus, I think the idea of DOM children of the canvas handling > accessibility state actually matches pretty well what a modern native > accessibility API would do. Yeah, this sounds like it makes sense (although I haven't looked into this in detail). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Received on Tuesday, 24 March 2009 15:33:19 UTC