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: Jim Tobias
Date: Wed, Aug 15 2007 9:40 AM

One way of resolving this problem is to require the vendor, at some point in
the procurement
process, to reveal what AT or AT-compatibility testing tool was used, and
what the results were.
This approach has the advantage of finessing the absence, for now, of an
AT-IT compatibility API.
It would improve over current practice, in which vendors may or may not
report any testing
results or even what was tested. It would leave it up to the vendors and
their customers to
determine what is sufficient -- a disadvantage, I think, but a realistic one
-- while motivating
vendors to increase the AT against which they test. Such a solution might
even spur the
development of the API, because this reporting requirement would chafe
against IT vendors, AT
vendors, and federal employees with disabilities whose preferred AT was not
being tested against.

Clearly, there would still be lots to debate over whether all this info
shows up in a VPAT or
only when a specific RFQ/RFI or negotiation is underway. But as I see it,
the only rigorous
alternative would be to create a list of AT, including models and versions,
with which compatibility
is required. If I remeber correctly, we couldn't even agree to create a
list of AT *categories*.

Can TEITAC or even the Access Board make such a requirement stick? Maybe
not -- it seems like a
FAR provision to me. But we can make this recommendation, and it's a far
more realistic and
workable solution than any technical provision could be in the current state
of API underdevelopment.

***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias


> -----Original Message-----
> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Wednesday, August 15, 2007 11:03 AM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] AT interoperability
>
> Hi Jessica, et al.
>
> You should be aware that in the functional area - there is a
> proposal to say that conformance to the technical provisions
> would mean automatic fulfillment of the FPC. There is a
> statement in a government FAQ and in preamble that supports
> this point of view at least for software aspect.
>
> Thus - if "support for AT" but not "compatibility with actual
> AT" is all that is required in the technical requirements -
> then working with actual AT would not be required anywhere.
>
> The questions therefore are:
> - when the AT industry agreed on the technical provisions did
> they understand them to say that "support for AT" (e.g. an
> API) was sufficient to meet the technical provision or did
> they understand the wording to mean that the software had to
> work with actual AT. That is, do they require companies to
> work with AT industry to make sure their products work - or
> could industry just build to an API and say the rest of the
> problem belongs to the AT companies.
> - this is not to say that the companies here don't work
> with AT companies today. The question is simply - do the new
> 508 regs REQUIRE that companies'
> products work with AT? Or do the regs only require that
> products have an AT interface - and it is up to AT to work
> with what is there?
>
>
> There was also a statement on the list that this was just a
> problem between AT and IT and it was only their concern. I
> believe that there is a substantial issue for people who have
> disabilities too.
> - With the "products need to work with AT" approach -
> products purchased would have AT and could be used by
> employees with disabilities.
> - With the "support for AT" approach - products could pass
> 508 if they had an AT interface even if there was not AT that
> worked with them. That would mean that there is no
> requirement that products that passed 508 would in fact be
> usable by employees with disabilities.
> So I think people with disabilities also have a concern
> or interest in this distinction. So I don't think it is
> purely an AT-IT industry concern.
>
> Since we have the final Software Call today at 1 EST before
> the lock down this is important.
>
> This is not a new or last minute issue. It has been brought
> up repeatedly but the language is now solidifying -- and
> there appears to be a problem with different people
> interpreting the same language in different ways.
> The current wording can be read either of the two ways
> discussed above.
>
> We need to at least add a note that clearly states which
> interpretation is intended by the language - so that we can
> determine if consensus exists for
> the language or not. And if so - does it mean "provides and
> interface that
> AT can use?" or does it mean "Works with AT that exists".
>
>
> PS
>
> Suggestion
>
> 1) that we say that conformance with 508 means that it works with AT.
> 2) that if there are no products that work with AT then the
> agency should purchase the product that has an API for AT as
> a fallback to leave best opportunity for access in the future.
>
> But to purchase a product with an API but no AT instead of a
> product that works with real AT should not be "ok" or what
> the 508 regs allow.
>
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Jessica M. Brodey
> > Sent: Wednesday, August 15, 2007 8:28 AM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] AT interoperability
> >
> > Andi:
> >
> > I couldn't agree more. We worked at length with IT to develop that
> > proposal, and we believe it will greatly improve
> interoperability in
> > the future.
> >
> > >From our perspective, the functional performance criteria
> should set
> > >the bar
> > for the end results (e.g., one mode that provides access without
> > vision either on its own or through the use of AT).
> > We are not set on one phrase to convey that concept - we are still
> > open to conveying that message either through the old
> phrasing or new
> > language. The technical provisions should help ensure that
> these end
> > results are achieved. With that being said, the technical
> standards
> > do not set forth every step necessary for AT and IT to work
> together.
> > It is possible to follow every provision and for AT & IT
> not to work
> > together. The FPC therefore focus on the result, the technical
> > standards set forth the components that MUST be done to
> reach the end
> > result, and the rest is for IT and AT to work out together on a
> > case-by-case basis. Is this ideal?
> > No - we would love to be able to point to a
> > standard(s) and say "if you do this, interoperability will
> happen."
> > We don't have that yet - perhaps someday soon we will. Our
> goal is to
> > ensure that we do not take a step backward from existing
> regulation,
> > and continue to require actual compatibility for the products the
> > federal government purchases at least to the same degree required
> > today.
> >
> > Jessica
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Andi
> > Snow-Weaver
> > Sent: Tuesday, August 14, 2007 6:18 PM
> > To: = EMAIL ADDRESS REMOVED =
> > Subject: Re: [teitac-websoftware] AT interoperability
> >
> >
> > This discussion has taken a hard left turn away from the
> specific AT
> > interoperability provision to the bigger issue of functional
> > performance.
> >
> > I will remind everyone that the proposed AT interoperability was
> > developed between AT and IT vendors who are the ones that
> ultimately
> > have to solve this problem and has been agreed to since sometime in
> > April I think. And it is much stronger than the vague
> requirement for
> > object information to be programmatically exposed that is in the
> > current (2001) 508 standard. So with just this one
> provision, we can
> > improve things over the current situation even if we keep the 2001
> > wording for the functional performance criteria.
> >
> > This issue is being debated at length in the general
> subcommittee and
> > they have scheduled another call tomorrow to continue looking for a
> > solution.
> > This discussion needs to be happening on the general subcommittee
> > mailing list to ensure that everyone's point of view is considered.
> >
> > Andi
> >
> >

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