Re: Proposed Section 4.3

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

Received on Wednesday, 7 April 1999 18:20:53 UTC