XHTML Access Module
Contents
References
For UAWG Review: Access Element | Activate Attribute | Key Mapping/Binding
Problem Statements
PS1. Must "activate" be boolean?
The XHTML Access Module defines the values for the "activate" attribute of the ACCESS element as boolean: yes or no. The default, if no activate value has been defined by the author, is no). However, it is possible to assign more than one event to a single ACCESS element; how, then, can one "inspect" the object or element for which more than one event has been defined, without inadvertently causing any event whose value is set to yes to fire?
PS1 References
original inquiry: "Must "activate" be boolean? (post to w3c-wai-ua, 24 April 2008)
PS2. Redefining Keys and Ensuring User Control Over "activate"
Is the ability of the user to redefine and exert control over pre-set activate values assumed to be the task of the user agent, or should there be a specific mechanism defined in the Access Module, itself, that provides for a cascade of commands?
If a user, for example, of a phone interface only has numeric numbers available to him/her, how are individual alphabetic characters to be accessed? what if the author-defined character used as the "key" isn't capable of being generated by the user's available "keyboard"? even though an "access key" is defined as: An access key is a single character from the document character set, what if that particular character set is not available, that particular character is only available through an obscure key-code sequence, or if the user's UA is using an approximation of (or substitution for) the character set defined for the document?
Granted, in the same section, 3.1.2., also states:
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 precendence [sic]. If no key attribute is specified, the user agent SHOULD assign a key.
Therefore, the language used in the Access Module needs to be less vague than that which originally defined accesskey in HTML4x/XHTML1.0.
The Access Module needs to -- at the very least -- point to UAAG (or reuse some UAAG verbiage) in order to provide -- at least -- a "best practice" for providing mechanisms for overriding, disabling, or re-assigning keys, especially since the section ends with:
In such user agents, user-specified assignments must take precendence [sic]. If no key attribute is specified, the user agent SHOULD assign a key.
While the phrase "user-specified assignments must take precedence", appears in the Access Module, it does so without a cascade mechanism, or at least the definition of one in the "author proposes, user disposes" vein. The extant language is too loose, unless the "must" in that sentence is an RC2119 MUST (that is, a normative must, rather than an informative must).
We must be wary of specifying normatively that, in the absence of a defined "key", "the user agent SHOULD assign a key." -- again, more guidance would be of utmost utility to users, as they would then have fore-knowledge of how their user agent assigns key values to access elements that have no "key" defined -- after, of course, providing the user with multi-modal notification that there are keys 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.
PS2 References
Continue UAWG Review: Access Element | Activate Attribute | Key Mapping/Binding