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: Peter Korn
Date: Mon, Oct 30 2006 10:35 AM

Mike Fratkin wrote:
> 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.
>

I think we should be careful with the word "focus", which generally
means "where keyboard input will go". This makes sense for something
like a search input box, but no the static text indicating the number of
hits.

What I think is wanted is a way for E&IT to indicate to AT that
"something new and interesting has happened here; you might want to
convey it to your user". What I think we don't want is for E&IT to
explicitly drive AT - that gets us into the dangerous territory of
designing for specific AT (e.g. this is what you need to do to make JAWS
say "number of search hits: 20").

We deal with this situation in the UNIX & Java worlds by giving things
the role STATUS_BAR, with the convention that screen readers will in
most cases want to read changes in the status bar to the user (there is
an event we fire in UNIX/Java to indicate that text has changed). A
user wanting less verbosity, or a custom script in the screen reader for
that app may then not speak those changes; but the information is there
for the user & AT to make that determination.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

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