[Bug 13575] New: Retrieving keybindings in automation-friendly format

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13575

           Summary: Retrieving keybindings in automation-friendly format
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: a11y, a11ytf
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: gcl-0039@access-research.org
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org, public-html-a11y@w3.org
        Depends on: 13555


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?

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Wednesday, 3 August 2011 04:42:39 UTC