Thread Subject: Re: Second draft of the APIRequirements Proposal, cross-referenced to ISO 9241-171

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, Feb 05 2007 7:03 AM

Hi Travis,

This document attempts to lay out a minim set of requirements for an
accessibility API. There are quite a few decisions that I think are
best left up to the designers of any specific Accessibility API on any
specific platform (e.g. UI Automation or the Java Accessibility API).
This for me is one of them.

In Java the GetAccessibleRole() call returns a text string (e.g.
"checkbox"). We have pre-defined a number of strings - they are our
pre-defined roles. At the same time, individual applications can return
a new role string, and so long as they have worked out with AT vendors
what this means and how to use it, all is fine. We've done that several
times in the development of the accessibility implementation of
StarOffice/OpenOffice.org, and the corresponding use of that
implementation by several UNIX AT applications. And the next time we
released an update to the Java platform, we expanded the set of
pre-defined roles to include those new ones.

By contrast, the UNIX accessibility API uses integers for the
pre-defined roles (e.g. the number 5 = "checkbox"), and will only
optionally return a text string for application-defined roles. This
allowed us to expand the set of roles more rapidly than we were able to
update the accessibility API and platform. And again, as with Java,
when it came time for the next release of the UNIX accessibility API and
the GNOME platform, we rolled those new roles into the set of
pre-defined roles.


It is important that applications carefully coordinate anything they do
beyond the defined accessibility API they are using with the AT for that
platform, else their work will fail to provide the benefits to the users
that they desire. At the same time, it is important for the
accessibility API and platform to not artificially limit communication
between AT & IT where the two are actively working together to
communicate information.

Hence my comment that this particular decision is, I think, best left to
those implementing any specific accessibility API on any specific platform.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> Hi Peter,
>
> "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
> types. However,
> does that gap present AT-IT interopreability issues?"
>
> Not sure if this question is directly related for the minimum list, but here
> it is:
> 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?
>
>
> --
> Travis Roth
> Production Manager
> TecAccess, LLC
> (804) 749-8646 (office)
> (402) 466-0907 (direct)
> = EMAIL ADDRESS REMOVED =
> www.TecAccess.net
> 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
> have
> received this communication in error, please reply to the sender indicating
> that fact and delete the copy you received. Thank you.
>
>
>
>
>

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