Re: Request for advice on <canvas> accessibility

there you go, shows how much i know about perusing HTML code, I missed the
headers in the table when i first looked :-)
so scratch "and provide column headers" advice.

regards
stevef


2009/7/11 Steven Faulkner <faulkner.steve@gmail.com>

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



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