W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2000

Re: Proposal: Single command input and edits to checkpoints about "easy access" (2.3 and 10.8)

From: Jon Gunderson <jongund@ux1.cso.uiuc.edu>
Date: Tue, 25 Jul 2000 10:13:09 -0500
Message-Id: <>
To: Ian Jacobs <ij@w3.org>, w3c-wai-ua@w3.org
Responses in JRG:
At 10:56 PM 7/24/2000 -0400, Ian Jacobs wrote:
>The term "single command" is used in the UA Guidelines
>in two checkpoints (from the 7 July draft [1]):
>    10.5 Allow the user to configure the user agent
>         so that the user's preferred  one-step
>         operations may be activated with a single input
>         command (e.g., key stroke, voice command, etc.).
>    10.8 Ensure that the default input configuration allows
>         easy activation of frequently used functionalities.
>           Note: Make the most frequent operations easy to
>                 access and operable through a single command.
>The exact meaning of "single command" needs clarification.
>Here are some questions:
>1) For keyboard access, does "single command" mean one
>    keypress only? Or can single command include modifier keys?

JRG: The group has already resolved it means a single key, without modifiers.

>2) What's the maximum number of keypresses that can be
>    considered to constitute a single command?
>    Is "Ctrl-X Ctrl-O" a single command? What about "Ctrl-x x"?

JRG: For 10.5 the group said a single key press so "Ctrl-x x" would be more 
than one key press and not applicable to the requirements for 10.5 as 
currently defined by the group.

>3) How do various OS facilities (such as StickyKeys)
>    fit into the problem? If combinations of modifier keys and
>    other keys are considered single command, does the usage
>    of StickyKeys change that?

JRG: For 10.5 or 10.4 these features are not really relevant.

>4) What happens if the user agent enters a particular input
>    mode, which changes the input configuration temporarily so
>    that a new set of functionalities are one keypress away. Do
>    these keypresses count as single keypress since the user had
>    to do something else to enter the special input mode (e.g.,
>    table navigation mode where single keys may be used to navigate
>    around the cells of the table)?

JRG: Context already enables additional single key fuctionality.  Just look 
at Microsoft's help page for IE 5.0.  It defines some of its keyboard 
functions with modal conditioins like "When in the Address bar, ".  This is 
also apparent in form controls.  When a button, check box or a set of radio 
button controls has focus there are additional one key commands that are 
available to change the state or activate the control.

In your example with tables, just being in the table could automatically 
enable additional navigation commands.

>5) What corresponds to single keypress for voice input?
>    It's probably not "single word" since I imagine being able to
>    say "Page Down". Don't forget internationalization when
>    trying to define the minimal discrete input act. I ask those
>    with experience designing voice-operated interfaces to
>    comment here: how does one express the minimal input
>    act (e.g., what occurs up to the next pause of more than
>    ms milliseconds)?

JRG: Current speech recognition products allow users to define any 
utterance to be any set of words or characters.  You can also retrain voice 
commands.  So I don't think there is the same concept as a keyboard in 
terms of a discrete set of commands and the idea of modifier keys.

>6) What about other input methods such as button activation?
>    Graphical UI is part of input configuration.

JRG: I think we need to be careful about changing behavior of the default 
operating system conventions in menus and dialog boxes for OS that support 
these types of objects.  But as it relates to access to controls that are 
rendered as part of content, I think these should be configurable to allow 

>The following proposals offer a definition of "single
>command input" and way to avoid related but different terms
>that might cause confusion in checkpoints 2.3 and 10.8.
>Proposal 1) Definition: Single command input
>   In this document, single command input means that the
>   action required of the user is the simplest that can be
>   recognized by the user agent for a particular input method.
>   For the keyboard, this means "single key input", i.e., a
>   single key press, without modifier keys such as "alt", "control",
>   "apple", etc. For voice input, "single voice command input"
>   means an individual vocal cue, though the number of words
>   in a command may be more than on (e.g., "Activate link",
>   "Page down", etc.) and should be few in number.
>   For graphical user interface components, single command input means
>   direct activation of the UI control (i.e., buttons, not menu
>   items) with a pointing device.
>   Note that any navigation through UI controls (by pointing
>   devices or keyboard navigation) does not constitute single
>   command input. Double command input means two single commands
>   (e.g., a modifier key and another key), triple means three, etc.
>   The user agent may change the input configuration dynamically,
>   and this may affect the set of single command bindings. The set
>   of single command bindings is relative to an input configuration.
>   For example, when the user is entering text, the number of
>   single key input bindings may be reduced significantly.
>   Or, if the user agent offers a special "table
>   navigation mode" for cell-to-cell or cell-to-header navigation,
>   those single key commands exist within the context of the
>   table navigation mode.
>Note about proposal 1: Delete the part about different input modes
>   from the note after checkpoint 10.5 since now it's in a definition.
>Proposal 2) Checkpoint 2.3
>   At the 20 July teleconference [2], we discussed eliminating
>   the expression "easy access" in checkpoints 2.3 and 10.8.
>   The proposal was to use "single command", which I find very
>   confusing (using the term "single" to describe two different
>   but closely related concepts is a mistake).
>   For checkpoint 2.3, refer to my proposal [3], which uses the
>   term "easy access" but explains the techniques that would meet
>   the requirement. I hope that this proposal satisfies the
>   resolution from the 20 July teleconference [2]:
>     "No objections to modification of Jon's proposal for modification
>      RESOLVED.- accept new proposal with modifications."
>Proposal 3) Checkpoint 10.8
>   For checkpoint 10.8, Jon proposed [4] the following wording:
>      10.8 Ensure that the default input configuration
>           allows one step activation of frequently used
>           functionalities.
>   Rather than "one step" (or "single step") I propose saying
>   something like this:
>   <NEW>
>        10.8 Ensure that the default input configuration
>             offers single or double command access
>             to functionalities the user is likely to use
>             frequently.
>           Note: For example, the default configuration
>           might allow history navigation with arrow keys
>           alone, modified arrow keys (e.g., Alt-left arrow)
>           or both.
>   </NEW>
>Notes about Proposal 3:
>  a) Some background about the goals of checkpoint
>     10.8 provided by Charles in his review with some developers [4].
>  b) There is no resolution marked in the
>     20 July minutes about checkpoint 10.8.
>  _ Ian
>[1] http://www.w3.org/WAI/UA/WD-UAAG10-20000707
>[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0097.html
>[3] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0132.html
>[4] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0032.html
>[5] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JanMar/0243.html
>Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
>Tel:                         +1 831 457-2842
>Cell:                        +1 917 450-8783

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
College of Applied Life Studies
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
WWW: http://www.w3.org/wai/ua
Received on Tuesday, 25 July 2000 11:12:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:27 UTC