Re: Helping Canvas Tag Be Accessible

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist

"Anne van Kesteren" <annevk@opera.com> wrote on 07/30/2009 08:10:49 AM:

> "Anne van Kesteren" <annevk@opera.com>
> 07/30/2009 08:10 AM
>
> To
>
> Richard Schwerdtfeger/Austin/IBM@IBMUS, "Steven Faulkner"
> <faulkner.steve@gmail.com>
>
> cc
>
> "HTML WG" <public-html@w3.org>, "W3C WAI-XTECH" <wai-xtech@w3.org>
>
> Subject
>
> Re: Helping Canvas Tag Be Accessible
>
> On Thu, 30 Jul 2009 14:50:45 +0200, Richard Schwerdtfeger
> <schwer@us.ibm.com> wrote:
> > In order to make canvas accessible we will need:
> >
> >    An object model to which authors can apply an accessibility API.
>
> Doesn't this defeat the whole idea of <canvas>? If you want an
> object model you could use SVG.
>
I agree but we cannot ensure authors will do the right thing. It is just a
fact of life. I ask why IBM product teams can't use Dojo components and
have to create their own equivalents for buttons, tab panels, etc.. I would
prefer that authors use SVG too.

>
> >    A collection of callback interfaces that can be applied to objects
to
> >    support an accessibility API mapping on each browser and platform
and
> >    potentially a vehicle to fire events to ATs.
>
> I'm not quite I follow this point.
>
So for anything that is a property (like and ARIA property) we could simply
provide set/get functions in canvas objects. When specific properties
change the browser fires an accessibility event. Pretty basic stuff.
However, for when it comes to text and tabular data this is not so simple.
Under the covers the browsers implement richer accessibility API for tables
and rich text that are bound to the corresponding data. That data includes
text, positioning information, caret position, selected text, table
headers, etc. In fact, both IE and FF bind text interfaces to text-related
data in contenteditable areas. The problem with <canvas> is that once you
draw the text the data is lost.

>
> >    A provision for equivalent alternative references that allow a
canvas
> >    author to specify an alternative resource for drawing that cannot be
> >    made accessible through traditional API.
>
> This is already possible. Just include content between the two tags
> of the element.
>
I need to look at this more. There may in fact be a need to pull in an
entirely alternative resource. Also, we need a vehicle to allow the browser
to choose which alternative to provide the users. For example, you may need
to interact with the alternative content between the <canvas> </canvas>
tags. How does the browser know which to render?
>
> > [...] For those who do not know this WCAG 1 required that you be
> > accessible with Script and CSS turned off in the browser.
>
> <canvas> is still compatible with that model as fallback must be
> shown if JavaScript is disabled. Having said that, since JavaScript
> is part of the semantics of a page that seems like an odd
> restriction to make, though probably in line with best practices of its
time.
>
I am not sure I follow you. JavaScript is not a semantic and we do not this
JavaScript restriction. The accessibility problem was never JavaScript.

>
> --
> Anne van Kesteren
> http://annevankesteren.nl/