Bug 13555 - Fixing keyboard shortcuts and commands
Fixing keyboard shortcuts and commands
Status: CLOSED NEEDSINFO
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec
unspecified
All All
: P2 normal
: ---
Assigned To: Greg Lowney
HTML WG Bugzilla archive list
: a11y, a11y_focus, a11y_ua
Depends on:
Blocks: 13576 13564 13565 13575 13579
  Show dependency treegraph
 
Reported: 2011-08-03 01:52 UTC by Greg Lowney
Modified: 2014-02-26 18:48 UTC (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Greg Lowney 2011-08-03 01:52:29 UTC
There is widespread agreement that keyboard commands in HTML have been fundamentally broken for a long time and need to be fixed. This has many aspects which will be discussed in subsidiary bugs. Examples include but are not limited to expanding the range of available keybindings, allowing components and the user to negotiate keybindings, allow retrieving keybindings in automation-friendly format, and acknowledging that the user may need to separate navigation from activation.

Some key concepts are:

1. Keyboard access and commands are a fundamental accessibility issue because: (a) users with disabilities are much more likely to rely on the keyboard or keyboard emulators, and keyboard conflicts can present them with insurmountable barriers while being merely inconveniences for users who routinely use a mouse; (b) users who cannot use a mouse often need to drastically increase the number of shortcut keys in order to make tasks more efficient, especially people for whom each keypress is time-consuming, tiring, or painful; (c) increased number of shortcuts increase the number of potential conflicts; (d) users with some cognitive impairments have more difficulty adjusting when their accustomed methods suddenly fail to work, or when commands they use suddenly do something unexpected; (e) many users find it difficult to memorize arcane key combination and sequences, and the problem is magnified for users who rely on keyboard commands, and may use or define large numbers of them, and are unable to use mouse methods as a fallback; (f) badly written content can totally break keyboard access, either accidentally or intentionally.

2. HTML introduces complexities for document authors and web application developers beyond those for proprietary formats and native applications: (a) many layers can define their own keyboard commands, including the primary document or web app, scripts it loads, the primary user agent, embedded user agents, user agent add-ins, and the platform on which the user agent is running, and these run the risk of conflicting with each other; (b) documents and web applications generally want to work with any host and platform, and a wide range of user preference settings; (c) HTML needs to support assistive technology in the form of user agent features as well as user agent add-ins and external components that interact with the user agent; (d) HTML can restrict the UI and interoperability of web-based content in ways that native applications are not restricted.

3. Keyboard UI needs to be both universal (for every task and every user) and usable (easy, efficient, reliable/predictable, and easily learned and remembered). Keyboard UI needs to: (a) let the user do everything from the keyboard; (b) let the user agent give the user flexibility and control over the keyboard UI; (c) let the user work with multiple layers at the same time without those interfering with each other; (d) let things adapt to keyboard restrictions, conventions, and conflicts; (e) let users discover and be reminded of keyboard UI.

4. Keyboard commands include access keys (e.g. S or Alt+S to activate the content's Send button, or Alt+F to activate the browser's File menu) where the user agent is generally trying to emulate behavior of the platform, hotkeys (e.g. Ctrl+S to trigger the "save" action, Ctrl+Shift+S to trigger the "save as" action, or Command+C to trigger the "copy" action), as well as basic keyboard commands (e.g. tab key, arrow keys, character keys to insert text or select an item starting with character, etc.). Keyboard techniques include navigating, selecting, and triggering actions, and can be sequential, direct, structural, spatial, or textual.

These and other concepts are discussed at http://www.w3.org/WAI/UA/work/wiki/Keyboard_Concepts_for_HTML5_Discussion.
Comment 1 Michael[tm] Smith 2011-08-04 05:05:39 UTC
mass-moved component to LC1
Comment 2 Ian 'Hixie' Hickson 2011-08-12 19:54:54 UTC
Is this intended to be an actionable bug or is it just a tracking bug for the other more specific ones? (A tracking bug is fine, I'm just trying to work out what I should be doing here.)
Comment 3 Michael[tm] Smith 2011-11-20 15:25:12 UTC
Greg, this bug is waiting on your response to comment #2:
> Is this intended to be an actionable bug or is it just a tracking bug for the
> other more specific ones? (A tracking bug is fine, I'm just trying to work out
> what I should be doing here.)
Comment 4 Ian 'Hixie' Hickson 2011-11-24 02:46:55 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: see comment 2