Re: hit testing and retained graphics

I've concerns about this approach. It would mean the sub-tree is no longer
separably viewable -- though not implemented at the moment, it is still 
an option.
The other concern is resolution. A clickable area is more like an SVG 
path, not a CSS box.

It's quite possible that someone using an AT and a pointing device would 
be informed
by the AT that they are within the CSS box, but their pointer events 
would still lay outside
of the clickable path (processed by JS).

Using CSS box model may indeed be the option we go with, simply because 
we can not find
support in other areas. I'd still like to see a means for representing 
the path of the clickable area,
for ATs and developers alike. Doing that in CSS would mean introducing 
normalized svg path
semantics into CSS -- SVG is along way from doing that.

<div style="x...; y...; width.. height..;... box-path: ....;">

Any form of export to the DOM is likely going to use normalized paths,
introducing   toPathString and fromPathString semantics into Canvas 
would be a big
help regardless. As would getCSSMatrix.

-Charles


On 6/20/2011 8:57 AM, Frank Olivier wrote:
> I would leave hit testing up to the (javascript) author. I would recommend that they set existing x,y position, z-index attributes on the DOM objects in the canvas subtree to report what the UI 'looks like' to AT tools. This way, the AT tools don't need to change - this part of the DOM is no different to them than any other part - and authors need to be annotating canvas DOM objects with correct information anyway (labels, aria attributes, etc).
>
> From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
> Sent: Friday, June 17, 2011 11:42 AM
> To: chuck@jumis.com; Frank Olivier; Mike@w3.org; david.bolter@gmail.com; Cynthia Shelly
> Cc: public-canvas-api@w3.org; public-html-a11y@w3.org; public-html@w3.org
> Subject: hit testing and retained graphics
>
> Charles, Frank, Mike,
>
> I am back from vacation. How far do we need to go with hit testing? Right now I am looking at associating a closed draw path with a DOM object in the canvas subtree. We would then need to address the routing of pointing device input events to the DOM object. The drawing path can be used to provide bound information to platform accessibility API.
>
> Do we need to bind any other drawing properties to the canvas object - similar to the way device context's are handled on graphic subsystems like Windows?
>
> Mike, I am including you as before I went on vacation you indicated that a number of developers desired this feature and wanted to be involved.
>
> Rich
>
>
> Rich Schwerdtfeger
> CTO Accessibility Software Group

Received on Monday, 20 June 2011 16:07:57 UTC