Re: Please vote on the canvas accessibility proposal

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.). Contextual information is
very important. You can try to reproduce all that with ARIA but it is a lot
more work

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


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