- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 18 Feb 2009 10:30:10 -0800
- To: Philip Taylor <pjt47@cam.ac.uk>
- Cc: Steven Faulkner <faulkner.steve@gmail.com>, HTML WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>, Janina Sajka <janina@rednote.net>
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