Re: [XHTML Access] redefining keys and ensuring user control over "activate" (yes tighten)

On 14 Apr 2008, at 1:04 PM, Gregory J. Rosmaita wrote:

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

Consider strengthening this to use the language that failed to make
it into SMIL2 only by editorial oversight:

The user agent must provide a means of identifying the [shortcuts]
that can be used in a [page].  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 [access key]  
requested by the
author might not be made available by the player (for example it may not
exist on the device used, or it may be used by the player itself).
Therefore the user agent should make the specified [action]  
available, but may
map the [shortcut] to a different [user] interaction behavior.

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

per W3C style, 'must' in a spec should be RFC 2119 MUST.

a suitable disposition of this would be to clarify that that is the
case here.

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

Defining that cascade in a way that people will actually follow is
a bigger job than this module alone should try to solve.

The Ubiquitous Web Applications activity is in the process of
reviewing its workplans with an eye to engineering the architecture
for personalization on the Web.  That is where the cascade should
come from, rather than a half-baked answer be put in here that
the browsers don't listen to.

This module does its part for 'author proposes, user disposes' by
putting the focus/fire choice under the control of an attribute
in the DOM where onLoad processing can adjust it prior to the
access element handling any user events.

Al
>
> 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 Thursday, 24 April 2008 11:35:11 UTC