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 10:46 AM

I agree for the most part, but it is not always strictly an AT issue.
If I am a keyboard only user, it would be helpful and again more
comparable or efficient to have the focus positioned at the logical
point of attention. This could be the "hits" or the number of errors.
The sighted mouse user can go directly to where he/she needs to go
whereas the keyboard or AT user must use multiple keystrokes to achieve
the same goal.

Mike Fratkin
SSA

Peter Korn wrote:

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.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
Korn
Sent: Monday, October 30, 2006 12:31 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Group A: 21(c) Keyboard focus

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


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