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: Mon, Jun 04 2007 10:10 PM

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.
>
>
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
>> Peter Korn
>> Sent: Monday, June 04, 2007 5:49 PM
>> To: TEITAC General Interface Accessibility Subcommittee
>> Subject: Re: [teitac-general] FPC - USERS' AT
>>
>> Hi Gregg,
>>
>> With this refresh we are introducing requirements to address
>> the needs of people with cognitive impairments. In our
>> con-call earlier today, you pointed out that one couldn't
>> really ask the government to purchase ACME OS if ACME OS said
>> that it "supported AT" but no AT existed that used that
>> support. But aren't we essentially in that situation today
>> for *all* OSes when it comes to supporting AT for users with
>> cognitive impairments? What AT exists (on any platform) that
>> provides desktop support for users with cognitive
>> impairments? We have products like TextHelp and WYNN, but
>> these aren't general cognitive AT solutions that work on the
>> desktop, and with applications generally. Likewise the
>> AppReader and DocReader functionality of ZoomText only works
>> with a tiny handful of apps. So with the current draft,
>> provision 1.1.G. "At least one mode shall be provided that
>> accommodates cognitive, language or learning impairments,
>> directly or with users' AT." we would make the overwhelming
>> majority of E&IT fail to meet 508 because the AT simply
>> doesn't exist (and existing software doesn't explicitly
>> accommodate cognitive, language, or learning impairments -
>> and frankly doesn't even know precisely what to do for that
>> accommodation).
>>
>> Also, you make a point in this e-mail about printers:
>>
>>
>>> Is this unfair to companies who create software that
>>>
>> Printer companies do not support? No. A the companies
>> 'held hostage' by the printer
>>
>>> manufacturers? No more than any company is held hostage
>>>
>> by any other
>>
>>> company who need their support. This is a very common
>>>
>> situation. The
>>
>>> companies can work this out amongst themselves.
>>>
>>>
>> Your printer analogy is a useful one. In the long-ago times,
>> individual applications would contain printer drivers (think
>> back to DOS and WordPerfect), but today the OS or platform
>> defines a printing framework, and both apps and printers plug
>> into that framework. There is no holding hostage anymore -
>> an application generates output via the platform printing
>> framework, and printers (and printer drivers) implement that
>> framework in order to be a printer that is worth purchasing
>> for that platform. Yes there are individual bugs that creep
>> in and appear with a specific app and a specific
>> printer/printer-driver, but those are almost always bugs in
>> how one or the other implemented support for the platform
>> printing framework that were only exposed when the two were
>> used together (or perhaps a bug in the platform printing
>> framework itself).
>>
>> And this is *precisely* the world that are trying to move to
>> with AT-IT interoperability. The platform defines the
>> accessibility services, and apps & AT implement support for
>> it. Then nobody holds anyone else hostage. Yes there is a
>> need for interoperability testing, bug fixing, etc. But it
>> dramatically different from the world of DOS & WordPerfect &
>> each application having its own set of printer drivers.
>>
>>
>> Regards,
>>
>> Peter Korn
>> Accessibility Architect,
>> Sun Microsystems, Inc.
>>
>>
>>
>>> Hmmm. I'm afraid that runs into the same problem.
>>>
>>> The government wouldn't buy software that has been out for
>>>
>> a certain
>>
>>> period of time if there were no printers that worked with
>>>
>> it -- or if it didn't
>>
>>> work with the operating systems. They wouldn't buy it
>>>
>> because it couldn't
>>
>>> be used by their employees.
>>>
>>> Similarly, they wouldn't buy software that didn't work with AT that
>>> the government uses no matter how long it had been out
>>>
>> since the gov
>>
>>> employees (with disabilities) couldn't use it.
>>>
>>> Now if there is NO software of a type that works with AT
>>>
>> that is different.
>>
>>> The software still wouldn't meet 508 but the gov might
>>>
>> purchase one of them
>>
>>> anyway because it needs someone to do the work. But if
>>>
>> there is software
>>
>>> that DOES work with AT and it isn't an undue burden to use it, then
>>> the gov should.
>>>
>>>
>>> Is this unfair to companies who create software that
>>>
>> Printer companies do
>>
>>> not support? No. A the companies 'held hostage' by the printer
>>> manufacturers? No more than any company is held hostage
>>>
>> by any other
>>
>>> company who need their support. This is a very common
>>>
>> situation. The
>>
>>> companies can work this out amongst themselves.
>>>
>>>
>>> >From the customer standpoint (the government) they wouldn't buy
>>>
>>>> things their
>>>>
>>> employees can't use no matter what the reason. And 508
>>>
>> says they should
>>
>>> apply the same standard for employees with disabilities -
>>>
>> unless it is
>>
>>> an undue burden to do so.
>>>
>>>
>>> Final note. The suggested language does not "limit deployment of
>>> technologies that aren't supported by some portion of the
>>>
>> AT in the field".
>>
>>> It focuses and promotes the purchase of technologies by the
>>>
>> government
>>
>>> that can be used by its employees including those with
>>>
>> disabilities."
>>
>>> 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 12:00 PM
>>>> To: TEITAC General Interface Accessibility Subcommittee
>>>> Subject: Re: [teitac-general] FPC - USERS' AT
>>>>
>>>> Hi Gregg,
>>>>
>>>> I want to briefly explore the flip-side of this. Rather
>>>>
>> than saying
>>
>>>> something that boils down to limiting deployment of
>>>>
>> technologies that
>>
>>>> aren't supported by some portion of the AT in the field;
>>>>
>> what about
>>
>>>> allowing deployment of technologies once a certain time period has
>>>> passed after accessibility services have been
>>>>
>> defined/implemented for
>>
>>>> that technology?
>>>>
>>>> E.g. we allow ACME web application technology to be used 1
>>>>
>> year after
>>
>>>> accessibility services for that web technologies were defined
>>>> (whether or not any AT supports it). This doesn't satisfy
>>>>
>> the desire
>>
>>>> that end user can reasonably expect to have access to
>>>>
>> something with
>>
>>>> AT they have or can easily obtain. But it is simply the
>>>>
>> flip side of
>>
>>>> the same coin - we are constraining innovation from one
>>>>
>> part of the
>>
>>>> industry to deployment by another part of the industry.
>>>>
>>>> We should not do that.
>>>>
>>>> Regards,
>>>>
>>>> Peter Korn
>>>> Accessibility Architect,
>>>> Sun Microsystems, Inc.
>>>>
>>>>
>>>>
>>>>> Absolutely.
>>>>>
>>>>> But if we do we also reduce the number of people who can
>>>>>
>> access to
>>
>>>>> less than 10%.
>>>>>
>>>>> So both solutions are not acceptable. We are put in a
>>>>>
>>>>>
>>>> really &^#@$%&
>>>>
>>>>
>>>>> situation here.
>>>>>
>>>>>
>>>>> 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:22 AM
>>>>>> To: TEITAC General Interface Accessibility Subcommittee
>>>>>> Subject: Re: [teitac-general] FPC - USERS' AT
>>>>>>
>>>>>> Hi Gregg,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Which users' AT?
>>>>>>>
>>>>>>> If "users' AT" means ALL users' AT it sets unreasonable
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> limitations on
>>>>>>
>>>>>>
>>>>>>
>>>>>>> technologies that can be used.
>>>>>>>
>>>>>>> If "users' AT" means only the best AT out there it
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> unreasonably limits
>>>>>>
>>>>>>
>>>>>>
>>>>>>> access to government information to just the small
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> percentage with the
>>>>>>
>>>>>>
>>>>>>
>>>>>>> best AT.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> One real problem - if we restrict what can be deployed to
>>>>>>
>>>>>>
>>>> the public
>>>>
>>>>
>>>>>> to something other than what the latest AT supports (let
>>>>>>
>>>>>>
>>>> us presume
>>>>
>>>>
>>>>>> to pick a number, only those features that is support by
>>>>>>
>>>>>>
>>>> AT that has
>>>>
>>>>
>>>>>> been in on the market for 1 year), then we remove a major
>>>>>>
>>>>>>
>>>> incentive
>>>>
>>>>
>>>>>> for AT vendors to support new technologies, approaches, etc.
>>>>>>
>>>>>> The AT industry has historically trailed new technology -
>>>>>>
>>>>>>
>>>> typically
>>>>
>>>>
>>>>>> supporting Web techniques and applications only when a
>>>>>>
>>>>>>
>>>> critical mass
>>>>
>>>>
>>>>>> / large enough market share has developed. There are a
>>>>>>
>> variety of
>>
>>>>>> reasons for this - including how hard it is to develop AT
>>>>>>
>>>>>>
>>>> in a world
>>>>
>>>>
>>>>>> without good support for AT-IT interoperability.
>>>>>>
>>>>>>
>>>> Nonetheless, it is a
>>>>
>>>>
>>>>>> market reality today.
>>>>>>
>>>>>> There is a real danger that we will hinder the development and
>>>>>> deployment of new and accessible techniques if use any test that
>>>>>> requires compatibility with AT deployed in the field.
>>>>>>
>>>>>> The situation we have today isn't great either - the
>>>>>>
>>>>>>
>>>> proliferation of
>>>>
>>>>
>>>>>> inaccessible techniques (e.g. AJAX without support for WAI
>>>>>>
>>>>>>
>>>> ARIA) and
>>>>
>>>>
>>>>>> the lag we have today in making them accessible. Frankly
>>>>>>
>>>>>>
>>>> the only way
>>>>
>>>>
>>>>>> I see to address this is to push new development as much
>>>>>>
>>>>>>
>>>> as possible
>>>>
>>>>
>>>>>> to develop and use accessibility services for AT-IT
>>>>>>
>>>>>>
>>>> interoperability
>>>>
>>>>
>>>>>> (as we are doing in our drafts).
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Peter Korn
>>>>>> Accessibility Architect,
>>>>>> Sun Microsystems, Inc.
>>>>>>

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