Re: Please vote on the canvas accessibility proposal

Yes thanks Charles and Steve.

Whatever we decide regarding adom, I think this approach/technique 
should be supported and preserved as it covers a lot of ground quickly. 
I'm a bit concerned about how we would represent structural 
relationships that might exist visually in the canvas (and in the 
data/model). Adding ARIA to the elements inside the map to describe the 
structure might work... aria-owns, aria-posinset etc. not sure...

cheers,
David
On 24/02/10 6:11 AM, Steven Faulkner wrote:
> 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
>>
>>      
>
>
>

Received on Wednesday, 24 February 2010 14:41:21 UTC