RE: hit testing and retained graphics

Mailing lists for HTML and canvas accessibility are not the venue for Flash accessibility requests, but I will mention here that Flash Player does support the accLocation() for finding a bounding rect; ask you to re-read the part where I said we're moving to IAccessible2 for our accessibility API; and throw in that we have stated our intention to support WAI-ARIA in future releases.

Please feel free to contact me offlist(s) with any questions or concerns.


-----Original Message-----
From: Charles Pritchard [] 
Sent: Tuesday, June 28, 2011 11:02 AM
To: Matt May
Cc: Silvia Pfeiffer; Richard Schwerdtfeger; Charles McCathieNevile; Cameron McCormack; Cynthia Shelly;;; Tab Atkins Jr.;;;;;
Subject: Re: hit testing and retained graphics

On 6/28/2011 9:15 AM, Matt May wrote:
>> What about Adobe Flash in this area? Adobe Flash is used for many of
>> the same use cases that canvas is used for. Is Flash more accessible?
>> How do they do it? Is Flash prohibited because it's not accessible?
> Any shape drawn the a Flash stage (or canvas) can be named, and any named display object can have an AccessibilityProperties object associated with it that allows it to be tagged with an accessible name and description, and other properties including grouping of child objects (forceSimple), keyboard shortcut, and the ability to hide it from the DOM. Reading order is handled either explicitly or algorithmically based on x,y coordinates.
> Further, any display object or sprite can have an AccessibilityImplementation object which allows MSAA (soon IAccessible2) roles and states to be applied and managed, and marshals events through the accessibility API. Using the Flex SDK, application developers can build sprites from any kind of graphics they choose, and wire them up to appear to assistive technology in the same manner as one would expect of an OS-level control.
Matt, as you know, MSAA is quite aged. UIAutomation models in Windows 
and OS X allow for a much richer (and more performant) vocabulary.

I'd like to see Flash (in the future) support the same technique that's 
been proposed here for work with spatially aware ATs.
Currently, as you've stated, bounding rectangles are exposed. I'd like 
for ATs to be able to fetch path information for objects.

If Flash, SVG and Canvas all expose a normalized path string for 
accessible objects, on screen, then the AT needs only
support that simple format, for whatever uses it may have.

Flash could simply target the same ARIA semantics that browser vendors 
are targeting with system level APIs.
ARIA semantics (thankfully) allow easy pass through and binding of 
string data to accessibility objects.

Allowing ATs to access path data enables software like Apple's VoiceOver 
for Mobile Safari,
and ViewPlus' Hands-on-learning software to inter-operate with more content.

WAI-ARIA attaches neatly to AccessibilityImplementation objects; it's 
easy to just
look at it as a bucket of key value pairs. They're interpreted by the 
AT, based on context
and user settings within the AT. It's compatible with work on IAccessible2.
>> On a side not: I'm wondering if in the majority of cases we may be
>> trying to achieve the impossible. For example, you may try as hard as
>> you want, but you will not achieve it that a blind user will be able
>> to drive a car with nothing but machine support.
> Actually, that's inaccurate. In fact, the technology is so close at hand that the state of Nevada has approved driver-less cars on public roads. I believe you have a business relationship with the company that's spearheaded the effort.
> It says something to me that this supposedly impossible problem is actually being tackled while HTML struggles not to have to apply semantics to shapes on a canvas.
>> Even with the best
>> technology that will communicate what is happening around them, it
>> will be impossible to provide a description of the visible environment
>> sufficiently timely to make it possible/safe to drive without seeing.
>> What is our solution for the impossible situation?
> This is not an intractable problem. This is not even close to an intractable problem. It has been a subject of research in accessibility for decades. The only thing missing in solving this problem is the will of those producing these specifications to address it. Or even to listen to some people who have been focused on this issue for a while, like Rich.

... And Richards separate response to Silvia's statements about drivers:
On 6/28/2011 8:19 AM, Richard Schwerdtfeger wrote:
 > My response is you are attempting to argue a point by stating we need 
to boil an ocean to solve the cases that are needed to keep people of 
disabilities employed. That is unnecessary. To address what you want is 
an entirely new research effort. At times you need to provide 
alternative equivalents for specific users. This is not a new concept.
 > If we want a blind person to be able to use a car to get around, 
design a car that drives itself ... but I think Google has done that. :-)

Richard: A driver-less car is not a car that allows a blind person to 
drive; but it does help them to get around.
I'm very sensitive to this issue, as I've many times seen discussion on 
the mailing lists about how accessibility
items can be handled "automatically" or "free" by some subsequent work 
or specification yet to be developed.

Silvia: It is not an impossible problem. It's been posed by the NFB:

And it's been prototyped and successfully driven:

As Dennis Hong points out: the challenge is creating a car which people 
can drive without eyesight.
It's a distinction he and his team had to learn, and they have learned 
it. It's an important distinction.

In the video, Dennis demonstrates a non-sighted driver maneuvering a 
simple obstacle course.
The driver is informed of road conditions through tactile interfaces.


Received on Tuesday, 28 June 2011 18:20:46 UTC