[Bug 13575] Retrieving keybindings in automation-friendly format

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

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |ian@hixie.ch
         Resolution|                            |WONTFIX

--- Comment #2 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-08-12 22:03:08 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: Rejected
Change Description: no spec change
Rationale:

> Aaron asks his web browser to display a list of the currently
> active keyboard shortcuts. [...] 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 [...] 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).

The user agent does know what names the user agent will use. It's itself.


> 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.

This seems entirely possible. It's a UA implementation issue.


> 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?

ATs should just communicate to the UAs directly, not via the JS APIs. That
makes no sense.

-- 
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 Friday, 12 August 2011 22:03:14 UTC