Re: Canvas Accessibility Next steps

> The main area yet to be decided is how this should affect the focus 
> model.

I will say there is no <canvas> 2D  focus model except the general 
element focus model for the canvas element itself. I think the 
<canvas> element can get focus easily enough? That is all .. literally 
no focus model for pixels of the bitmap. No events in or out of the 
bitmap. So everything that must be done in this 2D context the way I 
understand it must all be sensed and handled from the outside and 
redrawn from the outside for every change. There is the idea that once 
a canvas2D is drawn, then if you want to change it, you draw it again 
in the new state. It sounds simple and it is, only much more fun in 
the long run if the thing is controllable from the inside which is not 
done in the canvas 2D context.

Canvas2D is intended to be simple and fun for some class of user in 
some class of operations. But providing an intensive interactive 
presentation needs more built-in power or else the authoring becomes 
burdensome, which is one Why for html, svg, and x3d with more 
connections behind the fairing.

That said, in the end, for most displays the embedded content all 
boils down to a 2D bitmap where the pointer position x,y can be sensed 
using host DOM tools external to the <canvas> or other element. Then, 
touch interactions can be modelled and acted upon by host DOM script. 
Even actually drawn as, or considered as, an overlay or maybe actually 
trigger redrawing the basic bitmap, or pieces of it, by a host DOM 
script.

So, it seems possible to construct an aria access DOM for any element 
that may have embedded content inaccessible to the user either because 
it needs alternative interfaces to be usable, or else as a next resort 
because the specified content just won't play here. This gets 
complicated fast, I think.
Much better to employ a context where lots of basic interactive stuff 
you wish to do is already built-in and can converse easily with the 
host DOM. But when the author's first choice is not viable, creating a 
model live access aria DOM as augmentation for the desired element 
just might work to get some carefully designed interactivity for 
embedded elements with choices of AT.

Thanks Again and Best Regards,
Joe

Received on Friday, 22 January 2010 00:02:06 UTC