Re: Helping Canvas Tag Be Accessible

On Aug 5, 2009, at 11:28 PM, Henri Sivonen wrote:

> On Aug 5, 2009, at 20:39, Charles McCathieNevile wrote:
>
>> On Wed, 05 Aug 2009 08:46:59 -0400, Henri Sivonen <hsivonen@iki.fi>  
>> wrote:
>>> * If the mapping from low-level platform APIs to a JS API is  
>>> direct, malicious or incompetently written scripts can tell AT  
>>> crazy things. Are ATs robust against apps telling them crazy  
>>> things? Does the browser need to be able to sanitize the  
>>> interaction instead of directly mapping the interfaces?
>>
>> This is a general problem. ATs and browsers have some rudimentary  
>> protection against crazy information (e.g. for the summary  
>> attribute), but there isn't a known general solution to this issue.  
>> I don't think that the risk of lazy, incompetent or malicious  
>> coding in canvas is likely to be far different from that in the  
>> rest of the web (i.e. I suspect it will probably be something like  
>> an order or two of magnitude more common than good practice). This  
>> is akin to "this doesn't open any *new* security holes" - it is a  
>> long way from perfect, but at least it enables us to do some useful  
>> things that we couldn't otherwise.
>
> I didn't mean "crazy" as in semantically incorrect as far as the  
> user is concerned. ARIA already provides enough rope for that. I'm  
> concerned about having untrusted and badly tested code talking more  
> directly to AT where AT might be written to assume it is talking  
> with trusted and tested code. That is, I'm concerned that a more  
> direct API could drive AT into untested states that could be crashy.
>
> Maybe this concern is a non-issue, and ATs are robust enough to  
> deal. How do Java applets, Flash and Silverlight deal with untrusted  
> code driving AT?

I'm not sure if Mac OS X's "AX" APIs and VoiceOver tool are robust  
against random data from untrusted sources.

However, I would also mention that the object model they reflect is  
not significantly lower level than DOM + ARIA. The only material  
difference is that the reflected tree of accessibility objects can be  
constructed lazily on demand. Mac OS X applications that do custom  
drawing are expected to use a model that is very much like DOM + ARIA  
to reflect their underlying object model to AT.

I am not certain of the need for a lower-level API to reflect UI  
structure to API. I think your longstanding idea of using a nested DOM  
tree with ARIA is quite plausible and could effectively reuse the ARIA  
code already in browsers. I'd like to see if that approach can be  
practically applied to some of the existing examples of interactive  
canvas content, before we go about designing a new API. Doing this  
exercise will show us what cases are unworkable, and thus better  
understand whether we need targeted additions or a whole new API.

The main thing I think is missing accessibility-wise from canvas is  
focus management. I think it's difficult if not impossible for custom- 
drawn pieces of the canvas to participate in the browser's tab cycle,  
or to effectively draw a native-looking focus indicator. This is an  
issue for any user who cannot effectively work with the mouse (or has  
limited ability to use the mouse) and thus needs keyboard navigation.

Regards,
Maciej

Received on Thursday, 6 August 2009 06:56:04 UTC