Re: Please vote on the canvas accessibility proposal

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist

public-html-a11y-request@w3.org wrote on 02/24/2010 09:57:29 AM:

> "Charles McCathieNevile" <chaals@opera.com>
> Sent by: public-html-a11y-request@w3.org
>
> 02/24/2010 09:57 AM
>
> To
>
> Richard Schwerdtfeger/Austin/IBM@IBMUS>
>
> cc
>
> public-canvas-api@w3.org, "public-html-a11y@w3.org"
<public-html-a11y@w3.org>
>
> Subject
>
> 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.
>
yes, and the subtree you could construct the same way. You could use a map
in the subtree and apply aria attributes as you indicate. And you could
probably reuse most if in fallback. I would just not limit the author to
use an area map. I do agree it is an excellent approach for a lot of
content. My hats off to the Opera team for identifying that as an
implementation.

> > 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.
>
It seems that that we are both talking about the issue of where the mapping
lies. Should adom take an id as a parameter vs. a boolean?

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