- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Wed, 6 Jul 2011 20:58:07 -0500
- To: Charles Pritchard <chuck@jumis.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, public-canvas-api-request@w3.org, Doug Schepers <schepers@w3.org>
- Message-ID: <OFF5E647FB.B13DEFBB-ON862578C6.000A5F64-862578C6.000AD02B@us.ibm.com>
I agree. and title and description are insufficient for dynamically changing drawings. This is an SVG deficiency but NOT a canvas deficiency. Although important, the bounds of an object are only a piece of all the things to support interoperability. You need roles, relationships, state change notifications, and so on. We have those in canvas now. We do not in SVG. Let's stick to the problem at hand. ... canvas. Eventually we will get to SVG but not today. Canvas is part of HTML and it needs to be fixed. Rich Rich Schwerdtfeger CTO Accessibility Software Group From: Charles Pritchard <chuck@jumis.com> To: "Tab Atkins Jr." <jackalmage@gmail.com> Cc: Doug Schepers <schepers@w3.org>, "public-canvas-api@w3.org" <public-canvas-api@w3.org> Date: 07/06/2011 08:32 PM Subject: Re: You Got Your SVG in my Canvas! Mmm, Delicious! Sent by: public-canvas-api-request@w3.org "easiest solution" for whom? Other than politics, I don't see how this is the easiest. As others have pointed out, it is a diversion anyway. We're trying to finish the Issues with Canvas a11y that were brought up two years ago. "Don't use Canvas" is not a solution. I have surveyed developers, I've worked on AT and on implementations. Passing the path and bounding information via method call is quite easy for vendors, authors and spec editors. The difficulty here is entirely in the mind of those confused few who mistake this simple solution for something sinister. On Jul 6, 2011, at 6:15 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote: > On Sat, Jul 2, 2011 at 10:11 PM, Charles Pritchard <chuck@jumis.com> wrote: >> On 6/30/2011 3:13 PM, Tab Atkins Jr. wrote: >>> Sure. Here's a few use-cases that I've been able to extract from >>> emails in the threads: >>> >>> * Low- or no-vision users may have difficult reading text drawn into >>> an image. Solutions may involve keeping around the original text, so >>> it can be accessed by assistive technologies on demand. >>> >>> * Low- or no-vision users may have difficulty determining the >>> connections between far-flung sections of a complex image, such as a >>> graph, because they cannot easily assimilate the entire image's >>> information at once. Solutions may involve annotating sections of an >>> image with descriptions that can be accessed by assistive technology >>> on demand. >>> >>> * Low-vision users using a magnifier to aid in resolving details can't >>> see the entire application at once, and so don't know if something is >>> happening that requires their attention in a part of the application >>> that's not currently being magnified. Solutions may involve telling >>> the magnifier about active areas, so it can alert the user and >>> pan/zoom appropriately. >>> >>> Things of this nature are problems that can be solved, and we can >>> evaluate how well any given solution solves them. >>> >>> ~TJ >>> >> Thanks for supplying this. I missed it in my post earlier today. >> >> >> Let me know what kind of solutions you think are appropriate for these >> situations. >> I'm quite attached to binding to the DOM, because DOM elements >> have ARIA bindings (as well as data-* for intra-webapp communication). > > Honestly, I believe the easiest solution to all three of these > use-cases is to "use SVG", possibly paired with "add something to > SVG". #1 is solved automatically. I believe #2 is solved by the > <title> and <desc> elements. I think #3 is already solved by calling > .focus() on an SVG element; if not, it's pretty obvious that it would > be easy to solve in a similar way. > > ~TJ
Attachments
- image/gif attachment: graycol.gif
Received on Thursday, 7 July 2011 01:58:39 UTC