Re: Example canvas element use - accessibility concerns

I think that Bespin is an example of 'look at what we can do with this
cool new element and its similar to stuff we have done before so we'll
give it a go'. For what it is, it's an impressive example as it's
important that people try push the envelope with new technologies.
Problems come to light when you look under the hood however and I agree
with many of Maciejs points below about how you could fix them.

Keeping <canvas> limited to just a /view/ of the content (one possible
view) would be the way forward, as David Bolter notes. The model should
be a foundation that supports multiple modes of interaction, not just
one. The problem is when the only view is the photon dependent one as
the magic of the web is that we are not just limited to that (nor should
we be).

The rub is when new technologies/methods of development etc gain ground
and popularity that are not only flawed but non-inclusive from the
start. No amount of bolt ons etc will fix the situation and
accessibility will only ever be a 'we're working on it' situation.


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.
> 
> Regards
> Maciej
> 
> 
>

Received on Friday, 20 February 2009 09:51:14 UTC