- 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