Re: hit testing and retained graphics

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 Friday, 1 July 2011 20:15:23 UTC