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: Wed, Aug 15 2007 8:05 AM

Hi Randy,

[adding General SC to the distribution]

> Well, we agree on your last point of trying to come to a close on
> draft language. I actually haven't seen a specific provision cited
> anywhere in this thread. What specific section(s) are we talking
> about? I was reacting generally to your suggestion (which I thought
> was generally stated) about removing the burden of IT to interoperate
> with AT. I expect that covers a number of sections in both the FPC
> and the Technical Criteria.

I don't believe that was my suggestion; certainly not in this thread.
In the General SC we are discussing the language of the FPC and the role
of the FPC. I and others have argued that the current draft FPC are not
testable. It has also been noted multiple times that the FPC we've been
using since 2001 aren't being tested to, for similar reasons (in fact,
in general the Access Board asked TEITAC to improve the language of the
technical provisions in order to make them testable).

The circa 2001 FPC says "... or support for assistive technology...
shall be provided" for most of the provisions. I know there is a lot of
history and different interpretations of this language. But clearly,
the language doesn't say "IT is solely responsible for making AT work
with IT"; nor does it say "IT must create AT"

Looking at the other software provisions that talk about AT, we have
1194.21(c): "...focus shall be programmatically exposed so that
assistive technology can track focus and focus changes"; and 1194.21(d):
"...information about a user interface element... shall be available to
assistive technology"; and 1194.21(l): "When electronic forms are used,
the form shall allow people using assistive technology to access the
information."

Nothing in this text that we've had from before says that IT bears the
sole burden of interoperating with AT. What we have are specific
technical means IT must use to provide information that AT needs. Our
updated provides have only expanded that (something I have consistently
and forcefully pushed for).

As Andi noted (and also Debbie), this review of the AT Interoperability
provision was triggered by discussions in the General SC around the
FPC. Specifically about whether the FPC should require:
"Full use without Vision - in at least one mode (direct or via AT)"
(April 16 General SC draft)
"At least one mode shall be provided ... directly or with users' AT."
(May 30th draft)
"At least one mode must be provided ... directly or via AT." (July 6th
draft)
"Products must provide at least one mode... provided directly or
through assistive technology." (August 13 draft)

Defining "full use" was a huge problem. Demanding that this be "with
users' AT" isn't workable when we talk about all of the different
agencies and their different AT, let alone the general public, and also
means that innovation ends with this requirement since as long as one
user is clinging to an old version that doesn't support something,
nobody can use IT that needs that support. For the "via AT" and
"through assistive technology" language runs into the problem of
testability. We can't test this without defining what this means. For
either of these, is it sufficient to demonstrate that a single AT
product in any given category works (what if the agency doesn't use that
AT)? What about cross-platform products (a cross platform app that
works well with the built-in AT on the Macintosh, but not with similar
AT on Windows)? And what about version issues (my favorite hobby horse:
a Java app that worked with one version of JAWS, but not a later version
of JAWS)?

How can we possibly demand - and test - this scenario?


This is why, again, I believe what we can achieve in a testable
provision is a very detailed enumeration of the information IT must
provide AT. Ideally, what must be provided in the platform specified
(and AT supported) accessibility services.


But let me turn this around Randy. Why shouldn't there be a burden on
AT to work with IT?

>
> I definitely don't want to hold up the process. Just let me know what
> specific wording or section you're proposing to change, and let's see
> if we can't come up with mutually agreeable language.


As Andi suggests in another note in this thread, this should probably be
moved to the General SC. I've cc-ed that mailing list. We should fully
move this there, I think. Would folks replying please drop the Web &
Software e-mail alias from the To: field?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

>
>
> On Aug 14, 2007, at 1:52 PM, Peter Korn wrote:
>
>> Randy,
>>
>> I'm sorry, but I don't understand what *specifically* you are
>> recommending.
>>
>> Right now the draft FPC is not testable, and agencies have told us they
>> don't even try to test it. If we go back to the original FPC which says
>> "support for AT", then we have something we can test, and with the "AT
>> Interoperability" provision, we have a specific testable set of
>> behaviors for IT to do.
>>
>> Would that satisfy you?
>>
>> Or, when you say "leave it the way it current is", you mean have no AT
>> Interoperability provision at all (no enumeration of what IT must
>> provide at a technical level to AT)?
>>
>> Or, do you mean we have the current draft FPC, but make it clear that it
>> is not intended to be a testable provision.
>>
>>
>> We are trying very hard to come to a close on draft language to send to
>> the Access Board. In order to move the discussion forward, we need to
>> be discussing *specific* language suggestions. Otherwise we get nowhere.
>>
>>
>> Regards,
>>
>> Peter Korn
>> Accessibility Architect,
>> Sun Microsystems, Inc.
>>
>>> That was not the point I was making (but nice try) :-)
>>>
>>> My point is that a technical interoperability standard doesn't exist
>>> today. And yet we are trying to come up with something that is
>>> "testable" for interoperability in Section 508. In my opinion, you
>>> can't have one without the other. That's why we are all having such
>>> difficulty with this issue.
>>>
>>> My suggestion for something better is that until a generally accepted
>>> technical standard exists, leave it the way it currently is: simply
>>> state that IT should work with AT. Is that vague? Yes. Will it
>>> require interpretation at the agency level? Yes. Is that anything
>>> new? No.
>>>
>>>
>>> -Randy
>>>
>>>
>>> On Aug 14, 2007, at 1:04 PM, Peter Korn wrote:
>>>
>>>> Hi Randy,
>>>>
>>>>
>>>> The "consensus" I was referring to was that we weren't going to
>>>> require
>>>>
>>>> AT to support an API, or make any other explicit requirements on AT in
>>>>
>>>> Section 508. This was something I understood was particularly
>>>> important
>>>>
>>>> to ATIA. What I see you saying now, below, is that you hope to be
>>>> able
>>>>
>>>> to change the wording of Section 508 to place a requirement on AT (you
>>>>
>>>> wrote: 'Someday, I hope we will be able to change the wording of
>>>> Section
>>>>
>>>> 508 to say something like "AT and IT products must conform to the
>>>>
>>>> ABC123XXX interoperability standard".'). Doing that would essentially
>>>>
>>>> mean that AT that didn't conform to your theoretical ABC123XXX
>>>>
>>>> interoperability standard could NOT be acquired by agencies under 508.
>>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>

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