- 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