Re: Fw: Request to re-open issue 131 -USE CASES, USE CASES, USE CASES

On 12/20/11 2:22 AM, Jonas Sicking wrote:
> On Mon, Dec 19, 2011 at 1:19 PM, Richard Schwerdtfeger 
> <schwer@us.ibm.com <mailto:schwer@us.ibm.com>> wrote:
>
>     Do you support Frank moving forward with the setElementPath/hit
>     test proposal for the working group to review and are you still
>     supportive of having such an API for canvas?
>
>
> I honestly have lost track of what the latest proposal is at this 
> point. The main goal I have is to create an API which is simple enough 
> to use for people to want to do their own canvas hit-testing using the 
> API we provide. That is how we can get the most number of people to 
> use these APIs, and thus create the most accessible web.
>

Frank's comment for setElementPath(element):
http://www.w3.org/wiki/Canvas_hit_testing

Here is the bug report (scroll to bottom):
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13176


I spoke with several Canvas programmers, they felt that if hit testing 
were available in the API, they'd use it. They wanted it to be 
available. They're not particularly fascinated by the idea of using the 
DOM. I'm fascinated by the idea of using DOM+ARIA with Canvas as part of 
UI development. I think they'll be easily swayed once they start using it.

We had a many months discussion about use cases. Intuitively, I think 
most of us did not want to see additional complexity added to the Canvas 
specification. Hit testing is [was] a commonly requested feature by 
Canvas developers; many vendors saw it as an attempt to "bolt on" 
retained-mode semantics.

It's the DOM that does all of the retained-mode work.This is simply a 
means of "super charging" image maps. As I understand it, the only 
reason developers are getting this gift is because there's no practical 
solution to the accessibility issue, other than granting developers the 
ability to associate a region with a DOM node.

There are solutions other than this new method, but those solutions are 
not well integrated with Canvas and we can look at the past few years of 
Canvas development to see that a poorly integrated solution is a 
solution that is rarely implemented.



Here is an old summary of open Canvas a11y issues:
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0237.html

Many of those issues are about CSSOM and are not Canvas-specific. They 
came up during WCAG research.
There is another CSSOM shortcut, an extension of SVG pointer events into 
HTML:
http://lists.w3.org/Archives/Public/www-svg/2011Apr/0050.html

Those CSSOM issues can be taken up separately from the primary a11y 
concerns about legibility and positions.
They are mostly for speed and ease of use. The pointer-events proposal 
to www-svg is not for a11y, it's for speed.