Re: hit testing and retained graphics

On 7/2/2011 6:32 AM, Benjamin Hawkes-Lewis wrote:
> Would using a remote
> screen
> magnifier not work?


Generally speaking, an AT is intended for the computer that the user is
actually running on. Further, we're just looking for screen coordinates 
here,
so that the local AT will work.

Of course we can setup a page to use CSS transform, or many other techniques
to get a zoom effect. That does not serve the purpose of supporting the 
client-side
AT. Supporting client side ATs through ARIA and through adequate population
of the Accessibility tree is a part of the UAAG.

http://www.w3.org/TR/UAAG20/

UA vendors have a responsibility to support client-side AT.

As for your "less work" talk:  How is that relevant?
> I don't see why this needs to change when canvas is used
> for
> the
> visuals rather than a native graphics API?
> (Specifically, it sounds like less work to fix the
> technical
> problems
> I mentioned above than to duplicate the whole work of the
> accessibility stack in some sort of complex conversion from remote
> platform APIs to DOM to local platform accessibility APIs to local
> interface.)

How is this relevant?  We've already solved most of the a11y 
programmatic access issues
via the canvas shadow DOM, drawFocusRing and other associated methods.

We're simply looking to solve the issue involved in spatial awareness 
for pointer
events and for repositioning prior to/without requiring a focus event.

It's a very specific problem.



-Charles

Received on Saturday, 2 July 2011 16:14:24 UTC