Re: Thoughts towards an accessible <canvas>

On Mar 23, 2009, at 08:15, John Foliot - WATS.ca wrote:

> Joshue O Connor wrote:
>>
>> 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.
>>
>> Josh
>>
>
> In light of the recent change from 'should' to 'must' (RFC 2119), if
> retrofitting the API is out of the question, then what exactly is  
> the plan
> to ensure conformance?  The HTML5 WG and WHAT WG have gone to great  
> pains to
> ensure that pages will conform, so please all, how or what is going  
> to be
> done to address this issue?
>
> The spec says 'must', thus you must.  If you do not, then what  
> happens?
> Logic can only lead to one conclusion, the page is non-conformant.   
> What is
> the price for non-conformance?  (Henri, your thoughts?)

I'm not sure why this question is addressed to me. Is it because I  
develop an HTML5 validator? Or because I've mentioned that the  
existing low-level accessibility API available to JavaScript is  
creating a DOM tree of <div>s and putting ARIA attributes on the nodes?

Also, it isn't quite clear what you mean when you say "conformance"  
here. I assume you mean that what is exposed to an accessibility API  
is consistent with the visualization painted on <canvas>.

Checking that a program uses an accessibility API in a way that is  
consistent with its use of an immediate-mode 2D drawing API is not a  
computable problem. So if the question was meant to me with my  
validator developer hat on, I think the issue is outside the realm of  
things that a validator computes. As Maciej pointed out, other  
programming environments that provide a 2D drawing API and an  
accessibility API do not try to enforce their consistent use.

It seems to me that cost of failing to program to an accessibility API  
in a way that exposes information consistently to what is painted  
visually using an immediate mode 2D drawing API is the cost of the  
application being inaccessible by people who can't use the visual  
output and would rely on the exposure of information through the  
accessibility API; see http://lists.w3.org/Archives/Public/public-html/2009Mar/0548.html

P.S. I haven't discussed the use of a <canvas> subtree of <div>s with  
ARIA attributes with developers using <canvas>, so I don't know if  
that approach actually would fit e.g. the Bespin case. Having a tree  
with <div>s with ARIA attributes is to accessibility what SVG is to 2D  
graphics, so the API models of <canvas> and an ARIA tree would be  
different. I'm not sure if it is even feasible to expose an even lower  
level accessibility API to Web content in a browser considering that  
an even lower-level API would entail an accessibility API client such  
as a screen reader calling into untrusted code (Web author-supplied  
JS) which could expose software stability issues.
-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 23 March 2009 12:29:07 UTC