Thread Subject: Re: What is good enough to qualify for compatibility with 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: Tue, Mar 13 2007 3:05 PM

Hi Randy,

My responses are in-line, below.
> I hate to sound like a broken record (or stretched cassette tape, or
> scratched CD, or defective MP3 player, or faulty audio storage device that
> hasn't been invented yet...), BUT... I disagree.
>
> The suggestion is to remove IT's requirement to work with AT and replace it
> instead with a small set of API's that each side can design to. Correct?
> But to what end?
>

No, I don't believe that is what is being discussed.

Right now we have a handful of technical requirements which supposedly
help AT work with IT (but as has been discussed at length in the Web &
Software group, are in many cases no longer appropriate if they ever
were); and we have the broad and fairly vague repeated requirement in
1194.31 to either have a "mode of operation" that doesn't require a
variety of user capabilities, "or support for assistive technology used
by" that user community.

It doesn't say explicitly "you must work with AT vendors", and it
certainly doesn't say explicitly where precisely the responsibility lies
for AT-IT interoperability, beyond the functional criteria items noted
above.

This is where this thread started, with David Baquis asking for this
question to be addressed (see his message, which is the bottom-most
quoted message, at the bottom of this e-mail).

> If it is not economically feasible for an AT vendor to support a certain
> product or platform without the API's, it will still be so WITH the API's.
> This approach may simply give the IT vendor the ability to say "Hey, we've
> done our part" and proceed to sell their products to the Federal Government,
> which still don't work with existing AT.
>

At TEITAC #3 you gave a compelling demo of automatic switch scanning of
a GUI on the Macintosh, using the Apple accessibility API. You showed
it working with some of the built-in applications. You didn't show it
(for example) with MS-Office on Macintosh - which I note does not
currently implement the Apple accessibility API. This seems to
contradict your statement above. It was/is economically feasible for
Madentec to support this very compelling switch access to applications
that support the Apple API. Is it similarly economically feasible for
you to do so with applications that don't support the API?

> On the other side, if you demand that AT companies spend development dollars
> on products which they won't sell any of, one of two things will happen:
> they will either ignore the requirement, or they will go out of business.
> Neither scenario achieves the desired objective of providing accessible IT
> to Federal employees with disabilities.
>

I agree that we should not demand/require this. No argument here
Randy. I don't believe anyone is suggesting this anymore - we hashed
this out at some length a couple of months ago.

> If an IT company manufactures a product for which no AT exists, they have
> three choices:
> 1. Build accessibility directly into the IT product
> 2. Built their own AT
> 3. Work with AT companies (which may mean providing resources) to
> adapt their solution to be compatible with the IT product.
>

We need to distinguish software application from platform. They are two
distinct situations. Today we have existing platforms with AT on them,
but with insufficient support for AT-IT interoperability, making it much
harder than it needs to be to get AT and IT working well together. We
also have existing platforms with no AT on them. Oh, and we have a
couple of platforms which pretty rich support for AT-IT interoperability
(though as was pointed out in TEITAC #3, "pretty rich" is not the same
as "perfect, with no need for cooperation, debugging, and testing").

Looking then at these three distinct cases, I suggest that in fact there
are a lot more choices than just the 3 you outline:

A. On a platform with no existing AT, no support for AT.
Platform choices are:
1. Make the platform self-accessible (for blind, low vision, physical,
auditory, cognitive)
2. Build AT yourself without creating an architecture/API to support AT
3. Build AT yourself, on top of an architecture/API to support AT
4. Pay AT companies to support your platform (perhaps with or perhaps
without an architecture/API to support AT)
5. Be an important enough platform (sufficient popularity/sales) to
draw an AT industry to you that does the reverse engineering needed to
make your platform accessible (shifting you to scenario B below)
6. Claim an exemption of some sort
Application choices are:
1. Make the application self-accessible
2. Claim an exemption of some sort

B. On a platform with existing AT, little/no support for AT.
Platform choices are:
1. Work to not break existing AT, help them continue to reverse
engineer your platform, as your platform evolves
2. Build AT yourself (and potentially harm the existing 3rd party AT
ecosystem)
3. Build an architecture/API to support AT, allowing you over time to
shift resources away from #1
Application choices are:
1. Make the application self-accessible
2. Be an important enough application (sufficient popularity/sales) to
draw AT to you to reverse engineer and otherwise make you accessible
3. Pay AT to support you
4. Invent an accessibility framework/API that makes it easier for AT
to support you, and then some combination of #2 and #3 above to get AT
to support you
5. Claim an exemption of some sort

C. On a platform with rich support for AT
Platform choices are:
1. Build AT yourself
2. Be important enough (sufficient popularity/sales) to draw AT to
your platform
3. Pay AT to support you
Application choices are:
1. Make the application self-accessible
2. Support existing AT by implementing the accessibility framework/APIs
3. Claim an exemption of some sort


At Sun, when faced with these choices, we made the following decisions.
On Windows our applications defined their own accessibility API, and we
worked with AT vendors to support them (Java applications and
StarOffice/OpenOffice.org). While both of these are quite
important/popular (there are many tens of millions of copies of
OpenOffice.org running on Windows, and virtually every large
company/organization is using Java somewhere), they are still
insufficiently so to attract a large amount of AT support. Still, we
have more AT support than we would have had we not created an API to
gain access to those applications.

On both the Java and UNIX platforms, we developed our own rich support
for AT. And on UNIX, we are both building our own AT, and being some
combination of sufficiently important and relatively easy to develop AT
for that we are attracting 3rd party AT to UNIX.


> Because the Federal government (the customer) is asking for the
> compatibility, perhaps they could help with the resources required for
> number 3, with an SBIR-like grant program that AT and IT companies could
> jointly apply for. (Not within TEITAC's scope, but could be offered as a
> recommendation from our group).
>
> As to the question of whether an IT product must be compatible with ALL AT,
> or just common AT: I agree this is a difficult problem, and one which the
> formation of standards will help solve. To that end, we (AT) support the
> establishment of interoperability standards. We welcome them. But we don't
> feel they belong legislated in 508 where there is potential for them to be
> mis-used, but rather as non-normative language that is ancillary to it.
>

Now it is my turn to sound like a broken record (or some more modern
equivalent). We already have a set of technical standards in support of
AT-IT interoperability. They are the "group C" items in 1194.21 and
1194.22 (see
http://teitac.org/wiki/Web_and_Software:_Programmatic_exposure_of_information
for their enumeration and discussion). The problem is that they are in
many cases inappropriate, and more importantly they are insufficient to
the task of giving AT most of what it needs.

So to me, the multi-part question is:
1. do we leave things in this known, poor state? or
2. do we only fix the most obviously broken parts, but otherwise
leaving IT without technical guidance in how to best support AT (as it
is asked to do in 1194.31)? or
3. do we enumerate the techniques we generally agree are good (as
evidenced by the commonality in UI Automation, the Apple accessibility
API, the Java accessibility API, the UNIX accessibility API, and WAI
ARIA), recognizing that no enumeration is future proof?


I rather clearly prefer #3...


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> -Randy
> ATIA
>
>
>> From: Peter Korn < = EMAIL ADDRESS REMOVED = >
>> Reply-To: TEITAC General Interface Accessibility Subcommittee
>> < = EMAIL ADDRESS REMOVED = >
>> Date: Mon, 12 Mar 2007 15:04:16 -0700
>> To: TEITAC General Interface Accessibility Subcommittee
>> < = EMAIL ADDRESS REMOVED = >
>> Subject: Re: [teitac-general] What is good enough to qualify for compatibility
>> with AT?
>>
>> Hi David,
>>
>> As others have observed, this is a tricky issue. To me, it is also
>> unlike anything else in Section 508.
>>
>> Requirements in 508 that say to industry "you must meet this standard",
>> or "you must expose that information", or "you must meet this set of
>> functional criteria" can be perfectly objective, clearly understood, and
>> be 100% the responsibility of the product seeking to meet the 508
>> requirements.
>>
>> Something that says, in effect "play well with others" is extremely
>> difficult to deal with, especially if it is nearly that general a
>> statement. Even variants of this - e.g. "play well with some others",
>> or "play well with most others" - are only marginally better. Likewise
>> "play well with the popular others".
>>
>> Because who is to say objectively where the fault(s) lie in failing to
>> play well with another. Or to move away from these grade-school
>> metaphors, who can say objectively that the reason my application fails
>> to work well with their AT is because of a failing in my app or their AT?
>>
>> I understand and appreciate the challenge faced by agencies - Federal
>> and State - and also users, who simply want a strong level of confidence
>> that what they purchase will be accessible via assistive technologies.
>> But unless and until we specify in significant technical detail how apps
>> & AT are to interoperate with eachother - how they are to "play well"
>> together - we have no way to even start making that objective evaluation.
>>
>> Compounded with this challenge is the fact that 508 sets forth
>> requirements on IT, but not on AT. So we are really in the position of
>> saying that IT must play well with AT - with AT being allowed (under
>> 508) to completely uncooperative if it so chooses. If AT chooses to
>> ignore me (perhaps my software application lacks sufficient market share
>> to be worth any of their time), then I fail this test and am out of luck.
>>
>>
>> This is why I think 508 should not state that IT must work with AT.
>> Rather, I think it should set forth a measurable set of technical
>> requirements for what IT must expose to AT, with additional ancillary
>> material available that goes into even further detail for any given
>> platform/OS (what we've discussed as "sufficient techniques"). Then IT
>> can code to those specific technical standards. And if we have a short
>> set of "sufficient techniques", I believe that market pressure will lead
>> AT to support/use those techniques. Because AT does want to support IT
>> - that is why it exists! But lacking a small set of recognized specific
>> technical ways of supporting IT, we have the current, unsatisfying
>> situation we are in now.
>>
>>
>> Regards,
>>
>> Peter Korn
>> Accessibility Architect,
>> Sun Microsystems, Inc.
>>
>>
>>
>>> Some people think compatibility with just one AT is sufficient. And they
>>> will argue that Subpart C did not explicitly say that it had to work
>>> with more than one AT. This goes to product brands (e.g. JAWS and
>>> Window Eyes) as well as product types (e.g. refreshable braille displays
>>> and screen readers).
>>>
>>> To stretch this even further, an IT developer could argue that the IT is
>>> perfectly 508-conformant through compatible design, even though it does
>>> not work with any AT on the market currently, because it could work with
>>> AT if the AT manufacturers made the AT differently/better. Or would you
>>> disagree with that? Those of us on the front line providing technical
>>> assistance need this to be clear in the final standards so that our
>>> answers do not sound like they arbitrarily came from Access Board staff.
>>> I want something in writing to put my finger on.
>>>
>>> I skimmed the wiki and archived email discussions but did not see this
>>> directly addressed. This is one of those issues that have come to the
>>> Access Board many times and which need to be resolved in the refresh 508
>>> standards. We would like the TEITAC to address it. Would it be an
>>> interoperability sufficiency issue?
>>>
>>> This is tied to a discussion in January about problems with one version
>>> but not another version of a product. Perhaps all of these variations of
>>> the issue (versions, brands, AT types, etc) could be handled in one
>>> spot.
>>>
>>> David Baquis
>>> Accessibility Specialist
>>> U.S. Access Board
>>> 1331 F Street, NW, #1000
>>> Washington, DC 20004
>>> 800-USA-ABLE; (202) 272-0013 (voice)
>>> www.access-board.gov; = EMAIL ADDRESS REMOVED = "Leading the way to
>>> excellence in accessibility"
>>>
>>>

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