- From: Doug Schepers <schepers@w3.org>
- Date: Thu, 07 Jul 2011 13:07:17 -0400
- To: Steve Faulkner <faulkner.steve@gmail.com>
- CC: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, Charles Pritchard <chuck@jumis.com>, Henri Sivonen <hsivonen@iki.fi>, Sean Hayes <Sean.Hayes@microsoft.com>, "E.J. Zufelt" <everett@zufelt.ca>, Paul Bakaus <pbakaus@zynga.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, John Foliot <jfoliot@stanford.edu>, Charles McCathieNevile <chaals@opera.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, Cameron McCormack <cam@mcc.id.au>, Cynthia Shelly <cyns@microsoft.com>, "david.bolter@gmail.com" <david.bolter@gmail.com>, Frank Olivier <Frank.Olivier@microsoft.com>, "Mike@w3.org" <Mike@w3.org>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, "public-html@w3.org" <public-html@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
Hi, Steve- Steve Faulkner wrote (on 7/3/11 8:16 AM): > > For example if I increase the magnification in my browser to 200%, when an > element or object receives focus is offscreen, the view changes so it is no > longer offscreen. This does not happen if the objects are represented on the > canvas, regardless of whether they are local or remote. That's because "there is no there there". In a purely graphical display, as with the immediate-mode of the Canvas 2D API, there's no demarcated area for the magnifier to focus on. There are several solutions to this: 1) Make AT that is is "smart" enough to identify an important shape, zoom in on it, and track it if it is moving (this seems like a hard problem, but wouldn't need any changes to specs); 2) Make the shape, size, and position information available through a special accessibility API, updated and maintained in parallel to changes to the rendered shape; 3) Make the shape, size, and position information available through a standard API attached to a DOM element; some of the existing proposals on what this element could be include: 3a) an imagemap (HTML5 <map> element with <area shape="circle | rectangle | polygon">), updated and maintained by the author in parallel to changes to the rendered shape; 3b) a canvas subtree element (perhaps a <div>) with @aria-region, updated and maintained by the author in parallel to changes to the rendered shape (Cameron's proposal); 3c) a canvas subtree element with some other additional semantics, updated and maintained by the author in parallel to changes to the rendered shape, or perhaps automatically updated and maintained via the same API that the author uses to change the rendered shape (Charles and Rich's proposal; 3d) an SVG element, automatically updated and maintained via the same API that the author uses to change the rendered shape (Doug's proposal). I've already stated [1] why I think (3c) is seriously flawed as a general approach, in terms of scope, suitability (i.e. "does it solve the underlying problem"), and amenability to the majority of implementers. Obviously, I think my proposal has the most potential. [1] http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0093.html Regards- -Doug Schepers W3C Staff Contact, SVG, WebApps, Web Events, and Audio WGs
Received on Thursday, 7 July 2011 17:07:52 UTC