Thread Subject: Re: AT Interoperability

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, Aug 14 2007 1:00 PM

Hi Debbie,

What specifically do you propose?

You wrote "it really does appear to me that products which could
theoretically have AT support but don't, would be equally compliant with
those that have AT support." What does "have AT support" mean? That a
single assistive technology vendor has taken the time to reverse
engineer the product to make their AT work with it? 3 AT vendors? One
in each AT area? And in all of these cases, what has the IT product
done - other than be popular enough to get the attention of AT vendors -
in order to make itself work with AT?

Here are the constraints as I see them:
1. We must have criteria that are testable; we don't know how to test
"usability" (in any field, let alone accessibility)
2. We cannot require party A (e.g. industry) to guarantee the
functionality from a product from party B (e.g. AT) that it doesn't control
3. We want to improve AT-IT interoperability, and move the AT/IT
industry away from their history (by necessity) of reverse engineering
for access and to supported techniques for access

Do you disagree with these constraints?

As has been discussed in the General SC and in other places, the FPC as
written aren't testable. It was also noted several times (including on
the General SC call earlier this week) that agencies don't try to test
against the FPC - the direction is to use the technical provision, and
only go to the FPC when a product isn't covered by the technical
provisions. As such, I don't see a change in implementation in what we
are doing (clarify that the FPC aren't testable); rather it is a formal
recognition of the reality of application. As such, we can deal with
the situation more explicitly, and move to test what can be tested.

To your question about "where is the incentive?" I see this language as
providing three incentives:
1. Incentive for IT to use platform accessibility services, or some
other means "...to cooperate with AT..."
2. Incentive for a platform to define such services
3. Incentive for AT to use this information - because it has been
called out

Perhaps These incentives could be made stronger. But please note that
AT as long said that they want this kind of information, that it makes
their lives easier if they have it, and that they use it where they can.

The language also makes a very clear and unambiguous enumeration of the
minimum information IT should provide to AT. We have never had that before.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> OK I'm extremely concerned about this proposal. Concern is greater because,
> at the same time, it is proposed to reduce the Functional Performance
> Criteria to something lokie philosophy rather than requirement applicable to
> all.
> So, taken together with the proposal for interoperability, it really does
> appear to me that products which could theoretically have AT support but
> don't, would be equally compliant with those that have AT support. Where is
> the incentive there? More important, where is any accessibility? I really
> fail to see how the end user gains from this.
> I could live with the concept of the API being adequate if the final test
> would be the FPC. But that appears to be going away or significantly
> weakened based on discussions at General.
> So, my concern remains that products which are not accessible to consumers
> with disabilities will pass with equal status as those which are. And
> agencies, woh may lack the expertise to discern all the nuances will
> purchase those that do not as readily as those that do.
> This is a pretty fundamental change in the construct of Section 508 with
> huge implications.
> ----- Original Message -----
> From: "Peter Korn" < = EMAIL ADDRESS REMOVED = >
> To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
> Sent: Tuesday, August 14, 2007 10:20 AM
> Subject: Re: [teitac-websoftware] AT Interoperability
>
>
> Hi Gregg,
>
> We have more or less come to the consensus that we don't want to write
> specific provisions for assistive technologies (e.g. requiring that AT
> purchased by the government must implement support for platform
> accessibility services, let alone any API that any application chooses
> to invent and use). Unless that changes, we cannot insist that AT and IT
> must work together. Further, we cannot tell IT that it has the sole,
> unshared burden of working with AT.
>
> I feel this provision is nearly the best that is possible within those
> constraints. Pushing IT to use platform accessibility services where
> they exist (and by implication encouraging platforms to define and
> promulgate such services) will go a long way to improving AT-IT
> interoperability.
>
> But at AT and IT typically come from different companies, there is no
> way one can control the other. And since government-wide regulations
> like 508 must be technology neutral, 508 itself cannot say "your IT must
> work with the Gregorian Screen Reader". Individual agencies can (and
> do!) do that, but that is part of how they define their business need.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
>
>> I can't tell from the current language.
>>
>> 1) Does this provision require that software actually work with
>> assistive technology?
>>
>> 2) Or does it only require that information be provided that AT could
>> work with?
>>
>> 3) Could someone sell something to the government that met this
>> provision – but where there was no assistive technology available for
>> one or all disability groups?
>>
>> Thanks
>>
>>
>> Gregg
>>
>> ------------------------
>>
>> Gregg C Vanderheiden Ph.D.
>> Professor - Depts of Ind. Engr. & BioMed Engr.
>> Director - Trace R & D Center
>> University of Wisconsin-Madison
>> _<http://trace.wisc.edu/>_ FAX 608/262-8848
>>
>> DSS Player at http://tinyurl.com/dho6b
>>
>> If Attachement is a mail.dat try http://www.kopf.com.br/winmail/
>>
>> <http://trace.wisc.edu:8080/mailman/listinfo/>
>>
>> ------------------------------------------------------------------------
>>
>>

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