Re: hit testing and retained graphics

On 7/2/2011 7:09 PM, Benjamin Hawkes-Lewis wrote:
> On Sat, Jul 2, 2011 at 5:13 PM, Charles Pritchard<chuck@jumis.com>  wrote:
>> 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.
> The goal is to enable people with disabilities to use a remote system.
>
> Where the AT is running is not key to this goal.
Then you've misunderstood the mandate. It is documented by the UAAG
and WCAG.

>> Further, we're just looking for screen coordinates here, so that the
>> local AT will work.
> Please explain in the context of remote *system* access.
>
> Does "just" not imply converting remote applications into DOM?
>
> If so, can you explain what would be required for remote system access
> software and local AT?
 From Faulkner's post:
"canvas based http://demo.ericomaccessnow.com/ (requires websockets 
enabled browser, works fine in chrome)"

That's remote system access.  Unfortunately, it does not work in my 
mobile phone,
because they are processing click events but not touch events. And it 
doesn't work with VoiceOver,
because they have no method of conveying bounding box / path information.

The information is available on the remote side, but there's no method 
to convey that information
on the client side, other than the tag soup I've presented in earlier 
threads.

>> 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.
> UAAG conformance is not a precondition of HTML5 conformance.
It is for vendors.
> In the case of canvas being used as the visual display component of a
> remote access system, user agents that *choose* to conform to UAAG would
> conform (primarily) by reporting the bounding dimensions and coordinates
> of the canvas (2.1.6.a).
No, web content authors would *choose* to conform to the WCAG.

They can't make that choice if vendors use their position to block 
developers
from doing so.
> What would make the remote access useful to people with disabilities
> would be hooking up remote AT software with local hardware.
You're free to do that, but you're limiting the millions of web 
developers from trying,
to a handful of system OS developers targeting particular platforms.

Again, there are reasons why AT is so expensive, and some of them have 
to do
with barriers to entry, efficiencies and economies of scale.
>> As for your "less work" talk:  How is that relevant?
> All other things being equal, reducing the work required to make
> something happen makes it more likely people will do the work to make it
> happen.
This has -never- been an accepted argument when I make proposals to 
browser vendors
or otherwise try to justify standards based on the cost of programmer hours.
> The amount of work required for various approaches is therefore relevant
> to enabling people with disabilities to access remote systems.
You're not a market analyst; the work that peoples may undertake to help 
those with
disabilities is something worth discussing. But you have to do it with 
some credibility.

I've put forward the very simple concept that -individuals- are willing 
to work so that
they may communicate easier with people they care about. It doesn't even 
require a market
to be a fact.

Do you need more evidence? More examples?
> We have a way to enable magnification users to access remote
> systems when a native graphics API is used.
It is vital to support client side AT.

> If the goal is to enable magnification users to access remote
> systems when canvas is used, it's obvious to ask why the existing
> way is not sufficient.
>
> Can you answer the question?
It is a conformance requirement that web applications support client 
side AT.
>> We've already solved most of the a11y programmatic access issues via
>> the canvas shadow DOM, drawFocusRing and other associated methods.
> These features don't contribute to a practical approach to the remote
> system access use-case.
Based on what practice? Have you had any feedback from web app developers?

I've brought up practical approaches based on my experience as a canvas 
implementer
and a web application developer; as well as a canvas developer and 
relayed conversations
gathered from other canvas developers.

I'm willing to take your statements at face value; but right now they 
seem to be
based on conjecture which doesn't reconcile with my real world experience.
>> 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.
> Can you explain what that problem has to do with a practical approach to
> the remote system access use-case?
Yes: if the client UA can relay bounding box information, then they can 
also relay role information
of UI widgets, which then allows ATs running on the client's OS to 
interact with the UA in dynamic
ways. This allows for the user to select and customize their AT 
experience and thus improve accessibility.

This in turn means that those with disabilities, contextual or 
otherwise, are able to work more flexibly
and more productively. It also means that application developers are 
able to market their applications
to government agencies and meet U.S. legal guidelines, as well as large 
enterprises that might otherwise
face legal suits, should they fall out of compliance with the principles 
set forward by WCAG .

In doing so, they're able to carry a business, in the -practical- world, 
and invest in further usability.
Currently, its a rather closed field, because vendors have unwittingly 
kept the barrier to entry quite high.

I'm sure that existing vendors would welcome innovation in their industry.

-Charles

Received on Sunday, 3 July 2011 02:48:22 UTC