Re: Thoughts towards an accessible <canvas>

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