[Bug 13564] New: Negotiating shortcut keybindings

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

           Summary: Negotiating shortcut keybindings
           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 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 couldn’t 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.

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

Received on Wednesday, 3 August 2011 03:26:05 UTC