- From: Jon Gunderson <jongund@ux1.cso.uiuc.edu>
- Date: Tue, 25 Jul 2000 10:13:09 -0500
- 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: >Hello, > >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 remapping. >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 >2.3 > 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 MC-574 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