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

Return to this mailing list's archives

From: Peter Korn
Date: Mon, Feb 05 2007 7:03 AM
Subject: Re: Second draft of the APIRequirements Proposal, cross-referenced to ISO 9241-171

Hi Sailesh,

Thank you for taking the time to review this draft.

The current phrasing stems from two things:

First, in many GUI toolkits a table control is a single control, and it
typically has focus when one of the cells within it is active. As human
beings, we think of the cell has having focus, while in the GUI toolkit
parlance, the cell is the active region of the control that has focus.

Second, again in GUI toolkits, we commonly have table controls (think of
a "mini-Excel"). Sometimes they are called "grid controls". The user
can make a particular cell be active ("have focus"), and then edit the
contents of that cell. This table/grid control must expose
programmatically to AT the location of that cell - that it is at row 5
column C for example - as the user navigates to it to make it active to
edit it.

Because HTML also uses the term "table", I see where the confusion is
coming from.

Would it clarify things for you if we changed the subheading to:

"Additional object information needed for objects within a table or
grid object"

and further changed item #4 to say:

"A mechanism for determining that a cell is active/focused (the one
where user input is directed)"


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> Peter,
> Refer to: "Additional object information needed for objects within a table"
> At
> http://teitac.org/wiki/Web_and_Software:Accessibility_API_Requirements_Propo
> sal
> 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) "
>
> Sailesh Panchang
> 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 =
>
>
>

From: Peter Korn
Date: Mon, Feb 05 2007 7:03 AM
Subject: Re: Second draft of the APIRequirements Proposal, cross-referenced to ISO 9241-171

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.
>
>
>
>
>