Thread Subject: Re: AT Interoperability
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: Debbie Cook
Date: Tue, Aug 14 2007 2:40 PM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Gregg Vanderheiden: "Re: AT Interoperability"
- Previous message in thread: Peter Korn: "Re: AT Interoperability"
- Messages sorted by: Author | Thread | Date
Yes, I would certainly consider a continuem that looks like what Alan
proposes below. Assists agencies to determine "best meets" and addresses my
concern that all efforts do not yield equal re3sults for the end user.
----- Original Message -----
From: "Hoffman, Allen" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, August 14, 2007 12:16 PM
Subject: Re: [teitac-websoftware] AT Interoperability
I have to disagree with this.
I believe Section 508 does need to more clearly define what cooperation
and interoperability between IT and AT means, when possible. Debbie
Cook's point about this potentially being problematic if functional
performance criteria are weakened significantly is valid also. I
support creating more clear AT/IT interoperability requirements that are
incremental, E.G. vendors can meet portions and those who meet more get
more points at evaluation time, and then applying that principle to IT
vendors for all IT products including platforms, software applications,
and AT. This implies that, for example, platform vendors should be
evaluated upon the availability of accessibility services, applications
evaluated upon inclusion of accessibility services for At and from the
platforms they support, and AT evaluated against usage of, or equivalent
alternate provisioning of such services as an interoperability equation.
Agencies need to consider their particular business needs for specific
interoperability with specific AT as they must, but unclear requirements
to "work together" are not measurable in my opinion, and won't get used
at evaluation and selection time well.
So, what gaps would fill this in for the web/software to provide a real
1. We need a standard to indicate the platforms must provide
"accessibility services", that allow them to meet our interoperability
2. We should consider adding a software AT standard that requires use
of such platform accessibility services when available, or equivalent
facilitation of such information.
Finally, when we say programmatically determinable, that may be AT, but
does not have to be.
Let me provide an example as illustration.
Agency needs to procure an item which is a combination of platform and
Vendor 1 meets platform standards, and application meets application
requirements, but there is no At that meets requirements for this
platform. The seller of the "solution" would then respond to all three
sets of requirements. In this simplistic case would get 2 of 3. The
product fails several functional performance criteria because the AT
doesn't get them there.
Vendor two fails platform standards, fails application requirements, but
passes At requirements because some very specialized At exists to
provide this level of access for one group via equivalent facilitation.
They would get 1 of 3, but the FPC might be higher and evens out.
Vendor three meets all standards and gets 3 of 3 and meets the FPC, so
This situation is exactly why the "best meets" language is in the
standard in subpart A, do allow agencies to have some leeway to select
the items that do in reality do what is needed, which is work for people
with disabilities. I don't believe there is a simple way to
specifically require that IT work with AT without some generally agreed
upon foundation of roles and responsibilities in the chain.
Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303