RE: proposed pf access command requirements revisions in light of UAWG review

aloha, léonie!

first of all, thanks for all of your help with this, past, present
and future (wink)

when you asked, quote:
>  Should we suggest an order of precedence here perhaps? Would 
> the default behaviour of the UA take precedence over the author 
> defined behaviour for example?
unquote

were you referring to the "alt" problem endemic to past accesskey 
implementations, where on some systems with a certain browser 
that assigned "alt" to acceskeys without giving the user the 
opportunity to change that modifier, certain accesskeys were 
made inoperable due to their being indentical to hotkeys in 
the UA's chrome? -- hasn't this been resolved in subsequent 
releases, where ALT plus f triggers the accesskey in a document, 
but if one wants or needs to get the to "File" menu item, one can 
depress the alt key, pause a moment, and then type an "f" to 
open the "File" menu item?  

i'm open to suggested wording on precedence, but i think that
since an author can't predict nor control with what software 
her web content will be exposed to the end user, and since that 
same author went through the trouble to assign mnemonicly 
meaningful accesskeys which happen to include the hotkeys assigned 
to the UA's chrome, the author shouldn't be punished by having
her accesskeys eaten by the UA's chrome's hotkeys, but should -- 
of course -- retain the ability to invoke the hotkeys using the
alt plus pause plus character and hopefully, in the next release
of the certain browser referred to above, users will be able to 
set their own modifier keys for accesskey invocation AND be 
able to set whether accesskey moves focus or activates (and i'd
recommend that any UA also support ModifierKey1 plus accesskey 
to move focus and ModifierKey2 plus accesskey to activate...

so, it's both an authoring issue and a user agent issue: if 
authors are free to use the entire palette offered by the 
document's declared character set, while user agents should 
allow users to choose a different modifier key than that set
by default by the developer -- in the cascade, i think the
bang important goes to the end user, the author, and then the
user agent (it just struck me that the cascade is in decreasing 
order of sentience when it comes to what is actually most useful
to the end user -- at least, that's my 2 cents (american) on 
the matter -- what do you think?  what wording would you suggest?

i'm sorry i didn't get to this earlier, but i had a very unique
opportunity to get some extraordinarily expert help getting my 
linux box back up and some longstanding network problems 
resolved today, and only now have had time to get to today's 
email, and since we are pressed by time, i want you to know that 
since PF meets tomorrow, i'm going to send the amended access 
command requirements to the PF list so that they can be discussed 
and voted upon tomorrow at the telecon as a prelude to logging them 
as "access command requirements for accessibility" in the HTML5 bug 
tracker...  remember, and you or i (or anyone else, for that matter, 
who has a w3c public bugzilla account and a comment or suggestion) 
could add a comment to the bug report 

i hope that's ok -- i really appreciate your contributions and 
those of everyone who has commented on the requirements and the 
deeper background issues, gregory.

---------- Original Message -----------
From: Léonie Watson <lwatson@nomensa.com>
To: "Gregory J. Rosmaita" <oedipus@hicom.net>, "w3c-wai-ua@w3.org"
<w3c-wai-ua@w3.org>, Janina Sajka <janina@rednote.net>
Cc: "jeanne@w3.org" <jeanne@w3.org>
Sent: Tue, 28 Sep 2010 10:23:26 +0100
Subject: RE: proposed pf access command requirements revisions in light of
UAWG review

> "Requirement 3: Access commands should default to focus 
> behaviour; users must be able to:
>       (a) specify whether the default behaviour focuses or 
> activates           the target;
>       (b) choose whether to move focus to the element for which 
> the           access command has been defined, or to activate 
> the           element for which the access command has been 
> defined; and 
>       (c) override any author specified or default behaviour."
> 
> 
> Regards,
> Léonie.
> 
> --
> Nomensa - humanising technology
> 
> Léonie Watson            |  Director of Accessibility
> t. +44 (0)117 929 7333
> 
> -----Original Message-----
> From: Gregory J. Rosmaita [mailto:oedipus@hicom.net] 
> Sent: 25 September 2010 17:50
> To: w3c-wai-ua@w3.org; Janina Sajka
> Cc: Léonie Watson; jeanne@w3.org
> Subject: Re: proposed pf access command requirements revisions 
> in light of UAWG review
> 
> aloha!  here is a restatement of the requirements, in accord 
> with janina's comments, gregory.
> 
> PART 1: PROPOSED REVISIONS TO THE 9 PFWG ACCESS COMMAND REQUIREMENTS
> 
> note: 3 additional requirements, based on event handler concerns 
>       pointed-to by members of the UAWG, follow the original 9 
>       requirements defined by PFWG; note the references to UAAG
>       are NOT intended to be part of the requirements document, 
>       but serve as a reference for purposes of reviewing this 
>       document.
> 
> Requirement 1: A device independent means to activate an access command.
> 
> Explanatory notes:
>     * accesskey, today, requires the author to set a pre-defined 
> key       yet this key may or may not work on certain browsers,
>  operating       systems, and/or devices. Therefore, the ability 
> for the user to       request a key mapping, and have the user 
> agent make the       assignment, is essential.
> 
> Requirement 2: Ability for an author to define a default access 
> command mapping, and for a user to override the default mapping; 
> the default access mapping and user override mapping must be 
> sharable and storable.
> 
> Requirement 3: Access commands should default to focus 
> behaviour; users must be able to:
>       (a) specify whether the default behaviour focuses or 
> activates           the target;
>       (b) choose whether to move focus to the element for which 
> the           access command has been defined, or to activate 
> the           element for which the access command has been 
> defined; and 
>       (c) override any author specified or default behaviour.
> 
> Explanatory notes for Requirement 3:
>     * If no user or author behaviour is specified, a clear 
> default       should be used, in most cases this would default 
> to a focus       behaviour.
> 
> Requirement 4: Ability for an author to provide a description 
> for an access command assignment; the user agent should 
> recognize and describe user overrides; such descriptions should 
> be storable and sharable;
> 
> Explanatory notes:
>     * This is a glaring omission in accesskey today. Today, even 
> if the       author does assign an accesskey, the user agent has 
> no way of       conveying to the user what it is for. 
> Descriptions could be       built from the semantics of the 
> elements pointed to.
> 
> Requirement 5: Ability to specify the target elements that will 
> respond to an access command, based on their id reference.
> 
> Explanatory note:
>     * This allows the author to define a set of targets to be 
> navigated       to in order. The user agent would be responsible 
> for cycling       through these in DOM order.
> 
> Requirement 6: Ability to specify target elements in terms of 
> their role, or implied ARIA semantics for the role if not 
> overridden by ARIA.
> 
> Explanatory notes:
>     * This allows the author to define a set of targets to be 
> navigated       to in order. The user agent would be responsible 
> for cycling       through these in DOM order. References: 
> Annotations for Assistive       Technology Products (ARIA) from 
> the HTML5 editor's draft
> 
> Requirement 7: Ability to specify a custom order for cycling 
> through multiple objects attached to a single access command.
> 
> Requirement 8: As long as the document is loaded in the browser, 
> user agents must be able to return the user to their previous 
> place in the navigation sequence.
> 
> Explanatory notes:
>     * As an example, @tabindex is used to define a navigational 
>       sequence that allows users to move focus forwards and 
> backwards       among a set of elements.
> 
> Requirement 9: Access command mappings should be available at 
> the beginning of the document.
> 
> Explanatory notes:
>     * Some DOM based assistive technologies coulg quickly access 
> the       mapping shortcuts versus having to walk the DOM. 
> Descriptions       could be built from the semantics of the 
> elements pointed to.
> 
>     * Additionally, a user should be able to designate a 
> specific       keyboard layout so that the user agent can 
> respond appropriately       to user input
> 
> =-=-=
> PART 2:
> 
> proposed keyboard requirements based on UAAG 2.0 GL 4.2 "Provide 
> access to event handlers"
> 
> source: post to w3c-wai-ua by Gregory J. Rosmaita 2010-09-23
> http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JulSep/0093.html
> 
> REQUIREMENT EV1: a user must, through keyboard input alone, have 
> the ability to obtain the list of input device event handlers 
> explicitly associated with an element.
> 
>    * Explanatory note EV1.1: Users interacting with a web 
> browser may      be doing so by voice, keyboard, mouse or 
> another input technology      or a combination of any of these. 
> No matter how the user is      controlling the user agent, he or 
> she need to know all the input      methods assigned to a 
> particular piece of content.
> 
>    * Explanatory note EV1.2: this is a Level A requirement of 
> UAAG 2.0      SC 4.2.1. "List Event Handlers"
> 
> REQUIREMENT EV2: a user must, through keyboard input alone, be 
> able to activate any input device event handlers explicitly 
> associated with an element.
> 
>    * Explanatory note EV2.1: Although it should not be so 
> designed,      some Web content is designed to work only with 
> certain input      devices, such as a mouse, thereby limiting 
> the availability of      those event handlers to specific 
> devices. Some users interacting      with a web browser may be 
> doing so by voice, keyboard, mouse or      another input 
> technology or a combination of any of these. No      matter how 
> the user is controlling the user agent, he or she must      be 
> able to activate any of the event handlers regardless of the     
>  interaction technology being used.
> 
>    * Explanatory note EV2.2: A user who cannot use a mouse needs 
> to      activate a flyout menu that normally appears 
> OnMouseOver. The      user should be able to navigate to a link 
> and activate it using      keyboard shortcuts.
> 
>    * Explanatory note EV2.3: This is a UAAG 2.0 SC 4.2.2 
> "Activate any      event handler", a Level A requirement
> 
> REQUIREMENT EV3: a user must, through keyboard input alone, be 
> able to simultaneously activate all input device event handlers 
> explicitly associated with an element.
> 
>    * Explanatory note EV3.1: One input method should not hold 
> back      another. People who don't use a mouse shouldn't 
> necessarily have      to map their input methods to the same 
> steps a mouse user would      take.       * Examples:            
> * Speech input users may combine moving the mouse up,            
>    left and clicking in a single command phrase.            * A 
> link has an onmousedown and an onmouseup event link.             
>   The keyboard user should be able to use 1 key click to         
>       activate both events.
> 
>    * Explanatory note EV3.2: this is UAAG 2.0 SC 4.2.3 "Activate 
> all      event handlers" a Level A requirement
------- End of Original Message -------

Received on Wednesday, 29 September 2010 00:10:30 UTC