- From: Doug Schepers <schepers@w3.org>
- Date: Thu, 30 Jun 2011 00:59:10 -0400
- To: public-canvas-api@w3.org
Hi, Rich- (Please reply to public-canvas-api... I've BCCed other related lists.) I agree with others on this list that a retained-mode Canvas API is a bit of a contradiction, and that SVG is better suited (designed, in fact) for retained-mode graphics. I agree with you and others that there should be a way for applications using Canvas to be made more accessible. I suggest that rather than adding more retained-mode shape features to the Canvas API or shadow tree, that we simply allow the SVG and Canvas to be used more seamlessly together. The SVG WG has discussed this in the past, and I think most of them would be open to this idea. I wrote up some more detailed notes on my blog [1], and I'm interested in hearing feedback from you and others. [1] http://schepers.cc/retain-a11y-immediately Bonus Link: http://www.youtube.com/watch?v=DJLDF6qZUX0 (Do not watch if you are allergic to peanuts or cheese.) Regards- -Doug Schepers W3C Staff Contact, SVG, WebApps, Web Events, and Audio WGs Richard Schwerdtfeger wrote (on 6/17/11 2:41 PM): > Charles, Frank, Mike, > > I am back from vacation. How far do we need to go with hit testing? > Right now I am looking at associating a closed draw path with a DOM > object in the canvas subtree. We would then need to address the routing > of pointing device input events to the DOM object. The drawing path can > be used to provide bound information to platform accessibility API. > > Do we need to bind any other drawing properties to the canvas object - > similar to the way device context's are handled on graphic subsystems > like Windows? > > Mike, I am including you as before I went on vacation you indicated that > a number of developers desired this feature and wanted to be involved. > > Rich > > > Rich Schwerdtfeger > CTO Accessibility Software Group >
Received on Thursday, 30 June 2011 04:59:18 UTC