[XHTML Access] redefining keys and ensuring user control over "activate"

aloha!

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 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:

<quote 
cite="http://www.w3.org/MarkUp/2008/WD-xhtml-access-20080418/#sec_3.1.2.">

An access key is a single character from the document character set.

</quote>

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, the same section, 3.1.2., also states:

<quote 
cite="http://www.w3.org/MarkUp/2008/WD-xhtml-access-20080418/#sec_3.1.2.">

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. If no 
key attribute is specified, the user agent SHOULD assign a key
.

</quote>

this sounds as if a bit of coordination between the User Agent 
Accessibility Guidelines (UAAG) working group and the XHTML2 working 
group is needed -- UAAG 2.0, which is still in development -- has 
far more robust verbiage on keyboard support than before, but it is 
still in the drafting process -- i would feel much more comfortable,
as a member of both working groups, if the language used in the Access
Module were less vague than that which originally defined accesskey 
in HTML4x/XHTML1.0 

while i realize that there is a reason for the Access Module's ambiguity
on this point, it needs to -- at least -- point to UAAG (or reuse some 
UAAG verbiage) in order to provide -- at least -- a "best practice" for
provideing mechanisms for overriding, disabling, or re-assigning keys, 
especially since the section ends with:

<quote 
cite="http://www.w3.org/MarkUp/2008/WD-xhtml-access-20080418/#sec_3.1.2.">

In such user agents, user-specified assignments must take precendence. If 
no key attribute is specified, the user agent SHOULD assign a key.

</quote>

whilst i laud the fact that "user-specified assignments must take 
precedence", without a cascade mechanism (or at least definition, as in
"author proposes, user disposes") i am concerned that such language is
too loose, unless the "must" in that sentence is an RC2119 "MUST" (which,
as far as i can tell, it is currently not)

i am also 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...

References:
 * http://www.w3.org/WAI/UA
 * http://www.w3.org/TR/uaag20/
 * http://www.w3.org/TR/uaag10/

gregory.
-----------------------------------------------------------------
ABSURDITY, n.  A statement or belief manifestly inconsistent with
one's own opinion.      -- Ambrose Bierce, The Devils' Dictionary
-----------------------------------------------------------------
Gregory J. Rosmaita, oedipus@hicom.net AND unagi69@concentric.net
         Camera Obscura: http://www.hicom.net/~oedipus/index.html
UBATS: United Blind Advocates for Talking Signs: http://ubats.org
-----------------------------------------------------------------

Received on Monday, 14 April 2008 17:05:20 UTC