W3C home > Mailing lists > Public > public-html-a11y@w3.org > March 2011

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 9 Mar 2011 07:47:02 +1100
Message-ID: <AANLkTikWOJAGpCtKjwY+RMDv0ghQEZtr4=HkAyKi3rnj@mail.gmail.com>
To: Richard Schwerdtfeger <schwer@us.ibm.com>
Cc: public-html@w3.org, public-html-a11y@w3.org, Maciej Stachowiak <mjs@apple.com>, public-canvas-api@w3.org, Charles Pritchard <chuck@jumis.com>, david.bolter@gmail.com, franko@microsoft.com
I wonder: Is there any use for spatial media fragment URIs to solve
this? According to
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-space
you can basically specify a URL like this:
http://example.org/image.jpg#xywh=pixel:160,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...

Cheers,
Silvia.

On Wed, Mar 9, 2011 at 6:59 AM, Richard Schwerdtfeger <schwer@us.ibm.com> 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:47:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:33 GMT