Re: Accesskey Discussion

  By coincidence this topic was discussed on the UAAG conference call that just ended.  A few ideas brought up for further discussion include:

User needs to be able to to assign priorities of various keyboard shortcuts, e.g. when user, user agent, and content all try to assign the same key to different functions. Browsers need to mediate, but the user needs final say.

When there is a conflict between keyboard commands defined by content, user, and user agent, all of the commands still *need to be available* even if the user's preferences end with some being overridden. For example, if two things want to be Ctrl+S, one would be changed to another modifier, or a menu provides access to the various commands without using their keyboard shortcuts.

As documentation often refers to the keyboard commands originally specified by the content author or UA developer, the user may want to be able to determine the actual keyboard commands used on their system as it's currently configured (e.g. overridden keys, or change of modifier imposed by the user agent). For example, if a help topic tells them to press Command+S but they're running on a system without a Command key, they can determine that their browser changed it to Ctrl+S. Or if a Web page assigns Alt+F as a shortcut key to a form field, but the user remaps it to Ctrl+Shift+F to avoid conflicting with the keyboard command for their browser's File menu (or their assistive technology), they can look up to see what Alt+F was remapped to.

Ideally the user agent should also be able to provide the user with information as to what a keyboard command does, or at least which component (e.g. which html document, script, style sheet, plug-in, etc.) is handling it. For example, if they press a key combination expecting one behavior and something mysterious happens instead, they can examine a list of active keyboard commands to find that the current Web page has assigned that key combination to activate a particular form control, or that a particular plug-in is consuming it, etc.

-------- Original Message  --------
Subject: Re: Accesskey Discussion
From: Egan, Bim <Bim.Egan@rnib.org.uk>
To: simon.harper@manchester.ac.uk, UAWG list <w3c-wai-ua@w3.org>
Date: 9/23/2010 10:04 AM
> Sorry to butt in here, but it concerns me that as accesskey bindings
> frequently conflict with keyboard access to browser  toolbars or
> plug-ins, and can also change settings in access technology that runs in
> the background while being sensitive to all keystrokes, such as screen
> readers, defined accesskeys could result in all HTML5 pages using them
> being inaccessible to people  who navigate via keyboard or use access
> tech software, instead of the current situation where it is difficult
> only on some sites using code that conforms to specification.
>
> Bim
>
> -----Original Message-----
> From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org] On
> Behalf Of Simon Harper
> Sent: 23 September 2010 18:44
> To: UAWG list
> Subject: Accesskey Discussion
>
> I seems to me that HTML5 is becoming increasingly platform like. In this
> case I suggest that HTML5 specify a number of predefined accesskeys for
> common functionality including those useful for WebApps.
>
> Cheers
> Si.
>
> =======================
>
> Simon Harper
> University of Manchester (UK)
>
> More: http://simon.harper.name/about/card/
>
>
>
>   To report this e-mail as Spam, please forward it to:
> spam@mailcontrol.com
>
>