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:05 AM

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