Re: Please vote on the canvas accessibility proposal

On Wed, 24 Feb 2010 16:14:25 +0100, Richard Schwerdtfeger
<schwer@us.ibm.com> wrote:

>
> usemap has benefits and problems.
>
> benefits:
>
> - for basic controls like button, checkboxes, etc. it is great.
> - There are many ways it can be used for canvas today
>
> problems:
>
> - you can't use standard HTML input controls in it. For example, how do  
> you get at editable text?
> - You can't use the HTML DOM to provide structural information placing a
> greater burden on the author (tree widets, etc.).

If we return to HTML 4.01's image maps (which we specifically pushed to
have changed in order to make them support accessibility, although the use
cases at the time were a bit more simplistic), then you can easily do
those things.

> Contextual information is very important.

Sure. That's why I get annoyed at people who think that a random piece of
text somewhere on a page is automatically good enough to make a complex
image accessible.

> You can try to reproduce all that with ARIA but it is a lot more work

It is more work. But then, trying to build a visually rich application in
a scripting language is a lot of work too. You have to construct a model
of your own, and then represent it and maintain sufficient state if you
want interactivity. Compared to which, setting a few aria-attributes is
trivial - it is exactly the work you are already doing.

> It would be easier to use an imagemap as a technique in the subtree and
> simply set adom="true" when canvas is rendered..).

I don't think so. It's also pretty limiting as an approach. I might use
some controls which are common to the visual version of the canvas, the
extended (accessible) interface that goes beyond just click trapping, and
the fallback content that is offered if the canvas is not rendered in the
first place. adom doesn't help me do that, as I understand it, but using
existing HTML that is already possible.

cheers

Chaals

> Rich Schwerdtfeger
> Distinguished Engineer, SWG Accessibility Architect/Strategist
>
> public-canvas-api-request@w3.org wrote on 02/24/2010 05:11:02 AM:
>
>> Steven Faulkner <faulkner.steve@gmail.com>
>> Sent by: public-canvas-api-request@w3.org
>>
>> 02/24/2010 05:11 AM
>>
>> To
>>
>> Charles McCathieNevile <chaals@opera.com>
>>
>> cc
>>
>> Silvia Pfeiffer <silviapfeiffer1@gmail.com>, "public-html-
>> a11y@w3.org" <public-html-a11y@w3.org>, public-canvas-api@w3.org
>>
>> Subject
>>
>> 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


-- 
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 15:58:18 UTC