Re: Canvas positioning issue - possible solution (feedback requested).

I wonder: Is there any use for spatial media fragment URIs to solve
this? According to
you can basically specify a URL like this:,120,320,240 . Then you
could use an <img> element with a toDataURI from canvas to deal with
addressing a region in Canvas.

Just thinking out loud here...


On Wed, Mar 9, 2011 at 6:59 AM, Richard Schwerdtfeger <> wrote:
> 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

Received on Tuesday, 8 March 2011 20:48:56 UTC