- From: Ian Jacobs <ij@w3.org>
- Date: Fri, 09 Jul 1999 15:54:15 -0400
- To: schwer@us.ibm.com
- Cc: w3c-wai-ua@w3.org
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