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 4:55 PM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Gregg Vanderheiden: "Re: FPC - USERS' AT"
- Previous message in thread: Gregg Vanderheiden: "Re: FPC - USERS' AT"
- Messages sorted by: Author | Thread | Date
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.
>>>>
- Next message in Thread: Gregg Vanderheiden: "Re: FPC - USERS' AT"
- Previous message in Thread: Gregg Vanderheiden: "Re: FPC - USERS' AT"