Re: Example canvas element use - accessibility concerns

On Feb 18, 2009, at 6:52 AM, Philip Taylor wrote:

> Steven Faulkner wrote:
>> The recently released code editor Bespin (
>> https://bespin.mozilla.com/index.html) is a great example of the  
>> utility of
>> the canvas element, its also a worrying example of the barriers to
>> accessibility its use will produce. It includes editable text,  
>> folder lists
>> and interactive elements that are all essentially a graphic. there  
>> does not
>> appear to be a way to extract any usable information to support  
>> Assistive
>> technology to interpret or provide interaction.
>> [...]
>> Are there plans to provide mechanisms to add accessibility hooks  
>> for content
>> produced using canvas? As providing a secondary accessible version  
>> of an
>> application such as bespin seems like a non starter, and is a prime  
>> example
>> of the sort of "bolt on" accessibility that HTML5 was trying to  
>> move away
>> from.
>
> As far as I can tell, the non-bolted-on accessible way to implement  
> Bespin would be using HTML (with textarea, contenteditable, etc) and  
> CSS, not canvas. Its current use of canvas hurts fully-capable  
> graphical browsers too, e.g. I can't copy-and-paste text between  
> Bespin and any other application, and I can't edit its text with my  
> OS's usual key bindings.
>
> http://benzilla.galbraiths.org/2009/02/17/bespin-and-canvas/  
> indicates that canvas was chosen because of concerns over the  
> performance and controllability of other solutions. It'd be good to  
> see if those concerns could be addressed in the long term by changes  
> to the specs or by fixing browser bugs, to remove the reasons for  
> inappropriately using canvas.

I have the same reaction. One key thing we can learn from Bespin is  
what kinds of limitations are present in HTML/CSS editing that would  
make it hard to write such an application. For comparison, on Mac OS  
X, NSTextView provides enough flexibility that nearly all applications  
use it for their text editing, even if they have extremely specialized  
needs or want to support a lot of customization. Very few roll their  
own text editing from keyboard input and text drawing directly; those  
that do are usually implementing an additional general-purpose layout  
engine that supports text editing. So clearly it's possible to have  
text editing facilities that meet a wide range of needs, while by  
default providing good integration with system services  
(accessibility, spellchecking, grammar checking, system-wide  
keybinding customization, services menu, international text input via  
inline input methods, etc). I hope we can make the Web's editing  
capabilities meet that standard.

Regards,
Maciej

Received on Wednesday, 18 February 2009 18:31:16 UTC