W3C home > Mailing lists > Public > wai-xtech@w3.org > February 2009

Re: Example canvas element use - accessibility concerns

From: Steven Faulkner <faulkner.steve@gmail.com>
Date: Wed, 18 Feb 2009 14:26:08 +0000
Message-ID: <55687cf80902180626l71365e68reaffee948dc0b2b4@mail.gmail.com>
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>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:16:01 GMT