Re: Guideline for Keyboard accessibility

>Some of them look like potential checkpoints, others techniques.
>I think we should review the proposal at the next teleconference.
>The draft that will be published today will not include these proposals.

OK.

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 07/09/99 02:54:15 PM

To:   Richard Schwerdtfeger/Austin/IBM@IBMUS
cc:   w3c-wai-ua@w3.org
Subject:  Re: Guideline for Keyboard accessibility





schwer@us.ibm.com wrote:
>
> Ian,
>
> This is much better.

Yeah! Thank you Rich.

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

Some of them look like potential checkpoints, others techniques.
I think we should review the proposal at the next teleconference.
The draft that will be published today will not include these proposals.

 - Ian

> 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

--
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel/Fax:                     +1 212 684-1814

Received on Friday, 9 July 1999 16:41:01 UTC