Thread Subject: Re: Group A: 21(c) Keyboard focus

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: Fratkin, Mike
Date: Mon, Oct 30 2006 5:55 AM

I believe that we do need to make this provision broader. An aspect
that needs to be considered is not just the fact of a well-defined
focus, but where the focus should be in specific situations to be most
beneficial to a person with a disability.

As mentioned previously, in Search functions, the results of the Search
is most important and focus seems to vary from application to
application. It is generally at the top of the page, sometimes in the
Search input box but hardly ever focused on the number of hits or
indicating to the user that there were no hits.

For error handling, indicating the number of errors on a page and
guiding the user to the error fields is again an issue of focus and
needs to be considered. Additionally, Help screens where there are
frames with a table of contents in one frame and the actual contents in
another frames is also an issue of focus. When a item is selected in
the left or table of contents frame, typically, the right frame or
content changes. However, the actual focus stays on the left frame and
a screen magnification user would never know that something had changed.

So, it seems like focus issues so need a much broader attention.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi
Snow-Weaver
Sent: Friday, October 27, 2006 9:27 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [teitac-websoftware] Group A: 21(c) Keyboard focus


21(c) current wording:

A well-defined on-screen indication of the current focus shall be
provided that moves among interactive interface elements as the input
focus changes.
The focus shall be programmatically exposed so that assistive technology
can track focus and focus changes.

ISO has two provisions that address this issue: "Software shall provide
a focus cursor that visually indicates which user interface element
currently has the keyboard input focus, as well as the focus location
within that element when one exists." ISO does not contain a provision
specifically addressing programmatic exposure of keyboard focus but it
does include one that requires using system standard input and output
services. If you use standard input services, doesn't that imply that
the keyboard focus is programmatically exposed?

ISO does have a provision on event notification which would cover
keyboard focus changes and all other type of user interaction events:
"Software shall provide assistive technology with notification of events
relevant to user interactions."

It includes the following expanatory note:

Events relevant to user interaction include, but are not limited to,
changes in user interface element status (such as creation of new user
interface elements, changes in selection, changes in focus and changes
in position), changes in attributes (such as size, colour and name), and
changes of relationships between user interface elements (such as when
one user interface element contains, names, describes or affects
another). Just as important are input events, such as key presses and
mouse button presses, and output events, such as writing text to the
screen or playing audio information. This also applies to user interface
status values (such as the states of toggle keys).

Do we want to make 508 broader and more comprehensive in this area?

This function is not required by 508 for Web content and applications
(1194.22). Do we need to add this for Web content and applications? WCAG
2.0 does not contain such a provision.

Andi

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