W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 1999

Proposed Section 4.3

From: Charles Oppermann <chuckop@MICROSOFT.com>
Date: Wed, 24 Mar 1999 15:04:52 -0800
Message-ID: <BB61526CDE70D2119D0F00805FBECA2F07CF565C@RED-MSG-55>
To: w3c-wai-ua@w3.org
At the last conference call, I volunteered to rework section 4.3.  This is
the keyboard area for the browsers user interface.  

Here is my proposed section.  I've added several high priority checkpoints
to cover the basics and to go beyond the basics, there are new lower
priority checkpoints.

Guideline 4.3 Support accessible keyboard input

Providing a good keyboard interface is one of the most important aspects of
user agent accessibility, because it affects users with a wide range of
disabilities. It is also a usability feature for many people who do not have
disabilities.  Users have different needs with regard to keyboard access,
including single key activation, and the physical proximity of keys.
Additionally, uses of various accessibility aids, such as speech input and
programmable tablets require their input to be mapped to keyboard commands.

By default, the keyboard interface should be consistent throughout the user
agent interface and where practical, follow platform conventions.  The
keyboard commands and shortcuts must be documented and available to the end
user.  The more consistent and apparent the keyboard commands are to all
users, the more likely it is that new users with disabilities will find them
and use them. 

Priority 1
By default and without additional customization, all functions of the user
agent must be accessible using the keyboard

[Conflicts with the existing 4.2.1 which is input device independence.  As a
implementation checkpoint (and not a general guideline), I think they should
be called out separately.  The requirement that this is by default prevents
someone from ducking the rule by making keyboard access something you have
to set up afterwards - which 4.2.1 would allow.]

Priority 1
Graphical user agents that have multiple windows or panes must provide a
keyboard accessible way to show, hide, resize and move the window or pane.

[Yes, it should be covered under 4.3.1, but often isn't implemented as

Priority 1
Provide documentation on default keyboard commands and include with user
agent documentation and/or user assistance system.

Priority 1
Visually indicate the keyboard access method to activate a user agent
function using platform conventions.  [For example, under Microsoft Windows,
underline the accelerator to activate a menu item or dialog box control.]

Priority 1
Visually indicate the currently focused active element using platform
conventions.  [For example, under Microsoft Windows, this would be a dotted
line around the focused control]

Priority 2
Expose the current keyboard focus location within the user agent interface
to assistive devices using existing platform technologies.  [For example,
under Microsoft Windows, call the Win32 API SetCaretPos() or support Active
Accessibility.  This benefits accessibility aids that need to track the
current focus location, such as Screen Magnifiers and Screen Readers]

[Rationale:  Many browsers now have panes that are considered the user
interface, but not part of the HTML document.  IE's Explorer bars and
Opera's windows contain UI elements that may or may not support system
conventions for exposing focus location]

[FYI - this is a Windows logo requirement, but I have it down as Priority 2.
I, personally, feel it should be a priority 1, but others should debate

Priority 2
Allow the user to configure the keystrokes used to activate user agent
functions.  Wherever possible, allow single key activation of functions.

Priority 2
Ensure that the user can discover the current keyboard configuration [was
bindings - too techie].

[Rationale - There may appear to be overlap with 4.3.3, but if the product
does allow customization, it will be very difficult to dynamically update
the products documentation/user assistance system with the current commands.
Since most users will not customize the keyboard, the default commands
should be listed in the documentation.  This is where users go to find
information.  That is why 4.3.3 is priority 1 and this is priority 2]

Priority 3
Provide quick shortcuts by default to commonly used functions such as
"Print" or "Open Document".  Use existing platform conventions wherever
possible.  [For example, CTRL+P to print the document.  This goes beyond
4.3.1 by allowing the user to quickly access a UA function without having to
go through a series of steps (like ALT+F for file, P for Print, etc.)]

Priority 3
For a function that requires a number of keystrokes, or is particularly
tedious to activate, or has a non-obvious keyboard method, the user agent
documentation should list the keystrokes necessary.  [For example, using the
Organize Favorites feature in IE - there should be a help topic on how to do
that via the keyboard.  You can do it via the keyboard, thus meeting 4.3.1,
but it's not easy and non-obvious]

[Note:  This requires some wordsmithing.]
Received on Wednesday, 24 March 1999 18:05:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:48:49 GMT