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

Thanks Charles, good feedback. 
Ages ago we had some discussions around using image maps for canvas. For the record, I'm against this idea, as the HTML5 specification already has the (sensible) requirement of mapping canvas UI elements to elements in the DOM, and wiring up event/state synchronization between a canvas image map and the underlying DOM elements seems like even more work for the author.

From: Charles Pritchard [mailto:chuck@jumis.com] 
Sent: Tuesday, December 20, 2011 5:51 PM
To: Jonas Sicking
Cc: Richard Schwerdtfeger; Cynthia Shelly; david bolter; dbolter@mozilla.com; Frank Olivier; Maciej Stachowiak; Paul Cotton; public-canvas-api@w3.org; public-html@w3.org; public-html-a11y@w3.org; Sam Ruby; Steve Faulkner
Subject: 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> 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.

Received on Friday, 27 January 2012 02:36:02 UTC