Thread Subject: Re: FPC - USERS' AT

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Peter Korn
Date: Tue, Jun 05 2007 1:00 AM

Hi Gregg,

I'm sorry, but I don't think you understand what the GNOME On-screen
Keyboard (GOK) does, and how it works.

GOK uses AT-SPI (that is the formal name of the GNOME/UNIX accessibility
API, the Assistive Technology Service Provider Interface) to:
1. Enumerate the set of accessible applications, top-level windows (and
present a dynamic keyboard listing these windows, allowing the user to
pop any of them to the top directly, without injecting keystrokes like
ALT-TAB to do so)
2. Walk the user interface element tree for a window, and down into the
menus and menu items, and present dynamic keyboards showing all of the
menu choices, which are then activated directly (not by injecting
keystrokes, but via the AT-SPI "selection" interface - this will work
for menu items that don't have keyboard mnemonics)
3. Enumerate the items in toolbars, and present dynamic keyboards
showing all of the toolbar items, which again can then be activated
directly (and as with menus, activated not by injecting keystrokes, but
via the AT-SPI "action" interface - this will work for toolbar items
that don't have keyboard mnemonics)
4. Enumerate the hyperlinks in hypertext content (note I didn't limit
this to Firefox, and I didn't limit this to HTML), and present dynamic
keyboards showing all of the link, which can be activated directly (not
by injecting a series of TAB keys followed by spacebar, but via the
AT-SPI interface to activate hyperlinks). When the page updates, GOK
gets an event for the update, waits for things to settle (no more
updates), and then re-queries the page for hyperlinks and updates its
own dynamic on-screen keyboard for the new links
5. Enumerate the user-interface elements in dialog boxes, and present
dynamic keyboards with all of those elements (using color and style
coding on the keys of the keyboard to indicate the different kinds of
controls - text, checkboxes, etc.), and allowing the GOK user to
manipulate those items directly.

GOK works with hundreds of applications, including the GNOME desktop,
the GNOME hypertext help system, a full featured e-mail and calendaring
application, and a very full featured office suite among others.

I'd be happy to give you an in-depth demonstration of GOK and the
technology underlying it. It most definitely does not simply inject
keystrokes to do its job.


As far as what ATIA would and would not agree with, I believe Sun is the
only ATIA member who is shipping anything like GOK. I believe Sun and
Apple are the only ATIA members shipping a screen reader that is 100%
accessibility API-based (unless you want to count Narrator). At TEITAC
#3 Randy Marsden demonstrated some similar AT to GOK that Madentec is
working on for the Macintosh, making use of the Apple OS X accessibility
API. But I fear too few significant applications on Macintosh support
the API yet to for anyone to make definitive statements on how robust
the API route is for that use - the sample size of apps is I think still
too small there (e.g. you don't have a full office suite implementing
the Apple OS X accessibility API yet).

And please don't take my remarks to mean that testing is no longer
important.

Application vendors test printing. Printer driver vendors test with
apps. But app vendors don't test with every printer; printer vendors
don't test with every app. Both test against the platform printing
APIs, and against a handful of apps/printers, and convince themselves
that they've implemented the APIs properly. Same with network devices -
way too many network devices out there to test each one against every
other one. You test against the APIs, and you test against a
representative sample of other devices, and then you ship your product.
And if a problem arises from the field, you track it down and if the
problem is yours you fix it (and if not you forward it on to the party
you believe is responsible for it).


I believe we can get to this place with AT-IT interoperability. I
believe it is in all of our best interest to get to this place with
accessibility.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

P.S. to your original topic - I agree an application isn't accessible to
a specific person with a specific disability if it requires AT to make
it accessible and the person doesn't have that AT. More generally if
the specific AT doesn't exist on that platform, then the application
isn't accessible generally to people with that disability on that
platform (rich web apps implementing the WAI ARIA draft running on IE
[instead of Firefox]; or Flash on a UNIX desktop; or perhaps any
application on any platform meeting the needs of people with cognitive
impairments).

And what we say about the requirements for something being accessible is
distinct from any decision about who is responsible for what tasks (app
vendor, platform vendor, AT vendor) in order to realize solutions for
specific disabilities on particular platforms. It is also distinct from
the question of how one gets available AT that meets a user's needs into
that user's possession (the affordability and installed base questions).

> Yep - all of the 'keyboard' AT will work with the applications because they
> all create real keystrokes (as far as applications are concerned) so the
> applications don't have to do anything to work with them. But I was
> referring to screen readers and other AT that rely on APIs that don't work
> that way. Someday maybe. But I think ATIA would agree that mainstream
> software vendors won't be able to create software that works reliably with
> many types of AT without testing it with AT -- at least not anytime soon.
>
> (And I think we slipped off of the original topic - which was that software
> shouldn't be considered accessible (usable by people with disabilities) if
> it requires AT to do so and the AT doesn't exist.) But anyway.
>
>
> Oh -and regarding Cognitive - I join you in that quest. That item is
> still very open.
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
>> Peter Korn
>> Sent: Monday, June 04, 2007 11:07 PM
>> To: TEITAC General Interface Accessibility Subcommittee
>> Subject: Re: [teitac-general] FPC - USERS' AT
>>
>> Hi Gregg,
>>
>> The GNOME On-screen Keyboard *does* "work like that". No
>> scripting necessary, the GNOME On-screen Keyboard provides a
>> rich, powerful, and highly efficient user interface for
>> someone with a severe physical impairment to all apps that
>> implement the UNIX accessibility framework properly. Where
>> it doesn't work at all, it is clear that the mainstream
>> application didn't implement the UNIX accessibility
>> framework. Where it fails to work fully, we have always been
>> able to trace the problem to one of: (a) the app didn't
>> implement the accessibility API properly; (b) GOK has a bug;
>> or (c) the UNIX accessibility framework had a bug.
>>
>> This is just like the printer driver scenario I described.
>> It isn't a pipe dream, it is the reality we are living in the
>> UNIX world.
>>
>> Where the scenario differs from printer drivers is that applications
>> *always* test to see if they can print. Applications don't
>> always test to make sure they work with the accessibility
>> framework and with UNIX AT. But this too is changing...
>>
>>
>> With respect to cognitive impairments, I'm still waiting for
>> a good description of what desktop-wide AT should look like,
>> and what self-accessible/closed applications should
>> specifically do to support cognitive impairments. I'm an
>> accessibility expert, and I don't have a clear directive to
>> give to software developers on how to meet the draft
>> Functional Criteria 1.1.G such that someone else (e.g. the
>> Access Board or GSA) would say the software is compliant.
>> That is to say, I have some ideas as to what they might do,
>> but I can't point developers to known acceptable techniques
>> for addressing 1.1.G. And unless I am in a tiny minority of
>> the accessibility folks within Industry, this is a real
>> implementation problem with 1.1.G.
>>
>> Perhaps over the coming weeks we can start to develop a body
>> of acceptable techniques ("sufficient techniques" anyone?)
>> for addressing 1.1.G.
>>
>>
>> Regards,
>>
>> Peter Korn
>> Accessibility Architect,
>> Sun Microsystems, Inc.
>>
>>
>>> Hi Peter,
>>>
>>> Wouldn't it be great if AT worked like that? You just
>>>
>> built AT to
>>
>>> the spec for the OS and it would automatically work with
>>>
>> all applications on the
>>
>>> OS. Someday I hope - - til then I think the government
>>>
>> needs to buy
>>
>>> application that it knows work with AT. (Whenever it can).
>>>
>> Otherwise
>>
>>> employees with disabilities can't access the software and
>>>
>> can t do their
>>
>>> job. If it comes automatically - great. But the test is
>>>
>> whether it works
>>
>>> with AT or not (or is directly accessibile).
>>>
>>> Same with Cognitive. I don't know what we will come up
>>>
>> with in that regard.
>>
>>> Cognitive access will largely be built-in features I
>>>
>> suspect -- or AT
>>
>>> compatibility features we already have.
>>>
>>> Across all of these however the government would purchase
>>>
>> what it can
>>
>>> when it can. (Either direct access or compatibility with AT.) But
>>> when government can't it should do the best we can.
>>>
>>>
>>>
>>> Gregg
>>> -- ------------------------------
>>> Gregg C Vanderheiden Ph.D.
>>>
>>>
>
>
>

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University