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: Gregg Vanderheiden
Date: Wed, Aug 15 2007 9:15 AM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Jim Tobias: "Re: AT interoperability"
- Previous message in thread: Gregg Vanderheiden: "Re: AT interoperability"
- Messages sorted by: Author | Thread | Date
A couple notes
1) this did NOT come out of a discussion on the General Thread. It came out
of a review of the technical provision here called "AT Interoperability"
which was part of a review of all the Software provisions.
2) this issue is not covered by General. And can't be if the current
language of the FAQ and preamble are used. They specifically say that (at
least for software) conformance to the technical provisions automatically
means conformance to FPC.
So as things are currently being argued, - if working with real AT is not
required in the technical provisions then it won't be required anywhere.
This was not the intent of the last advisory group - nor the understanding
of many who thought that the current language meant that IT would need to be
tested with real AT. Not all AT. But at least some.
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Peter Korn
> Sent: Tuesday, August 14, 2007 7:10 PM
> To: TEITAC Web/Software Subcommittee; TEITAC General
> Interface Accessibility Subcommittee
> Subject: Re: [teitac-general] [teitac-websoftware] AT Interoperability
>
> 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.
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> --------------------------------------------------------------------
> >>> ----
> >>>
> >>>
- Next message in Thread: Jim Tobias: "Re: AT interoperability"
- Previous message in Thread: Gregg Vanderheiden: "Re: AT interoperability"