HTML5 makes major progress in allowing content to register keyboard commands with the user agent. However, there needs to be a mechanism for components (user agents, documents, web apps, embedded objects, accessibility aids, etc.) to negotiate which keyboard inputs (keys, key combination, and/or key sequences) are bound to their functions. will be used by one or the other, and to allow bindings to adjust to avoid conflicting with other components and restrictions imposed by the host, platform, or user settings. This entails:

    * Letting components negotiate keybindings, determining and adapting to the set of possible keyboard inputs and which are impossible (e.g. not on the user's keyboard), reserved by the platform (inputs reserved by the host or operating system so they cannot be changed by the component, e.g. Alt+Tab), restricted by convention (e.g. standard keybindings for copy, paste, exit, etc. that should not be changed lightly), in use (e.g. already assigned to a command created by a browser add-in, or by an accessibility aid that has registered its usage with the browser), or prohibited by the user's settings (e.g. user preference setting disallowing unmodified keys as commands, or explicitly mapping the a particular key to a particular function).

    * Letting components conform to the host's keyboard conventions, such as allowing a custom control (e.g. a drop-down list box implemented entirely in Javascript) to set its keyboard commands to match those its host browser provides for its equivalent controls, or allowing a form in HTML to emulate the navigation and access key behavior of native dialog boxes. 

    * Letting components adjust to actual, resolved keyboard shortcuts, such as incorporating them into their instructions. (This will be a separate bug report.)

This an important accessibility issue because: (a) Users with disabilities are much more likely to rely on keyboard access. For them, keyboard conflicts might present insurmountable barriers, while they'd only be minor inconveniences for users routinely using the 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. Increased number of shortcuts increase the number of potential conflicts; (c) 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. 

Here are some specific example:

Negotiation between host and content

    * Use case: Pablo is used to pressing Ctrl+F to find a string on the current page. However, an online encyclopedia grabs Ctrl+F and moves the focus to its own text input fields that's used to search the entire encyclopedia.

    * Recommendation: The script on the page should be able to query whether Ctrl+F is already assigned to something in the system (the host browser, a browser add-in, etc.), and if it is it can identify a new, unused keyboard input, map that to its control, and incorporate that into the instructions it presents to the user.

    * HTML5 Status: HTML5 allows the content to provide a list of suggested Unicode characters, but the user agent gets to decide on the actual key assignment, including base character and modifier keys. The content script can retrieve a user-friendly string representing the assignment. (That's enough for this use case but is too limited for some of the others.) 

Negotiation between host and embedded object

    * Use case: An embedded object uses Shift+Esc for one of its control functions, but it's run on a browser that uses this same key combination as the method for returning focus to the browser. In the simple cases, either the user wouldn't be able to exit the object using the method they're familiar with, or else they couldnt use some function in the object because the keystroke would exit the object instead.

    * Recommendation: It is important that the user have a consistent way to exit all embedded objects, because without this they can become effectively trapped; even if there is a way out, the user may not know it or be able to look it up when needed. The embedded object needs to be able to determine that on this particular browser it cannot use the key combination(s) that the user agent has reserved for this purpose and adjust its command set, user interface and instructions accordingly. If the user does exit the embedded object using the host's command, the host should inform the embedded object so that it can "clean up" and handle the action gracefully.

Negotiation with nested hosts

    * Use case: Pablo is used to pressing Ctrl+W to close a browser window. In his browser he's reading a page that contains an embedded user agent, and while browsing in THAT context he presses Ctrl+W to close the window. Unfortunately, the script being run by the inner user agent did not know that Ctrl+W was used by the outer user agent, and because it grabs and consumes the keyboard input and carries out some action, Pablo is unable to use his accustomed method to close the outer browser's window.

    * Recommendation: There should be some way for embedded objects, including nested user agents, to determine which shortcut keys are being used all the layers hosting it, so it can modify its own shortcut keys to avoid conflicting with them.