Re: Example canvas element use - accessibility concerns

Maciej Stachowiak wrote:
>
> 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.
>

I think for the approach to work, the hidden DOM could be the "model",
and the canvas could merely be a photon dependent "view" -- in terms of
MVC pattern-speak (and to borrow a TV Raman phrase).

cheers,
David

Received on Wednesday, 18 February 2009 19:08:20 UTC