HTML5 defines the accessKeyLabel property by which components can retrieve a human-friendly string describing an assigned access key. However, it also needs to provide an interface for retrieving the assigned access key in an automation-friendly format. This would let keyboard emulators provide generic commands that would map to the specific keyboard input bound to a particular element or command. It would also let the list of keybindings be processed in various useful ways, as well as being extremely useful for test automation.

    * Use case: Aaron asks his web browser to display a list of the currently active keyboard shortcuts. In the draft HTML5 specification it would do this by enumerating the command elements and retrieving each one's accessKeyLabel property. The user agent wants to make the list more useful by offering views sorted and organized in different fashions, including a view that includes separate groupings for unmodified keys, Ctrl key combination, Shift key combinations, and Ctrl+Shift key combinations. Unfortunately, it cannot easily parse the accessKeyLabel string, as it knows neither the names the user agent will use for modifier keys (e.g. "Ctrl", "control", an arrow glyph, etc.) nor what method will be use to concatenate them (e.g. "Ctrl+a", "Ctrl/A", "^A", "A+Control", an arrow plus "A", etc., all of which may depend on the platform, user agent, language, and/or locale). If it can obtain the automation-friendly version of each input, as well as its user-friendly equivalent, it can easily provide multiple views of the information organized in various useful fashions.

    * User case: Louis has a browser add-in that lets him specify a keyboard input and it tells him what function or element that is currently mapped to. The user enters a representation of a key or key combination as a text string using a consistent format (e.g. "Ctrl+[") regardless of which platform it's running on. To determine which command this is assigned to, it converts the string into the automation-friendly equivalent defined by the HTML5 spec, and compares that to the representation associated with each command recognized by the browser (per 4.11.5 Commands).

An automation-friendly representation could either be a list of codes representing keys and their modifiers (e.g. an integer representing the F5 key along with a mask of bits representing Alt and Shift modification) or it could be a string compounded from substrings that are language-, locale- and platform-neutral (e.g. "Ctrl+A" for the combination of the "A" key and the equivalent of the control key, even in environments where the latter is not normally written as "Ctrl"). 

Either format could either be returned by an element using a property analogous to accessKeyLabel, or user agents could be required to provide a function to convert the user-friendly string returned by accessKeyLabel into an automation-friendly representation.

Issue: Are there cases where an accessibility aid may be able to interact with with the DOM in order to query keybindings, yet still need to simulate the key combination associated with a control or command rather than activating it programmatically? This would certainly be useful for test automation, but are there accessibility cases?