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

Received on Saturday, 25 September 2010 16:50:53 UTC