- From: David Bolter <david.bolter@gmail.com>
- Date: Wed, 24 Feb 2010 09:40:40 -0500
- To: Steven Faulkner <faulkner.steve@gmail.com>
- CC: Charles McCathieNevile <chaals@opera.com>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>, public-canvas-api@w3.org
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:18 UTC