- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Wed, 18 Feb 2009 14:26:08 +0000
- To: Alexander Surkov <surkov.alexander@gmail.com>
- Cc: HTML WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>, Janina Sajka <janina@rednote.net>
- Message-ID: <55687cf80902180626l71365e68reaffee948dc0b2b4@mail.gmail.com>
Hi Alexander, I would suggest that it is the work of the HTML WG to specify a method to provide accessibility handlers for canvas content regards stevef 2009/2/18 Alexander Surkov <surkov.alexander@gmail.com> > I would guess canvas accessibility problem can be target for expert > handlers group (http://www.linuxfoundation.org/en/Accessibility/Handlers). > They develop plug-able mechanism to allow AT work with specialized > markups. In the case of Bespin we don't have specialized markup > actually, we have JavaScript code. Any way idea of plug-able mechanism > might work here. But it sounds Bespin guys don't care about > accessibility so I'm not sure they will be happy to create specialized > JS classes for AT assuming we have working plug-able mechanism :) > > Alex Surkov. > > > On Wed, Feb 18, 2009 at 8:12 PM, Steven Faulkner > <faulkner.steve@gmail.com> 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. > > > > The current advice on its use and provision of fallback content seems > > somewhat weak given the example of its use in Bespin: > > > > "Authors should not use the canvas element in a document when a more > > suitable element is available. For example, it is inappropriate to use a > > canvas element to render a page heading: if the desired presentation of > the > > heading is graphically intense, it should be marked up using appropriate > > elements (typically h1) and then styled using CSS and supporting > > technologies such as XBL. > > > > When authors use the canvas element, they should also provide content > that, > > when presented to the user, conveys essentially the same function or > purpose > > as the bitmap canvas. This content may be placed as content of the canvas > > element. The contents of the canvas element, if any, are the element's > > fallback content." [1] > > > > 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. > > > > [1] > http://www.w3.org/TR/html5/the-canvas-element.html#the-canvas-element > > > > -- > > with regards > > > > Steve Faulkner > > Technical Director - TPG Europe > > Director - Web Accessibility Tools Consortium > > > > www.paciellogroup.com | www.wat-c.org > > Web Accessibility Toolbar - > > http://www.paciellogroup.com/resources/wat-ie-about.html > > > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html
Received on Wednesday, 18 February 2009 14:26:51 UTC