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 15:51:52 UTC