W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2008

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

From: Jon Gunderson <jongund@uiuc.edu>
Date: Thu, 24 Apr 2008 08:42:53 -0500 (CDT)
To: Al Gilman <Alfred.S.Gilman@IEEE.org>, "Gregory J. Rosmaita" <oedipus@hicom.net>
Cc: public-xhtml2@w3.org, w3c-wai-ua@w3.org, wai-xtech@w3.org
Message-Id: <20080424084253.BEZ00153@expms1.cites.uiuc.edu>

I think at least Al's suggestion of the suggested SMIL text be  added.  I think it would also be good to add content related to allowing users to control accesskey behavior (i.e. disable, only move focus) would be important features.


---- Original message ----
>Date: Thu, 24 Apr 2008 07:34:26 -0400
>From: Al Gilman <Alfred.S.Gilman@IEEE.org>  
>Subject: Re: [XHTML Access] redefining keys and ensuring user control over "activate" (yes tighten)  
>To: "Gregory J. Rosmaita" <oedipus@hicom.net>
>Cc: public-xhtml2@w3.org, w3c-wai-ua@w3.org, wai-xtech@w3.org
>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  
>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.
>> 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
>> -----------------------------------------------------------------
Jon Gunderson, Ph.D.
Coordinator Information Technology Accessibility
Disability Resources and Educational Services

Rehabilitation Education Center
Room 86
1207 S. Oak Street
Champaign, Illinois 61821

Voice: (217) 244-5870

WWW: http://www.cita.uiuc.edu/
WWW: https://netfiles.uiuc.edu/jongund/www/
Received on Thursday, 24 April 2008 13:43:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:38 UTC