Re: Proposed Section 4.3

Thanks Mark and Chuck for your proposals and comments.
Jon


At 04:48 PM 4/7/99 -0500, mark novak wrote:
>hi all and thanks Chuck:
>
>I like the coverage, my comments are after [mn] below:
>
>
>>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.
>
>[mn] change the last sentence to read:
>
>[mn] The more consistent and apparent the keyboard commands are, the more
>likely it is that users will find them and use them.
>
>[mn] I'm also wondering if here wouldn't be a good place to add some of
>Harvey's
>comments from the WAI CSUN MTG (sent to the UA list, 3-26-99)
>
>
>>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.]
>
>[mn] agree with Chuck's comment that this *should* be covered in 4.3.1
>and I'm not sure if we need to highlight in a separate check point. I'd
>vote not
>needed.
>
>
>
>>4.3.3
>>Priority 1
>>Provide documentation on default keyboard commands and include with user
>>agent documentation and/or user assistance system.
>
>[mn]  unclear just what an "user assistance system."  Is this AT?  Wizard ??
>
>[mn] suggest wording change to include documentation on "default and
>customize-able" keyboard commands....realize you can not document what
>keys are changed until they are changed, i'm referring to documentation as
>to how to query the UA to have it show a list of current key combinations.
>
>
>
>>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.]
>
>[mn] are we safe in assuming that if it is "visual" it will also be aural and
>tactile ?
>
>[mn] reword to "Indicate the keyboard access method to activate a user agent
>function using platform conventions."  techniquies would give examples of
>how to do visually (e.g., underline), aurally, etc.
>
>[mn] move the part about " [For example, under Microsoft Windows,
>underline the accelerator to activate a menu item or dialog box control.]"
>to the techniques doc.
>
>
>>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]
>
>[mn] are we safe in assuming that if it is "visual" it will also be aural and
>tactile ?
>
>[mn] reword to "Indicate the currently "active" element with focus using
>platform
>conventions. "  techniquies would give examples of how to do visually,
>aurally, etc.
>
>[mn] move the part about "[For example, under Microsoft Windows, this would
>be a dotted
>line around the focused control]" to the techniques doc.
>
>
>
>>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]
>
>[mn] this in fact is very important, and indeed is not always visual.  I'd
>opt to
>making this a priority 1 item also, since without proper keyboard focus, the
>magnifiers will have a difficult time "tracking focus" and thus might make
>it "impossible" for low vision (at least in or within some elements?)
>
>[mn]  move the part about "[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]"
>to the techniques doc."
>
>
>
>
>
>
>>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.
>
>[mn]  i'd propose that 4.3.7 could be covered as techniques under 4.3.1.
>
>
>>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]
>
>[mn]  i'd propose that 4.3.8 could be covered as a techniques under
>my slightly changed 4.3.3 above.
>
>
>
>
>
>
>>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.)]
>
>[mn] propose as a technique under 4.3.1, more of just a convenience
definition,
>all functions have keyboard access, and these are additional "more
convenient"
>or shortcuts you can use with some of them ...
>
>
>>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.]
>
>[mn]  propose as a technique under 4.3.3, hard or not, it *still* needs to
>be in the documentation, and I don't think this needs a separate checkpoint.
>
>[mn] mark
> 
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, 8 April 1999 13:13:07 UTC