XHTML Access Module and UAAG 1.0 and UAAG 2.0

On last week's call [1] UAWG had a good discussion of the XHTML Access
Module [4] and it's accessibility implications and relation to UAAG10 [2]
and UAAG20 [3]. I took a task to write a summary of the discussion an map
relevant items in the module to Checkpoints in UAAG10 and UAAG20

The Access Module focuses on the ACCESS element in XHTML.
"The access element assigns an accessibility mapping to elements within a
document. Actuating the mapping results in the element gaining focus or,
optionally, in some other event being delivered." [4]

ACCESS has attributes of @activate, @key, @targetid, and @targetrole. This
message will only focus on @activate and @key.

>From Access Module:
3.1.1. activate = ( yes | no* )

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
may provide mechanisms for overriding the setting of the activate attribute.
In such user agents, user-specified settings must take precedence.
=========

UAAG (10 and 20) provide checkpoints for overriding the author setting for
'activating' events on focus, see below.
 
There was discussion that a mouse user explicitly knows what is being
activated - that is, they must place the mouse on the element to be
activated and THEN explicitly click a button. A mouse user can infer from
contextual information/content near the element what the activation of the
element may do. If @activate is set to 'yes' a user using the 'access'
keybinding has limited contextual information other than the @title of the
'access' element to infer the function, because upon focusing on the element
it is immediately fired. If @activate is set to 'no' then the focus is moved
to the appropriate element and the user is free to explore context if there
is any doubt as to actual function.  

There is an additional issue. The keyboard user does not know the value of
@activate when hitting the appropriate 'key' of an ACCESS element. I suppose
setting the user agent to never fire events would cover this...if there is a
conformant UA.  


The examples given in the Access Module provide little help when thinking
about @activate.

In example 1. Access element that focuses into a field - the field is not
actionable. 
In Examples 2,3,4,5. Accessing a table of contents, Access that moves to the
main content, Access element that goes to a specific element, Access element
with no specific key mapping - if a link, it could activate, if an inpage
anchor, it just moves to the appropriate location.

There are no given examples for @activate.

Relevant UAAG checkpoint pertaining to @activate (UAAG10 or UAAG20 precede
the checkpoint number to indicate version)

UAAG10-1.2 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.(P1)

UAAG10-9.5 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. (P2)

UAAG10-9.6 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.(P2)

UAAG20-3.12.11 On Focus:  The user has the option of ensuring that moving
the content focus to or from an enabled element does not cause the user
agent to take any further action.(Level A) 
***Note: 3.12.11 implies that the user directly moves focus to an element.
Activating an accesskey has the same effect as using the tab-key to move
focus to an element, in that accesskey moves the focus from its current
location directly to the element with the accesskey attribute.

UAAG20-4.2.2 Show All: For the element with content focus, the list of input
device event types for which there are event handlers explicitly associated
with the element are provided. (Level A)
***Note: having a list of event handlers is of dubious utility. In order for
a user to benefit from the list of event handlers she must know or be
informed of what action will occur upon activation. The user agent should
know about events that can occur. How does the user agent get the
information about what an event handler will do to share with the user? 

UAAG20-4.2.3 Activate All:  The user can activate, as a group, all event
handlers of the same input device event type, for the same control.(Level A)
======
>From Access Module
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. Note: Authors should
consider the input method of the expected reader when specifying an
accesskey.

UAAG Relevant Checkpoints:
UAAG10-11.2 Provide a centralized view of the current author-specified input
configuration.(P2)

UAAG10-11.3 Allow the user to override any binding that is part of the user
agent default input configuration.
	1. The user agent is not required to allow the user to override
conventional bindings for the operating environment (e.g., for access to
help).
	2. The override requirement only applies to bindings for the same
input modality (e.g., the user must be able to override a keyboard binding
with another keyboard binding). (P2)
***Note: this checkpoint does not apply to content!

UAAG10-11.4 Allow the user to override any binding in the user agent default
keyboard configuration with a binding to either a key plus modifier keys or
to a single key.
	1. In this checkpoint, "key" refers to a physical key of the
keyboard (rather than, say, a character of the document character set).
***Note: this checkpoint does not apply to content!

UAAG20-4.1.10 User Override any Binding: The user can 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 include single key
and key plus modifier keys if these are available in the operating
environment. (Level AA)
***Note: 4.1.10 does not explicit say 'author supplied' binding. It says
'any binding that is part of the user agent default input configuration".
Are author supplied bindings (accesskey) part of the user agent default? It
is further ambuiguated (is that a word) because the definition of 'input
configuration is -"An input configuration is the set of "bindings" between
user agent functionalities and user interface input mechanisms (e.g., menus,
buttons, keyboard keys, and voice commands). The default input configuration
is the set of bindings the user finds after installation of the software.
Input configurations may be affected by author-specified bindings (e.g.,
through the accesskey attribute of HTML 4 [HTML4])."
<cite="http://www.w3.org/TR/UAAG20/#def-input-configuration"> 
This should be explicit. 
Propose:
<new 4.1.10>
User Override any Binding: The user can 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) or author-specified
bindings. The keyboard combinations offered for rebinding include single key
and key plus modifier keys if these are available in the operating
environment. (Level AA)
</new>

UAAG20 is missing "in the event that no keybinding is provided by the
author, or the keybinding is not in existence on the device, the user agent
should supply a keybinding that is not in conflict with current bindings and
that is available on the device". Perhaps it should be incorporated into
4.1.10. 

References
1. http://www.w3.org/2008/04/24-ua-minutes.html
2. UAAG10 www.w3.org/tr/uaag10
3. UAAG20 www.w3.org/tr/uaag20
4. XHTML Access Module
http://www.w3.org/MarkUp/2008/WD-xhtml-access-20080418/ 

-----Original Message-----
From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org] On Behalf
Of Al Gilman
Sent: Thursday, April 24, 2008 6:34 AM
To: Gregory J. Rosmaita
Cc: public-xhtml2@w3.org; w3c-wai-ua@w3.org; wai-xtech@w3.org
Subject: 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 precedence. 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, 1 May 2008 17:31:56 UTC