Re: Proposed Section 4.3

Thank you very much for your proposal.
Jon


At 03:04 PM 3/24/99 -0800, you wrote:
>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. 
>
>4.3.1
>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.]
>
>4.3.2 
>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
>such.]
>
>4.3.3 
>Priority 1
>Provide documentation on default keyboard commands and include with user
>agent documentation and/or user assistance system.
>
>4.3.4 
>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.]
>
>4.3.5
>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]
>
>4.3.6
>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
>that]
>
>4.3.7 
>Priority 2
>Allow the user to configure the keystrokes used to activate user agent
>functions.  Wherever possible, allow single key activation of functions.
>
>4.3.8
>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]
>
>4.3.9
>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.)]
>
>4.3.10
>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.]
> 
Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
University of Illinois at Urbana/Champaign
1207 S. Oak Street
Champaign, IL 61820

Voice: 217-244-5870
Fax: 217-333-0248
E-mail: jongund@uiuc.edu
WWW:	http://www.staff.uiuc.edu/~jongund
	http://www.als.uiuc.edu/InfoTechAccess

Received on Thursday, 25 March 1999 10:02:14 UTC