W3C home > Mailing lists > Public > public-canvas-api@w3.org > July to September 2011

Re: hit testing and retained graphics

From: Charles Pritchard <chuck@jumis.com>
Date: Fri, 1 Jul 2011 18:10:14 -0700
Message-Id: <5F0D1CC4-81AB-4A52-8E7C-C6C3C92E9469@jumis.com>
Cc: Richard Schwerdtfeger <schwer@us.ibm.com>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, "public-html@w3.org" <public-html@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>, "jbrewer@w3.org" <jbrewer@w3.org>
To: Edward O'Connor <eoconnor@apple.com>
I proposed such a path object in my post, as well as getCSSMatrix to expose the current CSS matrix. I also mentioned toString (stringify in webidl) and gave an example with isPointInPath. It is written in webidl and matches what you're putting forward. I'm glad we're converging on a consensus.

Look at the part about CanvasPath:

Please advise Ted, on how we can associate an element in the shadow Dom with a bounding box on the screen. This is vital to the operation of several ATs. All Accessibility Apis have a slot with which a bounding box is associated to an element. 

I have put forward the suggestion of simply extending aria; with something like aria-d="toString path data".

It does not have the benefits that Richard has put forward, it'd be slow/inefficient in dealing with animated data, but it would meet some bare minimum.

 I documented the benefits of having a path object in my post; glad we're moving forward... Let's keep moving forward on our accessibility commitments as well. Currently, the canvas spec supports keyboard a11y-- it does not support that last bit we need to move on. Shadow Dom nodes need a bounding box and future access to path data to work with various ATs on the market including VoiceOver and ZoomText.


On Jul 1, 2011, at 1:14 PM, Edward O'Connor <eoconnor@apple.com> wrote:

> Hi Richard,
> You wrote:
>> So, one could interpret your statements that Apple and Webkit
>> developers (this includes Google) support leaving canvas inaccessible
>> to people with disabilities.
> I don't think that's a fair interpretation of what I said, no.
>> So, if you exclude retained mode graphics features, here are the
>> options that are on the table Edward:
>> - apply an image map that an author must maintain on top of canvas.
> This has several downsides. One that comes to mind is the need for the
> page author to duplicate path information between their drawing code and
> the image map. There's no reason to believe that authors will keep the
> image map path info synched with what they're drawing.
>> - Write paths into the canvas subtree elements and maintain them as
>>  well as the transformations of the coordinates.
> This shares the above downside with the image map proposal.
>> - Do absolutely nothing and state that canvas will be inaccessible
>>  from here on out.
> I'd like to assume that anyone motivated to participate in this thread
> would reject this one. That said, our goal is to ensure the
> accessibility of the Web platform as a whole. Content authors can help
> to ensure the accessibility of their content by using the right Web
> platform tool for the right job. For instance, using <h1> for headings
> and not for "make this text bigger," and as another example, using SVG
> for complex, interactive, retained mode graphics, and not <canvas>.
> <hr>
> Here's a sketch of a simple-as-possible path object for enhanced hit
> testing support in <canvas> that may be more palatable to implementors.
> Suppose the 2d context API had a method to get the current path. An
> author calls this method after drawing some path onto the <canvas> and
> squirrels away the returned object foo. Later on, in a click handler on
> the <canvas>, the author can call foo.isPointInPath(x,y) to see if the
> click has happened in that path. Some things to note about this
> proposal:
> * There is no retention of the path data by the <canvas>. It doesn't
>  know where any of its pixel data came from, and it doesn't care.
> * The object isn't live; it doesn't automagically update as the
>  context's current path changes.
> * If multiple objects like this overlap, that's the author's problem;
>  <canvas> doesn't have any notion of which one wins / which one's "on
>  top."
> * There's no explicit association of this object to an element in the
>  shadow DOM, nor is there any kind of weird event propagation to the
>  shadow DOM. The author is responsible for doing the associating.
> * I don't think there's necessarily an existing data type that fits this
>  object very well. SVGPathElement is a full DOM element, which is
>  serious overkill for this. It might be nice to have a toString()
>  method on this object that generates the same syntax as SVG's d=""
>  attribute.
> * Along those lines, there are several other methods that would be
>  useful to have on such an object; I've tried to sketch out just the
>  bits needed for hit testing.
> Thoughts?
> Ted
Received on Saturday, 2 July 2011 01:10:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:10:31 UTC