Re: You Got Your SVG in my Canvas! Mmm, Delicious! (was: hit testing and retained graphics)

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