- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 23 Mar 2009 00:44:25 -0700
- To: Charles McCathieNevile <chaals@opera.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 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. 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>. > 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. Regards, Maciej
Received on Monday, 23 March 2009 07:45:12 UTC