Re: Thoughts towards an accessible <canvas>

On Sun, 22 Mar 2009 13:47:25 -0400, Maciej Stachowiak <mjs@apple.com>  
wrote:

> The <canvas> horse has long since left the barn. We are not up for  
> breaking existing deployed <canvas> content at this point.
[...]
> I could imagine trumping that principle if a truly  
> compatibility-breaking change was needed to even enable accessibility,  
> but that doesn't seem to be the case here.

Agreed.

> As to the proposal itself: <canvas> already has one way of providing an  
> accessible alternative, namely the nested fallback content. The proposal  
> adds three additional ways, makes one of the mandatory, and makes noting  
> the author mandatory.

Well, John's initial proposal does that. The discussion has already moved  
on from that though.

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

> That being said, I do think the accessibility story is weak for complex  
> content rendered using canvas. Traditionally, native development  
> platforms provide some degree of automatic high-level accessibility  
> support for built-in controls, and then a low-level accessibility API  
> for custom controls that developers build using drawing primitives and  
> events directly. The Web platform needs something similar. For images  
> that are generated on the fly, but thereafter not modified, a textual  
> alternative may suffice. For animated graphics demos, a description of  
> the demo could be enough. But for truly interactive application-like  
> content that is custom-rendered, a true accessibility API is needed, not  
> just an assortment of different textual alternatives.
>
> Henri has argued in the past that the way to provide this for <canvas>  
> is to apply ARIA markup to the fallback content. I am not 100% sure this  
> is sufficient for a complex tool like a text editor, but it seems to me  
> that Bespin could be a test case for this kind of approach (assuming  
> browsers expose the accessibility tree under <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...

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 Sunday, 22 March 2009 21:50:46 UTC