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 2:30 PM

Hi Debbie,

> 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.

OK. This to me sounds like a suggestion to define some interoperability
layer (which for technical reasons would have to be platform-specific),
and then insist that both IT and AT support it (your "comply"
statement). If AT doesn't do this, then the AT would not meet 508,
correct? The AT-IT interoperability provision that we have now goes as
far as we know how to do this in a technology/platform-neutral fashion,
and places the burden solely on IT to provide that information.

> 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'm sorry, but here I disagree. Actual, tested compatibility with
specific AT isn't compliance to a standard. It is compliance to a
specific version of specific AT on a specific platform. If/when that AT
changes, it potentially throws my application "out of compliance". E.g.
one version of JAWS had pretty good support for Java. A later release of
JAWS introduced bugs that broke that support for Java. So one day Java
is "compliant", and then the next it isn't, with *no* change in Java.
How can this be right?

> 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.

We are absolutely factoring AT compatibility "into this equation
somewhere". The FPC purpose makes this clear, and the AT
Interoperability provision spells it out. What we don't do is make AT
compatibility testable, because we don't know how to do that.

> 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.

There is no way we can do this if we place no requirements under 508 on
AT. If AT is free to do whatever it wants, free to support/not support
any application, platform, API, etc. that it wants, then there is now
way that 508 can be a testable tool to provide reasonable assurance of
access via AT.

We either decide to place requirements on AT, or we go as far as we
possibly can shy of that (with the concerns that you have stated
remaining in place). I believe that the AT Interoperability provisions
do exactly that - the push IT applications as far as can be testable
pushed given those constraints.

> 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.
>

Again, can you propose specific language that addresses these concerns,
and that meets the constraints we are operating under?


I want to point out that at least this Industry representative
recognizes the importance of AT, and because the AT industry has not
found enough of a market/demand/whatever on Solaris and UNIX systems in
general, we have been developing our own AT for our platform. We have a
screen reader that is increasingly offering the kinds of efficiency and
productivity functionality that blind users have come to enjoy with
commercial Windows AT products (custom scripts in the screen reader for
things like e-mail and web browsing and creating/reading office
documents). We have an on-screen keyboard AT that offer an efficient
single switch interface for controlling applications that in my opinion
exceeds similar functionality in Windows AT offerings. And we are
bundling a dynamic text entry application that allow someone who can
only move their eyes to type at 35+ words per minute (into our office
suite, into e-mail, etc.). Oh, and we do this all through a set of
"accessibility services" that are a superset of those specified in the
AT Interoperability draft provision.

As Sun is now also an AT vendor, speaking with that hat on I strongly
believe that addition of the AT Interoperability provision will be a
powerful tool in our discussions with companies that develop software to
run on Solaris (and UNIX in general) - it will be the primary litmus
test for whether they are doing their part to support AT. E.g. when
Adobe updates their PDF Reader for Solaris, agencies will look to see
whether PDF Reader exposes all of the required information via the
Solaris accessibility services. If Adobe Reader does this, it is highly
likely that it will work with our screen reader Orca. And I would
certainly like Adobe to test with Orca; but I wouldn't claim that any
problems found are solely Adobe's responsibility to fix.


Sorry, I'm getting a bit long-winded here. I understand your desire to
have some collection of language/provisions in 508 such that we could
guarantee that IT that complies with that language automatically works
with the AT either in hand or immediately purchasable at the agency.
But I don't see how we can actually do that. And please note, the
existing 508 provisions we've been apply for the last years didn't do so
either.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> ----- 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