Thread Subject: Re: AT support in 508 and 255
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: Randy Marsden
Date: Mon, Mar 03 2008 8:45 AM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Hoffman, Allen: "Re: AT support in 508 and 255"
- Previous message in thread: Fratkin, Mike: "Re: AT support in 508 and 255"
- Messages sorted by: Author | Thread | Date
With respect to the newly proposed provision that would write AT into
What we need to be clear about is that there AREN'T any API standards
yet. Individual IT companies have started to provide different
accessibility API's on different platforms, and even more than one
company is providing differing API's for the same platform. So, we
can't put a magical check mark in the "API" box and know that AT is
going to work with IT. An IT company may build support for one API
into their product, while the AT company may choose the other, for
example. That is the danger I alluded to earlier: that by putting in
an "AT API Conformance" clause, it will give the false sense of
compatibility without requiring testing. We simply aren't to that
point yet - maybe someday, but not yet.
Let me reiterated, once again, why we think an AT Clause is a bad
idea. First of all, it's not because we don't want to have to do
something for 508. Remember, we are the companies who make our living
from making technology accessible to people with disabilities. We
WANT and NEED to be compatible with IT - that's how we put food on the
table. Adding a clause in 508 is unlikely to provide any more
incentive to do that than we already have (you can't get higher than
100% motivated). So why not just put it in then? Because we are
concerned that it will lower - not increase - the amount of
collaboration that will take place between IT and AT. To be clear,
I'm not talking about the IT companies who are at the TEITAC table -
they are obviously motivated and committed to work with AT. But there
are many who are not, and who would love to be able to say "Yup - we
included the XXX API library in our software build and so we've done
our part in being compatible with AT", end of story. That's not going
to result in products that people with disabilities can readily use.
Finally, AT may have a better way to accomplish accessibility that
doesn't involve an API (especially in the early years as the API's
develop). So mandating that AT must use the newly-provided
accessibility services could potentially result in a step backwards.
Saying the burden is solely on IT without this new AT clause is
inaccurate. The essence of AT is the "burden" of being compatible
with IT, and that will continue whether or not it's written into 508.
My apologies for the long explanation, rather than being language-
specific as Mike has requested. To that point, it is our
recommendation that the New Assistive Technology clause NOT be added
as it will not provide any more incentive to AT than what already
exists, but may leave an opening that IT companies could use to claim
interoperability when in fact there may not be interoperability.
On Mar 3, 2008, at 6:35 AM, Hoffman, Allen wrote:
> 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