W3C home > Mailing lists > Public > public-html@w3.org > March 2009

Re: Thoughts towards an accessible <canvas>

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>
Message-ID: <op.uraypr0lwxe0ny@widsith.local>
On Mon, 23 Mar 2009 03:44:25 -0400, Maciej Stachowiak <mjs@apple.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.

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>.


>> 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).



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:20 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:44 UTC