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: Debbie Cook
Date: Tue, Aug 14 2007 1:35 PM

While I don't think that AT should control IT nor should IT control AT, I do
believe both ought to be expected to comply with reasonable requirements and
constraints. The fact that AT has necessarily reverse engineered itself in
order to work with it does not mean it should be the desired practice of the
future. But the fact that is has had to do this and presumably will continue
to do so is indication that AT compatibility has to somewhere be considered
in the notion of compliance. I think we have to start with the original
intent of section 508. It was not to develop a protocol (although one would
be needed) it was to provide equal access to information for employees and
customers with disabilities. So, while I totally agree that AT cannot run
the show as it were, compatibility with it has to be factored into this
equation somewhere. The bottom line is that two products, one that works
with AT that is likely to be used, and one that does not work with any
available AT, cannot be equally compliant with respect to section 508.
When an agency purchases E&IT that is aledgedly compliant with 508, they
must have a reasonable assurance that when customers and employees with
disabilities come along to use the IT in question, they should be able to
have access to those functions. We can spend a lot of energy on all the
definitions of access etc. but eventually this is all a smoke screen for the
real issue. Will people be able to use, in some comparable form, the
products developed and purchased by the federal government. If we know it's
not compatible with any AT, and we can't reasonably arrange an AT to reverse
engineer itself for compatibility, then compliance serves no one.
All I'm asking for is to have the end user factored into this somehow so
that agencies will know the difference between E&IT that meets a set of
standards, no matter how good those standards are, but for which there is no
way to access the product for some set of individuals who may need that
access.
----- Original Message -----
From: "Peter Korn" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, August 14, 2007 11:57 AM
Subject: Re: [teitac-websoftware] AT Interoperability


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