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.