Thread Subject: Re: 21 g - revision
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: David Poehlman
Date: Wed, Mar 28 2007 9:50 AM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: David Poehlman: "Re: 21 g - revision"
- Previous message in thread: Gregg Vanderheiden: "Re: 21 g - revision"
- Messages sorted by: Author | Thread | Date
Oh, it is necessary to provide guidance in the standards on this,
document only could wind up being something inaccessible.
On Mar 27, 2007, at 5:05 PM, Lybarger, Barbara (MOD) wrote:
1. Wouldn't this approach be problematic for the open source community,
as many of those efforts are not documented well, and some not at all.
2. How about just "documented" for the 508 standard? That might motivate
the open source folks to document, and would save a fight about what
"industry standard" one is talking about.
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi
Sent: Tuesday, March 27, 2007 4:30 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] 21 g - revision
To your question about what does the phrase "documented according to
industry standards" used in 21(b) and the proposed 21(g) mean?
The only guidance provided currently by the Access Board on 21(b) is the
What is the application programming interface?
The application programming interface, (API) refers to a standard way
for programs to communicate with each other, including the operating
system, and with input and output devices. For instance, the application
programming interface affects how programs display information on a
monitor or receive keyboard input via the operating system.
What are accessibility features?
Many commercially available software applications and operating systems
have features built into the program that are labeled as accessibility
features. These features can typically be turned on or off by a user.
Examples of these features include: reversing the color scheme (to
assist people with low vision), showing a visual prompt when an error
tone is sounded (to assist persons who are deaf or hard of hearing), or
providing "sticky keys" that allow a user to press key combinations
control-C) sequentially rather than simultaneously (to assist persons
with dexterity disabilities). This requirement prohibits software
programs from disabling these features when they have been activated
prior to running the application.
<end of AB guidance>
and from the 508 preamble:
Comment. The proposed rule only specified that software not interfere
with features that affect the usability for persons with disabilities.
Commenters from industry noted that the provision in the NPRM did not
provide any method of identifying what features are considered access
features and further stated that this provision was not achievable.
These commenters pointed out that it was impossible for a software
producer to be aware of all of the features in all software packages
that could be considered an access feature by persons with disabilities.
Sun Microsystems recommended that this provision address access features
that have been developed using standard programming techniques and that
have been documented by the manufacturer.
Response. This provision has been modified in the final rule to
reference access features which have been developed and documented
according to industry standards. No other changes have been made in the
<end of preamble text>
So I think this is open to interpretation and I think you would find
that there are wide variations in how this checkpoint is interpreted. As
I said before, the subcommittee was unable to agree on a better wording
for 21(b) so we decided to at least make the wording of 21(g) consistent
Frankly, I am more concerned about the requirement to not interfere with
the accessibility features of "other products". A software application
runs on some "platform" and you can search through the platform
documentation to find the accessibility features. You could argue
whether or not they are "documented according to industry standards" but
if they're documented at all, that's something tangible you can use to
measure compliance with this requirement. But you can never guarantee
that you will not interfere with the accesssiblity features of "other
products" because the set of other products is infinitely large. You
could never complete your testing if you even tried to do this.