Re: hit testing and retained graphics

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:
http://lists.w3.org/Archives/Public/public-canvas-api/2011AprJun/0047.html

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.

-Charles

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