- From: <schwer@us.ibm.com>
- Date: Wed, 23 Jun 1999 09:57:04 -0500
- To: Ian Jacobs <ij@w3.org>
- cc: w3c-wai-ua@w3.org
Ian,
This is much better.
There are some checkpoints I have in our Java guidelines that may be useful. The
keyboard bindings issue may in principal be covered by the checkpoint discussing
operating system conformance.
I have a few items from our Java accessibility guidelines that may also be
useful checkpoints.
Keyboard Bindings
In Java, you never know what system your application might run on. Therefore,
you must consider how keyboard conflicts might affect the usability of your
keyboard implementation. Take the following steps to prevent conflicts with the
underlying operating environment:
Make sure the keyboard bindings you select do not conflict with system
keyboard mappings of the underlying operating system. For example, Ctrl+Alt+Del
might cause you to reboot or offer a shutdown option on some systems.
Make sure the keyboard bindings you select do not interfere with the
reserved mobility access keyboard modifiers for your operating system. See
section
11.1.3 Reserved Key Mappings for Mobility Access Features.
Navigation Order
It is important that application developers maintain a logical keyboard
navigation order. The navigation order is defined as the order with which you
use the keyboard
to navigate between components and component elements in your graphical program.
Navigation is accomplished by tabbing between components or groups, and
using the arrow keys within a component group or component's elements.
Tabbing
The ability to tab between software components is a key feature in the
implementation of keyboard accessibility. A component is inclusive in the
tabbing order when
added to a panel and its isFocusTraversable() method returns true. A component
can be removed from the tabbing order by simply extending the component,
overloading this method, and returning false.
Excessive use of tabbing can reduce the usability of software for both disabled
and non-disabled users. As a developer, you need to determine the point at which
tabbing gets in the way and provide a keyboard alternative. This is done through
the use of keyboard Mnemonics and Accelerators.
Tab Groupings
Buttons of common functionality, such as a set of radio buttons used to set the
location of a panel (top left, bottom left, and so on.), should be grouped
together so
the first element of the visible group can be tabbed to. The arrow keys can be
used to navigate to each end of the group.
Rich
Rich Schwerdtfeger
Lead Architect, IBM Special Needs Systems
EMail/web: schwer@us.ibm.com http://www.austin.ibm.com/sns/rich.htm
"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the difference.", Frost
Ian Jacobs <ij@w3.org> on 06/17/99 01:29:50 PM
To: w3c-wai-ua@w3.org
cc: (bcc: Richard Schwerdtfeger/Austin/IBM)
Subject: Guideline for Keyboard accessibility
Reference document:
http://www.w3.org/WAI/UA/WAI-USERAGENT-19990611
At the 16 June WG teleconf [1], the WG expressed a
desire to create a guideline specific to keyboard
accessibility. The idea is that keyboard accessibility
is important for ensuring compatibility between desktop
browsers and dependent user agents.
The 11 June draft of the guidelines distributes keyboard-related
checkpoints to guidelines about device-independence, documentation,
configurability, and following system conventions. In this proposal,
those checkpoints would be regrouped under a single guideline,
with cross references back and forth from other guidelines.
GUIDELINE: Ensure accessible keyboard access to user agent
functionalities
RATIONALE: Some text here about keyboard access
being important to ensure compatibility.
CHECKPOINTS:
- By default and without additional customization, ensure that
all functionalities offered by the user agent are
accessible using the
keyboard. [Priority 1] Cross-ref to device-independence guideline.
- Allow the user to configure the keystrokes used to activate
user agent functionalities. Wherever possible,
allow single key activation of functions. [Priority 2]
Cross-ref to configuration guideline.
- Indicate the keyboard access method to activate a user agent
function using platform conventions. [Priority 2] Cross-ref
to guideline about system conventions. E.g., underlined letters
in menu entries.
- Provide documentation on default keyboard commands and
include with user agent documentation and/or user help
system. [Priority 2] Cross-ref to guideline on documentation
- Provide information to the user about the current keyboard
configuration. [Priority 2] Cross-ref to guideline about
documentation.
PROPOSED ADDITIONAL CHECKPOINTS:
- Provide default keyboard configuration for frequently performed
operations [Pri 3]
- Others?
There are two checkpoints that should probably remain in other
guidelines since they are more general (and cross references
used):
a) 11.6 Follow operating system conventions and accessibility
settings. In particular, follow conventions for user
interface design, default keyboard configuration,
product installation, and documentation. [Priority 2]
b) PROPOSED: "Define default keyboard configurations consistently
between software versions. Changes should not be
made arbitrarily and should improve accessibility
or consistency with platform conventions."
Perhaps Priority 3?
This second checkpoint will appear in a separate proposal
for a guideline about software consistency. If the Working
Group elects to include a single checkpoint about keyboard
configuration consistency, that checkpoint would naturally
fall under the keyboard accessibility guideline.
I do not think we need to have checkpoints specifically for
keyboard navigation and activation of active elements. They
can be listed in prose or as examples to emphasize their
importance, but are covered by the first checkpoint.
- Ian
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999AprJun/0205.html
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel/Fax: +1 212 684-1814
Received on Wednesday, 23 June 1999 11:03:05 UTC