proposed pf access command requirements revisions in light of UAWG review

NOTE TO UAWG: i need to circulate this to the w3c-wai-pf list by
monday, 28 september 2010 for it to be voted on by the workgroup
as a friendly amendment to our previously articulated requirements
document, which can be found at:

http://www.w3.org/WAI/PF/HTML/wiki/Access/pf_requirements

along with its discussion page, which contains email threads, comments,
 and citations from UAAG 2.0:

http://www.w3.org/WAI/PF/HTML/wiki/Talk:Access/pf_requirements

PLEASE be sure to reply-to-all if you have any comments, additions, 
disputes or editorial suggestions, as there are collaborators and 
interested parties to whom i am also circulating this proposed 
revision/attempt to ascertain if everything we've discussed on-list
and in telecons have been addressed; 

and THANKS for your contributions, past and present, gregory.


PART 1: PROPOSED REVISIONS TO THE 9 PFWG ACCESS COMMAND REQUIREMENTS

note 1: only Requirements 2, 3 and 4 have proposed revised text; 
        requirement 9 has text added to the explanatory note; 
        suggested new text is inticated using <ins>new text</ins>
        and deleted text is indicated using <del>deleted text</del>;

note 2: 3 additional requirements, based on event handler concerns 
        pointed-to by members of the UAWG, follow the original 9 
        requirements defined by PFWG


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.

    * proposed addition to Requirement 2: "the default access mapping and 
      user override mapping must be stored and capable of being shared",

    * PROPOSED REVISION: "Requirement 2: Ability for an author to 
      define a default access command mapping, <ins>and for a user to 
      override the default mapping;the default access mapping and 
      user override mapping must be stored and capable of being 
      shared</ins>"


Requirement 3: Access commands should default to focus behaviour, 
ability for authors to specify whether the default behaviour focuses 
or activates the target, and for a user to overwrite 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. 

    * PROPOSED REVISION: Requirement 3: Access commands should default 
      to focus behaviour; <del>the ability for authors</del> <ins>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</ins> any author specified or default behaviour.


Requirement 4: Ability for an author to provide a description for an 
access command assignment.

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. <ins>Descriptions could be 
      built from the semantics of the elements pointed to.</ins>

    * proposed addition to Requirement 4: "the user agent should 
      recognize and describe user overrides; such descriptions should 
      be stored and capable of being shared"

    * proposed addition to Requirement 4: descriptions could be built 
      from the semantics of the elements pointed to. (added to 
      Explanatory note instead of the Requirement itself)

    * PROPOSED REVISION: Requirement 4: Ability for an author to provide 
      a description for an access command assignment; <ins>the user agent 
      should recognize and describe user overrides; such descriptions 
      should be stored and capable of being shared;</ins>


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:
    * This way, some DOM based assistive technologies can quickly access 
      the mapping shortcuts versus having to walk the DOM. 
      <ins>Descriptions could be built from the semantics of the elements 
      pointed to.</ins> (added to Explanatory Note rather than
      Requirment 9 itself)

    * proposed second explanatory note: 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" [1]

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 



[1] source: 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JulSep/0093.html

Received on Saturday, 25 September 2010 01:17:39 UTC