Thread Subject: Second draft of the API Requirements Proposal, cross-referenced to ISO 9241-171
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.
In the January 3rd Web & Software subcommittee meeting, we had a
discussion of the first "API Proposal", and a few of us took the action
to review the proposal in the context of the language on "Compatibility
with assistive technology" in ISO 9241-171, Section 8.6. See:
for a summary for a summary of that January 3rd discussion, and
the original proposal that Andrew Kirkpatrik and I put together last
In the intervening weeks since January 3rd, Sean Hayes and Rich
Schwerdtfeger joined the original group who drafted and reviewed that
original proposal (unfortunately we didn't manage to get engineering
review from any ATIA members). We have finished a thorough comparison
of what the original proposal stated, and the requirements (phrased in
much more general terms) in ISO 9241-171, Section 8.6.
As a result of this work, and additional discussions and thoughts and
review among this group, we have:
1. Renamed this work to "Accessibility API Requirements Proposal",
to more accurately reflect what it is. It isn't a proposal for
any specific API, or even a proposal what should be done in 508
with APIs. Rather, it is a distillation of what any Accessibility
API must have in it in order to be effective - at a minimum with
least today's desktop systems - to support AT-IT interoperability.
2. Removed the "General system information" section of the original
proposal, as that was the one thing that went beyond the scope
of ISO 9241-171 Section 8.6.
3. Added a few new requirements that flow from ISO 9241-171 Section
8.6 that we had not thought initially to put into the proposal
4. Made a few other changes, largely stemming from concerns about
new graphic rendering techniques now being released, or soon on
the horizon, in desktop IT systems.
5. Annotated each specific API requirement with links to the
corresponding language in ISO 9241-171 Section 8.6 that requires
Please see this second draft at:
and specifically the notes to this update, at:
You may also find our dissection of the language in ISO 9241-171 Section
8.6 and the portions of the API Requirements Proposal that support each
portion of that dissection illuminating as well. See that at:
As before, these are draft documents, subject to further discussion, and
Sun Microsystems, Inc.
Refer to: "Additional object information needed for objects within a table"
Comment: I am confused. Is the reference to editable content like form
controls in a table... the fourth (last) item in the list suggests it is.
If they are form controls in a table, their row / column positions are
unimportant as long as the controls are labeled completely.
And if they are not interface elements but just text or links in a table
then row/column position is relevant. In which case the reference to 'user
input' in the fourth list item is not ok.
Perhaps the solution is to re-word item #4 to
"4. A mechanism for determining that a cell is active (the one where user's
focus is directed) "
Senior Accessibility Engineer
Deque Systems Inc. (www.deque.com)
11130 Sunrise Valley Drive, Suite #140,
Reston VA 20191
Phone: 703-225-0380 (ext 105)
E-mail: = EMAIL ADDRESS REMOVED =
"Questions about this document:
1. This document doesn't contain a set of minimum roles. This is
intentional, as that would imply a minimum set of user interface element
does that gap present AT-IT interopreability issues?"
Not sure if this question is directly related for the minimum list, but here
What happens if a new role is created by a new interface element being
created, such as a custom component in Java?
Should the component convey through the Role information that it comprises
various other roles? Or should AT have to learn to handle the new Role? And
what should happen if the AT has not yet been updated?
(804) 749-8646 (office)
(402) 466-0907 (direct)
= EMAIL ADDRESS REMOVED =
Experts in Section 508 Compliance & Accessibility
NOTICE: This communication may contain privileged or other confidential
information. If you are not the intended recipient or believe that you may
received this communication in error, please reply to the sender indicating
that fact and delete the copy you received. Thank you.