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

Re: Reserved keystrokes for browsers and operating system functions

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Tue, 19 Feb 2008 05:04:47 -0600
To: "Charles McCathieNevile" <chaals@opera.com>
Cc: "John Foliot" <foliot@wats.ca>, "'W3C WAI-XTECH'" <wai-xtech@w3.org>, wai-xtech-request@w3.org
Message-ID: <OFA5FB6362.6B897E0B-ON862573F4.003BD0DF-862573F4.003CDD07@us.ibm.com>




Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Chair, IBM Accessibility Architecture Review  Board
blog: http://www.ibm.com/developerworks/blogs/page/schwer

wai-xtech-request@w3.org wrote on 02/09/2008 02:18:33 AM:

>
> 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.
>
This only helps if you are doing alt+xxx. If you want to trap the arrow key
to expand/collapse arrows access keys do not cut it. So, I believe author
needs control over the
browser.

I would also prefer that the access element approach be used from the XHTML
2 working
group to replace access key. It also provides a description of the key and
allows
the author to let the browser assign the key and to identify the target
event.

http://www.w3.org/TR/2008/WD-xhtml-access-20080107/

> 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
>
Received on Tuesday, 19 February 2008 11:05:16 UTC

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