Canvas positioning issue - possible solution (feedback requested).

One of the challenges we still have with Canvas accessibility is computing
a bounding rectangle for the accessibility API mapped to each object in the
fallback content. We have looked at:

- coords from image map: We feel this is too much work for authors.
- Use CSS positioning. This is inadequate as it only provides us with a
point and not the full rectangle,

We have had a number of discussions on this and we think the right way to
do this is to bind the element to a clipping region in canvas. This is also
consistent with how Windows and UNIX graphics subsystems started. You would
get a handle to a device context and apply a number of properties to it
including the bounding rectangle or clipping region. When assistive
technology first came out this device context was bound to an accessible
object and that is where the bounding rectangle would come from. It also
allowed the graphic subsystem to maintain the rectangle as things were
moved on the desktop. This same clipping rectangle was used in hit testing
for the mouse.

What we don't see is this facility in <canvas>. What we would like to see
happen is to provide a 2DCanvasAPI called setClickableRegion:

setClickableRegion(element) - Takes the current clip region and associates
it with the element in the fallback content. When the mouse is within the
hit test region the user agent the user agent can capture the appropriate
onclick, ondblclick, onmousedown, mouseover, onmousmove, onmouseout, and
onmouseup event in the region and passed to the associated element in
fallback content.

This would allow us to populate the accessibility API for that element and
it would solve a hit test problem for the associated element. Now you,
could basically have: <element ... onclick="drawButtonPress()");

This has two-fold benefit. It helps the accessibility issue we are having
and it provides a clicking.

We would like to hear feedback on this approach. Maciej, since Apple
created canvas we would like to hear your thoughts. We think this is a much
better approach than we have now. We would also need to examine other
events should be passed such as for touch.

Thanks,
Rich

Rich Schwerdtfeger
CTO Accessibility Software Group