- From: Charles McCathieNevile <charles@w3.org>
- Date: Mon, 30 Sep 2002 19:17:41 -0400 (EDT)
- To: Jonny Axelsson <jax@opera.no>
- cc: <wai-xtech@w3.org>, HTML WG <w3c-html-wg@w3.org>
On Mon, 30 Sep 2002, Jonny Axelsson wrote: >It is access *character*, not access *key*. This is what all W3C specs use, >and the only reasonable alternative when the keyboard vary widely. This is >different from the OMA (nee WAP Forum) interpretation. They on the other >hand use dynamic reallocation of accesskey keys, so what the author >specifies is informative only. CMN Agree that it is a character, but it can only be informative given the wide range of characters and the fact that different systems have a different set available. (If it takes too many steps to reproduce the character then the benefit is mostly lost...) JA: >Accesskey will never work unless there is a mechanism to let it be readily >apparent that a page has accesskeys, and which those are. The suggestion in >HTML 4.01 (underline the critter) will not work in the general case. Agree >A CSS2 capable browser can simulate the iCab implementation using > *[accesskey]:after {content: " <" attr(accesskey) ">";} >(this will fail with dynamic reallocation of the accesskey character). Because of the likelihood that some dynamic remapping will be required the browser needs to take responsibility for informing the user what keys are actually available. Context menus, a link list similar to that used in many browsers for the HTML link element, a marker in the visual display, are all possibilities. JA: >Accesskey should never be allowed to override the keyboard bindings of the >UA, that would lower accessibility and usability. Since it will be >unpredictable for the author which keys the UA reserves and what keyboard >the user has, this implies a separate space for it to be useable. > >Conflicts between accesskey and DOM3 text events may still happen, but in >this case the author will be able to predict the interaction (unless >accesskey remapping or user overrides are in play), so this is less likely >to be of a problem. > > >I would agree with Tantek on the effect of triggering an accesskey. While it >is more efficient to do actions with no confirmation, the risk of triggering >an accesskey accidentally, together with the possibility that the action may >be irreversible (like a POST or even a GET under some circumstances, or some >scriptable control), has convinced me that giving the element focus is the >best and most predictable alternative. > >While there are conflicting opinions on whether keyboard navigation should >trigger events (navigating using a keyboard would normally traverse all >intervening elements on the way to the target, you would not want to trigger >those elements), accesskey should trigger a focus event. It is the keyboard >equivalent to point and click (or rather point and mousedown). CMN For most accesskey users, directly activating links provides the most efficient and helpful implementation of the functionality. I would recommend that the default behaviour is instant activation. I do think it is important to have an option that disables instant activation, for users who need this. The User Agent Accessibility Guidelines talks in brief about the general principles in Guidelines 5 - http://www.w3.org/TR/UAAG10/guidelines.html#gl-user-control-ui From a personal perspective: Instantly activating accesskeys are one of the key functions in one of my everyday browsers (iCab) - much more useful than the ability to tab through links. But fast keyboard control generally is valuable - structure navigation, etc - to reduce the strain on my hands of travelling around the keyboard to use modifiers or sequences, or the mouse. Accesskeys are better than simple structure navigation because well-implemented they provide much faster access to the handful of key elements that will be regularly used. Sites such as http://www.peepo.com try to make extensive use of accesskey functionality (I believe they still replicate the instant activation behaviour by using javascript) and for large or often-used multi-page documents (manuals, big sites, specifications, etc) they are a well-known usability technique much older than the Web. cheers Charles
Received on Monday, 30 September 2002 19:17:42 UTC