Re: Please vote on the canvas accessibility proposal

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

Received on Wednesday, 24 February 2010 11:00:46 UTC