Re: Thoughts towards an accessible <canvas>

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