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

HTML5 Facilitate organizing keyboard commands

From: Greg Lowney <gcl-0039@access-research.org>
Date: Wed, 27 Jul 2011 21:42:38 -0800
Message-ID: <4E30F6CE.3080708@access-research.org>
To: WAI-UA list <w3c-wai-ua@w3.org>
CC: Janina Sajka <janina@rednote.net>
Hi! I've added this to the wiki at http://www.w3.org/WAI/UA/work/wiki/HTML5_review_by_UAWG_notes#Facilitate_organizing_keyboard_commands:


          Facilitate organizing keyboard commands

Added by Greg Lowney <http://www.w3.org/WAI/UA/work/wiki/index.php?title=User:Glowney&action=edit&redlink=1> 04:39, 28 July 2011 (UTC)

Defining generic commands that have associated keybindings is an extremely powerful mechanism that lets user agents give the user control over keybindings. One use of this is to automatically generate documentation for the user providing a reference and guide to the keyboard commands as they're actually configured. However, a long, unorganized list of keybindings, while better than nothing, is still extremely difficult to use. This could be much easier if the user agent (or tool) could organize the list, as well as allowing the user to filter and navigate it intelligently. This would be possible if the author could provide hints with each command, such as recommended categories or keywords.

*Use case:* Carlos relies on the keyboard, and command keybindings are very important way for him to perform tasks efficiently. He is using a web-based application, and asks his web browser to present a list of all the commands defined by the web-app, which he can consult and print out for future reference. The browser has already processed all the commands defined in the HTML source, including those created by interactive elements with acccesskey as well as those command elements that associate an action with a keyboard input. Unfortunately, this list is very long, especially if it's combined with the browser's own commands. Luckily, the browser's dialog box contains buttons for sorting the list alphabetically or by category (e.g. commands relating to tables, commands relating to view options, commands for formatting, etc.), and it's able to do that because the author was able to supply a user-friendly name and category (or keywords) for each command. When Carlos wants to 
look up a command but doesn't know the name assigned to it, or wants to look up a bunch of related commands, he can use the category view, just like those provided in printed software user guides. When he already knows the official name of the command, he can use the alphabetical view to find it quickly. Note that this is particularly important when Carlos moves between different user agents that assign different keybindings to the author's commands.

*HTML5 Status:* HTML5 lets the author provide a user-friendly name for command elements, but

*Recommendation:* HTML5 should allow the user to associate a category or, even better, multiple categories or keywords, with each author-defined command. My preferred method would be to allow a keywords or tags attribute on any element that can be used to define a command (that is, all the methods described in section 4.11.5 Commands <http://www.w3.org/TR/html5/commands.html>), as discussed in more detail elsewhere in this document (see 11 Standard pieces of information should be automation-friendly <http://www.w3.org/WAI/UA/work/wiki/HTML5_review_by_UAWG_notes#Standard_pieces_of_information_should_be_automation-friendly>). There would also be value in letting the author define a primary keyword or category, but I think that's less critical than allowing multiple keywords or categories.
Received on Thursday, 28 July 2011 04:44:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 28 July 2011 04:44:59 GMT