Re: Thoughts towards an accessible <canvas>

On Mar 22, 2009, at 3:13 AM, Joshue O Connor wrote:

> Maciej Stachowiak wrote:
>>
>> On Mar 19, 2009, at 8:34 AM, Charles McCathieNevile wrote:
>>
>>>
>>>> I propose that
>>>> any instance of <canvas> that lacks at a minimum the 2 proposed
>>>> mandatory
>>>> values be non-conformant and not render on screen. The inclusion  
>>>> of this
>>>> information should not be left to chance - the specification  
>>>> requires
>>>> that some fallback content exist - and if it does not exist then  
>>>> the
>>>> <canvas> element is incomplete, thus it should simply fail all  
>>>> users...
>>>
>>> I think that this is a non-starter. As explained in a narrower
>>> follow-up, the penalty to browsers who do this means that mainstream
>>> browsers simply won't, in all probability.
>>
>> I agree with Chaals on this. We would likely not be willing to stop
>> rendering existing <canvas> content in Safari.
>
> Yes, all the more reason to ensure that the API is suitable /before/  
> it
> leaves the stable so we are not facing a situation where we need to
> retrofit the API for accessibility.

The <canvas> horse has long since left the barn. We are not up for  
breaking existing deployed <canvas> content at this point.

I will note that we did break all existing <canvas> content once, to  
convert <canvas> from a void element to an element that can have  
children, in order to support fallback content for accessibility and  
graceful degradation. This change was made when <canvas> became part  
of HTML5. At the time, <canvas> was only really used in WebKit- 
specific Dashboard widget content, and it was clear this change was  
necessary to make <canvas> work on the public Web. All the same, it  
was quite painful, and we had to go to some lengths to get all content  
converted and to add compatibility hacks

Now that <canvas> has significant deployment in content on the public  
Web, I think it is too late to make any compatibility-breaking changes  
that make existing content not render. To do so would be in direct  
contradiction of the Support Existing Content design principle. 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.

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. This seems unhelpful to me. Content  
rendered to canvas does not need four different representations to  
assistive technology, it needs one good one. In addition, the author  
attribute and its additional status do not seem well thought out to  
me. A <canvas> element does not meaningfully have an author; it is the  
JavaScript code that draws into the canvas which may have one or more  
authors.

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

Regards,
Maciej

Received on Sunday, 22 March 2009 17:48:12 UTC