Re: hit testing and retained graphics

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:51 UTC