Re: Request for advice on <canvas> accessibility

hi Ian,
>I've now done that; thanks for the advice. Is this really all that needs
 >to be done?

I would further suggest you could break the tables into years and provide
column headers. also you will need to place the table outside of the canvas
element, as currently (and for the foreseeable future) fallback inside the
canvas element is not exposed to AT in browsers that support canvas.

Providing a mechanism via the canvas API to automatically output the HTML
rather than having to develop a bolt-on generaion method would be an
improvement.

>It's what the HTML5 spec recommends today,

Which is why you chose the example.
In the simple case where canvas is used to generate a static image the best
solution may be the unfortunate bolt on option. a canvas API that generates
such HTML content  from inputted data  would make it much more likely that
such bolt-on fallback is provided.


>To be honest I think that the accessibility expertise of the WAI group is
 >far more important here than what little HTML engineering expertise I and
 >others may have. In this particular instance

You really sell yourself short Ian, IMHO your knowledge and understanding of
accessibility to be on par or greater than many of the so called experts
(including myself), and IMHO your HTML engineering expertise far exceeds any
of those people involved in the WAI groups, that I know of (including
myself). So IMHO and in conversations with the people you ccd on the email,
it is agreed we really need you to lead the development of an improved
canvas API, but of course we will help where we can.

> The example i posted yesterday http://tools.mozilla.com/ is not a demo
> and provides another example of a canvas containing interactive
> elements.

What can we provide to make this more accessible as is, without resorting
to the bolt-on fallback page?

ability to navigate and interact with the canvas content using the keyboard.
expose the name/role/states of interactive elements in the canvas to
accessibilty APIs

regards
stevef


2009/7/10 Ian Hickson <ian@hixie.ch>

> On Fri, 10 Jul 2009, Steve Faulkner wrote:
> >
> > The discussion on IRC last night was useful
> > http://krijnhoetmer.nl/irc-logs/whatwg/20090710#l-8, in that it started
> > to grapple with the issues of providing methods to allow developers to
> > provide objects in canvas with built in interaction behaviours,
> > something they could use in their course of their development without
> > having to think about how to add accessibility.
>
> Unfortunately that discussion only touched on the comparatively simple
> problem of keyboard focus. I agree that it was useful though. Is there an
> IRC channel where WAI members discuss similar issues? It would be really
> great to get input from the WAI members on how to address these issues.
>
>
> > > Is there some way to follow the WAI's work on this? What is the
> > > process by which the WAI can provide advice on such topics?
> >
> > Discussion will occur on wai-xtech and public html lists Though I think
> > that the technical progress will come more from those such as yourself
> > who have the most expertise in engineering HTML.
>
> To be honest I think that the accessibility expertise of the WAI group is
> far more important here than what little HTML engineering expertise I and
> others may have. In this particular instance, for example, I really have
> no idea how to truly make <canvas> accessible (short of the solution that
> is already in HTML5, which you have pointed out can best be described as a
> primitive example of "bolt on" accessibility).
>
> I was hoping that the WAI group would be able to suggest solutions that
> are better than this; the "HTML engineering" expertise side of things has
> so far failed to find any (except for the keyboard focus issue, which is a
> relatively simple issue in comparison).
>
>
> > > I'm certainly happy to look at other cases also. The main reason I
> > > suggested the HTML5 issues list graph:
> > > http://www.whatwg.org/issues/data.html
> >
> > The answer to making this accessible is to provide the data in html
> > format marked up as a data table.
>
> I've now done that; thanks for the advice. Is this really all that needs
> to be done? It's what the HTML5 spec recommends today, but I thought we
> were agreed that that was not enough, and that in fact that was an
> accessibility issue that needed resolving.
>
>
> > The example i posted yesterday http://tools.mozilla.com/ is not a demo
> > and provides another example of a canvas containing interactive
> > elements.
>
> What can we provide to make this more accessible as is, without resorting
> to the bolt-on fallback page?
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>



-- 
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