Thread Subject: Re: What is good enough to qualify for compatibility with AT?

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: Peter Korn
Date: Mon, Mar 12 2007 3:10 PM

Hi David,

As others have observed, this is a tricky issue. To me, it is also
unlike anything else in Section 508.

Requirements in 508 that say to industry "you must meet this standard",
or "you must expose that information", or "you must meet this set of
functional criteria" can be perfectly objective, clearly understood, and
be 100% the responsibility of the product seeking to meet the 508
requirements.

Something that says, in effect "play well with others" is extremely
difficult to deal with, especially if it is nearly that general a
statement. Even variants of this - e.g. "play well with some others",
or "play well with most others" - are only marginally better. Likewise
"play well with the popular others".

Because who is to say objectively where the fault(s) lie in failing to
play well with another. Or to move away from these grade-school
metaphors, who can say objectively that the reason my application fails
to work well with their AT is because of a failing in my app or their AT?

I understand and appreciate the challenge faced by agencies - Federal
and State - and also users, who simply want a strong level of confidence
that what they purchase will be accessible via assistive technologies.
But unless and until we specify in significant technical detail how apps
& AT are to interoperate with eachother - how they are to "play well"
together - we have no way to even start making that objective evaluation.

Compounded with this challenge is the fact that 508 sets forth
requirements on IT, but not on AT. So we are really in the position of
saying that IT must play well with AT - with AT being allowed (under
508) to completely uncooperative if it so chooses. If AT chooses to
ignore me (perhaps my software application lacks sufficient market share
to be worth any of their time), then I fail this test and am out of luck.


This is why I think 508 should not state that IT must work with AT.
Rather, I think it should set forth a measurable set of technical
requirements for what IT must expose to AT, with additional ancillary
material available that goes into even further detail for any given
platform/OS (what we've discussed as "sufficient techniques"). Then IT
can code to those specific technical standards. And if we have a short
set of "sufficient techniques", I believe that market pressure will lead
AT to support/use those techniques. Because AT does want to support IT
- that is why it exists! But lacking a small set of recognized specific
technical ways of supporting IT, we have the current, unsatisfying
situation we are in now.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> Some people think compatibility with just one AT is sufficient. And they
> will argue that Subpart C did not explicitly say that it had to work
> with more than one AT. This goes to product brands (e.g. JAWS and
> Window Eyes) as well as product types (e.g. refreshable braille displays
> and screen readers).
>
> To stretch this even further, an IT developer could argue that the IT is
> perfectly 508-conformant through compatible design, even though it does
> not work with any AT on the market currently, because it could work with
> AT if the AT manufacturers made the AT differently/better. Or would you
> disagree with that? Those of us on the front line providing technical
> assistance need this to be clear in the final standards so that our
> answers do not sound like they arbitrarily came from Access Board staff.
> I want something in writing to put my finger on.
>
> I skimmed the wiki and archived email discussions but did not see this
> directly addressed. This is one of those issues that have come to the
> Access Board many times and which need to be resolved in the refresh 508
> standards. We would like the TEITAC to address it. Would it be an
> interoperability sufficiency issue?
>
> This is tied to a discussion in January about problems with one version
> but not another version of a product. Perhaps all of these variations of
> the issue (versions, brands, AT types, etc) could be handled in one
> spot.
>
> David Baquis
> Accessibility Specialist
> U.S. Access Board
> 1331 F Street, NW, #1000
> Washington, DC 20004
> 800-USA-ABLE; (202) 272-0013 (voice)
> www.access-board.gov; = EMAIL ADDRESS REMOVED = "Leading the way to
> excellence in accessibility"
>
>

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