W3C home > Mailing lists > Public > wai-xtech@w3.org > February 2008

Re: Reserved keystrokes for browsers and operating system functions

From: Jon Gunderson <jongund@uiuc.edu>
Date: Mon, 11 Feb 2008 10:21:39 -0600 (CST)
To: Charles McCathieNevile <chaals@opera.com>, John Foliot <foliot@wats.ca>
Cc: "'W3C WAI-XTECH'" <wai-xtech@w3.org>
Message-Id: <20080211102139.BBZ74054@expms1.cites.uiuc.edu>

I don't think you can build keyboard accessible widgets using the current accesskey technology.  You are dealing with keyboard events to manipulate widgets, not just moving focus or activating a link.

There is no information in the event object to notify a script that the browser wants a key combination.  

The browser can always win if it never passes the keyboard event to the web application, like IE7 doesn't pass "Control+Tab" or "Shift+Control+Tab" when there are tabs open in IE7.

So the browser can always win if it wants to, but a web application doesn't know what keys a browser may want, except by convention.  

I don't know how you would use accesskeys in a keyboard event handler to define shortcut keys for widgets.  Does anyone know how to do this?

Jon


---- Original message ----
>Date: Sat, 09 Feb 2008 13:48:33 +0530
>From: "Charles McCathieNevile" <chaals@opera.com>  
>Subject: Re: Reserved keystrokes for browsers and operating  system functions  
>To: "John Foliot" <foliot@wats.ca>
>Cc: "'W3C WAI-XTECH'" <wai-xtech@w3.org>
>
>
>On Wed, 19 Dec 2007 02:18:05 +0530, John Foliot <foliot@wats.ca> wrote:
>
>> Jon Gunderson wrote:
>>> Aaron,
>>> Is there a list of key combinations that ARIA (Web 2.0) applications
>>> should never use?
>>>
>>> There are already some conflicts in the best practices, in that case
>>> the best practices says the Widget should win.
>
>I'm not sure that the widget should win, actually. Changing the user  
>interface locally is not exactly kind to the user, because of its  
>unpredictability, poor discoverability, and difficulty to learn.
>
>>> Are these combinations going to be OS and browser specific?
>
>The reason why I suggest using the actual accesskey mechanism in HTML  
>rather than directly trapping key events is that accesskey *can* be  
>implemented not to clash.
>
>My proposal to the HTML WG to improve the specification of accesskey would  
>make it clearer that accesskeys can be remapped by the client, according  
>to what is available. Thus you get (at least) the ability to re-use  
>existing techniques - and while there are known hassles with gobbling  
>accesskeys out of the UI in Internet Explorer, Opera doesn't have the  
>problem already, Firefox is changing.
>
>> Not sure if this helps any, but my list of reserved keystrokes, while now
>> over 5 years old, is still pretty-much up-to-date.  Note that this list  
>> was directly in relationship with Accesskey (ALT+___ in Windows
>> environment), but might serve as a useful start (?).  See:
>> http://www.wats.ca/show.php?contentid=43 (There is some i18n data there  
>> too
>
>John, there are no conflicts between Opera's accesskeys and alt - since  
>you don't use alt to enable accesskeys in teh first place, but a single  
>configurable command (default is shift-esc, but you can set it to anything  
>you like).
>
>> I also have a list of keystroke combinations directly related to JAWS
>> [http://www.wats.ca/show.php?contentid=48], that also features other
>> activator keys (for example "Prior Link" = SHIFT + TAB) if that is of any
>> use.
>
>cheers
>
>Chaals
>
>
>-- 
>Charles McCathieNevile  Opera Software, Standards Group
>     je parle franšais -- hablo espa˝ol -- jeg lŠrer norsk
>http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com
>
Jon Gunderson, Ph.D.
Coordinator Information Technology Accessibility
Disability Resources and Educational Services

Rehabilitation Education Center
Room 86
1207 S. Oak Street
Champaign, Illinois 61821

Voice: (217) 244-5870

WWW: http://www.cita.uiuc.edu/
WWW: https://netfiles.uiuc.edu/jongund/www/
Received on Monday, 11 February 2008 16:22:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:25:18 UTC