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

You are wasting people's time and going around in circles - just like Ian.
You know nothing about accessibility and what is important for
accessibility.

Rich Schwerdtfeger
CTO Accessibility Software Group

public-canvas-api-request@w3.org wrote on 06/30/2011 01:52:48 PM:

> From: "Tab Atkins Jr." <jackalmage@gmail.com>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Cc: Paul Bakaus <pbakaus@zynga.com>, public-canvas-api@w3.org,
> public-canvas-api-request@w3.org, Doug Schepers <schepers@w3.org>
> Date: 06/30/2011 01:54 PM
> Subject: Re: You Got Your SVG in my Canvas! Mmm, Delicious! (was:
> hit testing  and retained graphics)
> Sent by: public-canvas-api-request@w3.org
>
> On Thu, Jun 30, 2011 at 11:39 AM, Richard Schwerdtfeger
> <schwer@us.ibm.com> wrote:
> > "Tab Atkins Jr." <jackalmage@gmail.com> wrote on 06/30/2011 12:53:34
PM:
> >> Again, define your problems. Making your average game, such as the
> >> ones produced by Zynga, accessible to the blind, for example, can
> >> *not* be accomplished by exposing an alternate subtree. It can
> >> theoretically be done, but only be exposing completely different
> >> interaction modes, which are most likely fairly tightly coupled with
> >> the design of the game itself. Different disabled subgroups require
> >> different interaction modes.
> >>
> > I am not trying to solve the gaming problem for the blind. And
something you
> > have a problem understanding is that the main problem we are solving is
>
> How can I know you're not trying to solve that?  You haven't yet
> stated what problem you're trying to solve, and you've talked about
> Zynga's needs more than once.  It thus seems a natural assumption that
> accessible gaming is a problem you want to solve.
>
Tab I told you that Zynga was not focused on accessibility. I simply stated
that they wanted fast hit testing.

I simply need to provide the object locations and bounding information to
be located. This would be true for a game, a flow diagram decisions
statement or a widget.

It is now natural to assume that your only mission here is to waste our
time. You offer nothing of value.


>
> >> There *are* accessibility problems that can be solved by exposing an
> >> alternate subtree (or possibly by other solutions). Until you list
> >> those problems, we have no way to tell how good your proposed solution
> >> is.
> >>
> > Alternative solutions depend on infinite number of problems and I am
not
> > inclined to boil an ocean with you.
> >
> > We are simply providing the ability to map visual objects and their
> > relationships to platform accessibility API. New 508 government
requirements
> > in development require a whole littany of those. That is the problem we
are
> > trying to solve here. We are not trying to build new applications with
> > different interaction models.
>
> What. Problem. Are. You. Solving.
>

I explained that. You are either as dense as concrete or simply being an
obstruction. The end result is you are having us go around in circles. You
are not worth my time.

> This question is both simple and vital.  There is no "simply
> providing" on the web.  If your problem is "as quickly as possible,
> make it possible for companies who chose to use the canvas 2d context
> to comply with a particular set of US accessibility laws", then state
> that.  I think it's a really bad problem to solve, but we can at least
> debate that.
>
>
> > I am not trying to solve accessible gaming but if I were a low vision
user I
> > would need to be able to find the damn object on the screen with their
> > magnifier! It does not matter what the interaction model is. That would
be
> > like you trying to play Farmville on a 60 inch screen looking through a
shot
> > glass butted up against the screen. Try it some time and go find the
shovel.
>
> Being able to automatically magnify an active region of an application
> is a useful problem to solve.  It is not solved very well by your
> solution, as it only works when the app author goes to the extra
> effort of annotating the canvas with information about what areas are
> associated with certain elements in the alternative subtree.  Optional
> APIs make for horrible accessibility in general, because most people
> won't use them.
>
That is the design we have now with the exception that we were trying to
associate these objects with hit testing as this is something the author
needs. I am happy with that approach. You offer nothing of value other than
to moan about things you don't like. It is a trivial exercise to join a
discussion and point out things you don't like. It is another to provide
something of value. It is a trait you share with Ian. Until you can provide
that this discussion is done.

> ~TJ
>