- From: Alexander Surkov <surkov.alexander@gmail.com>
- Date: Wed, 18 Feb 2009 23:10:59 +0800
- To: Steven Faulkner <faulkner.steve@gmail.com>
- Cc: HTML WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>, Janina Sajka <janina@rednote.net>
Sure. Just I couldn't imagine the content conveys essentially the same function or purpose as the Bespin canvas. Are known any illustrative examples of canvas with content? Alex Surkov. On Wed, Feb 18, 2009 at 10:26 PM, Steven Faulkner <faulkner.steve@gmail.com> wrote: > 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 15:11:38 UTC