Thread Subject: Re: AT support in 508 and 255
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: Hoffman, Allen
Date: Mon, Mar 03 2008 6:40 AM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Brad Hodges: "Re: AT support in 508 and 255"
- Previous message in thread: Gregg Vanderheiden: "Re: AT support in 508 and 255"
- Messages sorted by: Author | Thread | Date
My perspective on this entire AT/IT inter-operability issue is that both
sides are right since this is a chicken-and-egg situation.
If a vendor develops an API (or information exchange mechanism), for an
IT product but no AT vendor takes advantage of it, the government would
be well supported to wait to purchase the new IT product until At does
take advantage of the API. However, this seems to penalize the IT
vendor for doing what they need to do. I suppose they could engage AT
vendors to support the new mechanism during development, tub this seems
to really put a burden on the IT vendor in my opinion.
As the purchaser, I would really just like to be able to access the
information regarding the inter-operability mechanism, and if the
product meets the standards. This goes, for the first part, for AT
products in the software realm also, e.g. what mechanisms do they
support, and use to render information. if I have both pieces of this,
i can determine myself it the products "should" work, rather than if
they in fact do. An IT vendor who claims that a product works 100% with
AT is fooling their buyer generally, since without a specific
compatibility list, this is too broad a statement. This is a challenge
for both groups, AT and IT vendors, but the reality is that the
government can't simply mandate that products "work with an unknown",
without setting boundaries for the unknown. The boundaries for the
unknown are that AT must use, but not be limited to, documented
information exchange mechanisms for IT products they are intended to
provide At services for. In the software realm this is quite broad, but
that is the nature of the game.
Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
- Next message in Thread: Brad Hodges: "Re: AT support in 508 and 255"
- Previous message in Thread: Gregg Vanderheiden: "Re: AT support in 508 and 255"