- From: Jim Allan <jimallan@tsbvi.edu>
- Date: Thu, 1 May 2008 12:28:44 -0500
- To: "WAI-ua" <w3c-wai-ua@w3.org>
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