Re: Please vote on the canvas accessibility proposal

Hi Charles,

I support the idea of adding usemap to canvas as I have previousdly stated
and have filed a bug to this effect (
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9061). In another thread you
also mentioned that it works with opera 10.5, is that a partcular OS? as i
could not get it working on windows.


regards
stevef

On 24 February 2010 11:00, Charles McCathieNevile <chaals@opera.com> wrote:

> On Wed, 24 Feb 2010 08:31:52 +0100, Silvia Pfeiffer
>
>
> After having read the URL that you pointed to, it seems to me that
>> fallback content in canvas is different to fallback content in video.
>>
> ...
>
> It seems this is different for the Canvas since the canvas fallback
>> content can also provide focusable content.
>>
>> At this point, I actually wonder if the Canvas' fallback content is
>> not overloaded in meaning: it can both contain information for legacy
>> browsers and it can contain focusable elements for accessibility
>> reasons. I wonder if it would make sense to separate the two concepts
>> somehow. Maybe some markup that would be invisible on screen if the
>> canvas element is supported, but can still be accessed by the AT?
>>
>
> Yes, I think this makes sense
>
>
> Maybe it is possible to move the focusable elements into some other
>> subelement of Canvas (similar to how the video element has source
>> elements inside it)?
>>
>
> This is what the map element has been offering for most of the lifetime of
> HTML. And it works inside elements like object and canvas already. We had
> a bug on it for canvas that we have fixed in 10.50, and the other browsers
> I tested manage it, which is a lot more widespread than waiting for
> implementation of a new attribute that interferes in focus management.
>
> HTML 4.01, about a decade ago now, was specifically tweaked to match what
> browsers did, allowing for a mix of area elements or block elements.
>
> area elements have no visible rendering although they do have alt and can
> have title. They have an existing behaviour in the focus management and
> are handled by assistive technology, keyboard control of browsers, and
> anything else I can think of. Updating an area element to change its
> coordinates is pretty trivial if you are writing a dynamic canvas
> application where you are already calculating coordinates for painting.
>
> You can also have block content inside an image map. Which means,
> effectively, anything you want.
>
> So making your canvas accessible means providing information about what is
> happening inside it, and a way to interact with it that doesn't rely on
> the mouse. There is an authoring requirement here, that the author do the
> right thing. And it may be that they build some more complex set of DOM
> structures that have their own interaction behaviour, and don't need any
> markup stub.
>
> But it seems to me that map allows everything we might get from adom. You
> can build an structure that is not visible, allows you to dynamically
> interact with the canvas, attach information that can be rendered by AT,
> and has well-known focus management. And it's already described in
> tutorials, implemented in browsers, familiar to users, working in
> assistive technology.
>
> You can also build your fallback content inside canvas. If we reinstated
> the shape and coords attributes on the a element, which were there
> specifically to use block content instead of area elements in a map, we
> would offer the possibility of defining fallback content that included the
> hooks for making the canvas accessible - and thus allowing reuse of some of
> the script logic where the ability to use a canvas itself isn't completely
> integral to achieving the goals of the application. (E.g. a drawing
> application based in canvas should, but in all probability wouldn't, offer
> fallback with the accessible controls shared between the canvas and the
> fallback. But a canvas application for dynamically putting objects in an
> order the user likes could much more easily provide a fallback with shared
> controls).
>
> As a complicated thought experiment, imagine a Tetris game written in
> canvas. If you have something like
>
> <canvas usemap="#theMap">
>  <map name="theMap">
>    <area alt="current: L, pointing down, left 3 bottom 5" accesskey=" "
> onclick="drop()" shape.../>
>    <button onclick="spin(cc)" accesskey="z"><img src="ccButton"
> alt="counter-clockwise"/></a>
>    ...
>    <img alt="next: square block" .../>
>    [some description of the state of the blocks at the bottom already]
>  </map>
>  <script src="tetris.js"/>
> </canvas>
>
> And it is slow enough to move around and find what is happening, the script
> can pretty readily change the relevant bits of the map at the same time as
> it updates the graphical view. A bit more thought than the ten minutes that
> I put into this example might provide a parallel verbal tetris game if
> canvas doesn't work (or if someone is too good at it and wants more
> challenge), that wouldn't require any assistive technology to use...
>
>
> Note, I am trying to make suggestions not understanding all the
>> consequences, that I am sure you have thought through. However, I have
>> the impression that the @adom attribute doesn't actually help you
>> separate the overload issue: if @adom is given, the browser would
>> still display both, the text for legacy browser and the extra
>> focusable elements that at this stage relate to something that the
>> browser cannot visually present.
>>
>
> Yeah, I cannot actually see anything the adom attribute really adds.
>
> Steven F wrote
>>
>>> Silvia had written
>>>
>>> Is this because the AT doesn't support the canvas element yet? I would
>>>> think that it is expected of AT that supports HTML5 markup to ignore
>>>> "fallback" on an element that only applies to legacy browsers.
>>>>
>>>
>>> canvas is a visual element, like <img> AT such as screen readers cannot
>>> support it as such, but they can access alternatives if the browser that
>>> a person is using with their AT exposes the alternative.
>>>  Another example would be that the viusal aspects of a video are not
>>> accessible to a blind user, so she needs audio description provided as
>>> an alternative, even though the browser she is using supports the video
>>> element.
>>>
>>
> And, like video, whether the user has some particular assistive technology
> running doesn't (and shouldn't) determine whether the canvas or its fallback
> content is rendered (although following UAAG, the user should be able to
> turn the canvas off).
>
> cheers
>
> Chaals
>
> --
> Charles McCathieNevile  Opera Software, Standards Group
>      je parle français -- hablo español -- jeg lærer norsk
> http://my.opera.com/chaals       Try Opera: http://www.opera.com
>



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