Re: Example canvas element use - accessibility concerns

On Feb 18, 2009, at 10:05 AM, David Bolter wrote:

> Ben, a Bespin developer has written about some accessibility  
> thinking here:
>
> http://benzilla.galbraiths.org/2009/02/18/bespin-and-canvas-part-2/
>
> It seems reasonable to me. How do we move this conversation forward?


The downsides to a bespin-like approach to text editing go beyond  
accessibility. Operating systems provide quite a few built-in services  
for text, and it's hard to recapture them when doing raw text drawing  
onto a bitmap surface.

I tend to draw parallels to native APIs in cases like this. <canvas>  
is a raw drawing area. Most OS-level equivalents let you use  
additional low-level APIs to hook into accessibility, international  
text input, spellchecking and other system services. It makes sense to  
me to have some of these, to enable <canvas> to be more effective as a  
mechanism for bleeding-edge innovation on the Web. However, designing  
low-level APIs to handle these details in an OS-agnostic way is pretty  
challenging. This is why my initial reaction is to figure out what is  
inadequate about current HTML editing facilities for a project like  
Bespin and add the needed functionality. That's a conceptually simpler  
problem to tackle than "what are all the OS-level hooks you miss out  
on by doing your own text drawing and editing".

However, it seems to me that part of the reason Bespin was written the  
way it was is simply that the authors are comfortable with that style  
of programming and enjoyed writing it that way. Past experience with  
Java's 2D graphics APIs was cited. Consider that Bespin includes a  
canvas-rendered UI widget toolkit, and it seems to me that none of the  
arguments for <canvas>-based custom text editing really apply there.  
So we may actually need someone else to try to rebuild the Bespin  
experience in a non-<canvas>-based way and report the stumbling  
blocks. But I am not sure anyone will find that to be a fun and  
motivating project.

As to the specific proposal there, to have a hidden DOM under the  
canvas element, I'm not sure that is the best way to expose OS  
integration, not even just for accessibility. If such an approach  
works with acceptable accuracy and performance then it casts doubt on  
the motivation for using <canvas> at all; and in general having two  
completely separate ways of presenting the same content that must be  
kept in sync (even in the face of dynamic change) is likely to be  
error-prone.

Regards
Maciej

Received on Wednesday, 18 February 2009 18:47:35 UTC