Key Mapping & Binding Drafts
Re-Wording As a Result of the 8 May 2008 User Agent teleconference
3.1.2. key = Character
This attribute assigns a key mapping to an access shortcut. An access key is a single character from the document character set. (editor's note: the following sentence should either be moved or deleted entirely) <DEL>Note: Authors should consider the input method of the expected reader when specifying an accesskey.</DEL>
Triggering an access key defined in an access element changes focus to the next element in navigation order from the current focus that has one of the the referenced role or id values. Note that it is possible to deliver alternate events via XMLEVENTS. It is also possible to have the target element activated through the use of the activate attribute. Finally, it is possible to associate additional event handlers with target which might then perform additional actions once focus is changed. <INS>If an element accepts multiple events that dispatch different actions, the user agent MUST provide a way for the user to discover the all events, which events are available, and how they are triggered.</INS>
An access element <INS>MUST</INS> have either a targetrole or a targetid attribute specified. If neither a targetrole nor a targetid attribute are specified, the user agent MUST NOT define a mapping nor deliver any events.
The invocation of access keys depends on the implementation. For instance, on some systems one may have to press the "alt" key in addition to the access key. On other systems, one generally has to press the "cmd" key in addition to the access key. A conforming user agent MUST allow the user to override any author-defined binding.
The rendering of access keys depends on the user agent. We recommend that authors include the access key in label text or wherever the access key is to apply. <DEL>User agents should render the value of an access key in such a way as to emphasize its role and to distinguish it from other characters (e.g., by underlining it).</DEL>
The character assigned to a key, and its relationship to a role or id attribute, are a suggestion of the author. User agents may provide mechanisms for overriding, disabling, or re-assigning keys. In such user agents, user-specified assignments MUST take precedence. <INS>A conforming user agent MUST allow the user to override any binding that is part of the user agent default input configuration except for conventional bindings for the operating environment (e.g., for access to help). The keyboard combinations offered for rebinding SHOULD include single key and key plus modifier keys if these are available in the operating environment, as specified in UAAG 1.0, Checkpoint 11.3</INS>
If no key attribute is specified, the user agent MUST assign a key. <INS>When a user agent assigns key values to access elements that have no key defined for them, the user agent MUST provide the user with multi-modal notification that keys have been defined for the following values: x, y, z, etc. and that there are no specific keys defined for "foo" and "bar", so "foo" and "bar" have been assigned keys 1 and 2.</INS>
<INS>A conforming user agent MUST also provide a centralized view of the current author-specified input configuration. (UAAG 1.0, Checkpoint 11.2)</INS>
The activate attribute indicates whether a target element should be activated or not once it obtains focus. The default value for this attribute is "no", indicating that the element will not be "activated". User agents <INS>must provide a means of identifying the shortcuts that can be used in a document. This may be accomplished in different ways by different implementations, for example through direct interaction with the application or via the user's guide. The key defined by the author might not be made available by the user agent (for example, it may not exist on the device used, or it may be used by the user agent itself).</INS>
<INS>A keyboard user will not know the value of activate when invoking the appropriate 'key' defined for an ACCESS element. A conformant user agent MUST, therefore, allow the user to exercise control over the user interface in accordance with the requirements set forth by the User Agent Accessibility Guidelines, 1.0 [UAAG10]:
Allow the user to activate, through keyboard input alone, all input device event handlers that are explicitly associated with the element designated by the content focus. (UAAG 1.0, Checkpoint 1.2)
Allow configuration so that moving the content focus to or from an enabled element does not automatically activate any explicitly associated event handlers of any event type. (UAAG 1.0, Checkpoint 9.5)
For the element with content focus, make available the list of input device event types for which there are event handlers explicitly associated with the element. (UAAG 1.0, Checkpoint 9.6)</INS>
<INS>Therefore, the user agent MUST make the specified action(s) available, but may map the shortcut to a different user interaction behavior. Note that timely notification of any remapping or reassigning of an author-defined "key" MUST be issued to the user through the user agent's native interface, so that the user is aware of the reconfiguration. A user agent SHOULD provide a broad option of alert mechanisms, all of which must be issued in conformance with user-defined settings for alert mechanisms (for example, if an audio file is played to signify remapping or reassignment, it must be fired in such a way that the operating system's "Show Sounds" or "Sound Sentry" or equivalent mechanism can be used to alert a user whose device is incapable of rendering the aural cue or for whom the processing of an audio clip is either impractical or impossible).</INS>
Do We Need To Address the Following Issue?
<INS>The author knows which action she thinks her users will want automated. The user, however may know which of the alternate actions he would prefer. Only the user knows if he wants to allow the events to fire as defined by the author, or whether he needs to inspect the object to determine which events to fire. Although the author can define multiple actions for a multi-action object, only one action per object will be displayed on the "accelerate" menu. This is the dominant action of the object that is termed its activate action. If an element has a recognized role, and the repertory of actions assigned to the element via access reflect that role, the role itself will be reflected in a change to the visible appearance of the object, as well as providing the necessary contextual and orientational information needed by a user. New and uncommon actions should always have context help describing those actions, written by the author. With declarative handlers more help and assistance can be generated, but since this will not always be the case, authors writing the scripted behaviors SHOULD write the hypertext help as well. Context help generated by the user agent -- and/or an assistive technology based on inspecting the DOM. While the event flow described in DOM3 provides the ability to query what events an object is sensitive to, a user needs help perceiving that an inspection of an object, to ask "what can I do?" The user can then arrange any client-side software to automatically query the context help. Providing an author's tooltip onFocus alone, is not sufficient. (Note: This restriction only holds until XML Events [XMLEVENTS] becomes available.)</INS>
<INS>The ability to query an element or object for which access has been defined, MUST be available to the user whether the user invoked the key defined for the object, or if the user moved focused to the object through tab navigation.</INS>
<INS>A user may need to selectively accept some hotkeys defined by the author as a fire-or-focus event, but may also need to inspect the destination object of some hotkeys in order to exert control over the firing of events, as well as ascertain the expected result when each event is fired.</INS>
<INS>The onLoad processor that edits the activate attribute on access elements may have more subtle policies driven by selectors for trusted actions (where the hotkey will activate), while suppressing the activation of those not on the "whitelist". Or the user can install a handler that responds to a variant user input gesture based on the same mnemonic, but which only navigates to the destination element per the access element, as if activate were negative.</INS>
Important Considerations to Be Discussed by UAWG (13 May 2008)
The previous re-wording for Access Module section 3.1.2. has been moved to:
http://www.w3.org/WAI/UA/wiki/KeyMappingBinding/Talk
In doing so, GJR noted the following:
GJR1: Restoration of Original Text
Original Text: If neither a targetrole nor a targetid attribute are specified, the user agent MUST NOT define a mapping nor deliver any events.
An access element must have either a targetrole or a targetid attribute specified.
GJR Comment 1: This text really SHOULD be retained as it is a normative section of the Access Module --GJR proposes re-adding it.
<INS> An access element must have either a targetrole or a targetid attribute specified. If neither a targetrole nor a targetid attribute are specified, the user agent MUST NOT define a mapping nor deliver any events. </INS>
GJR2: Original MUST NOT changed to a MUST
In the original text of 3.1.2, it is stated:
- An access element must have either a targetrole or a targetid attribute specified, the user agent MUST NOT define a mapping nor deliver any events
Whereas our rewording reads:
- If no key attribute is specified, the user agent MUST assign a key and alert the author to the key mapping and the resultant user agent assigned key SHOULD/MUST persist across sessions.
NOTE: the NOT was dropped during the latest round of posts pertaining to the access module, as it was still a MUST NOT at the end of last week's teleconference; if we are changing a MUST NOT to a MUST we should cite a normative UAAG 1.0 citation.
GJR3: Dropped Dependencies/Citations
The following normative references which originally appeared in the re-write are no longer cited:
Stuff Potentially to be Deleted
removed: in the user agent default keyboard configuration with a binding to either a modifier key(s) a key plus or to a single key. (UAAG 1.0, Checkpoint 11.4)
Further Considerations and Feedback
Is this a more appropriate place to address Gez Lemon's concern about the persistence of user-defined settings when a user overrides the author's proposed key?
- The only reason I mention it is because of how most browsers have implemented alternate style sheets, which change back to the author's preferred style sheet if the user navigates to another page or refreshes the current page. It would be irritating to have to redefine keys on every single page.
Note: Thanks to Jim Allan, Judy Brewer, Alan Cantor, Kelly Ford, Al Gilman, Gez Lemon, Jan Richards, and Jeanne Spellman for their direct input on this issue. Thanks, as well, to the entire User Agent Accessibility Guidelines Group for their attention to detail and invaluable contributions.
return to the current proposal for Access Module Section 1.3.2