- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 30 Jun 2011 09:18:39 -0700
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- Cc: public-canvas-api@w3.org, public-canvas-api-request@w3.org, Doug Schepers <schepers@w3.org>
On Thu, Jun 30, 2011 at 5:49 AM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote: > > Tab, > > You were explained to more than once what problems we are trying to solve. > > 1. We need a vehicle to tell an assistive technology the position and bounds of an object on the drawing space. > 2. In EVERY operating system since 1994 this has been tied to retained mode graphics information. In these systems hit testing was tied to the same information in retained mode graphics used to supply platform accessibility APIs. > 3. Authors have been asking for hit testing This is why I keep pounding on the "define the problems you're solving first" thing. You keep trying to jump straight to the solution. Your #1 and #3 are good problems to solve. Note that your #2 is suggesting that, based on history, a correct solution is likely going to be based on a retained-mode API. *I 100% agree.* However, without a proper list of problems, there's no way to evaluate the possible solutions. They may not even all be solved by the same thing. For example, hit-testing is a useful thing to solve. More importantly, it's: 1. Self-evidently useful to the author that needs it 2. Immediately apparent when you're doing it wrong 3. Completely safe to ignore if you don't need it for your app These three conditions make it *much* more acceptable to solve the problem by grafting an optional API onto the 2d context. If the author gets it wrong, they *know*, immediately, and it's a bug worth spending time fixing. If the author ignores it because they don't need it, that's completely fine, because it *doesn't hurt the user*. (It still doesn't mean this is the best solution, of course - "use SVG" may still be the right answer, possibly along with "let's fix your problems with SVG". Or "use this new canvas context designed to handle hit-testing well".) Your problem #1, though, meets *none* of those criteria. It's not obvious to the average author that it's important. If they're doing it wrong, they won't find out through normal app use (they'd have to explicitly test it with an AT). And if they ignore it, it hurts the user. The same applies to the problem I extracted from Charles Pritchard's link. Because they usually fail these three criteria, accessibility problems are simply harder to solve. You have to smuggle in their solutions so that they're solved automatically while the author is using the technology normally, solving problems that *do* meet the three criteria. This is not a point up for debate - it is a simple truth that, unfortunately, many people in this conversation seem not to recognize. Any solution that ignores this fact will end up a complete waste of time that doesn't actually measurably improve accessibility. ~TJ
Received on Thursday, 30 June 2011 16:19:39 UTC