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

Only a first pass grammar reaction for now ...

In the several spots where the text says "stored and capable of being
shared," suggest saying "storable and sharable."

At Requirement 9 we have mixed modal verbs--both indicative and
subjunctive. That doesn't make sense. It's either one or the other, i.e.
should/could (subjunctive) or can will (indicative). Which is it?

Janina


Gregory J. Rosmaita writes:
> 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

-- 

Janina Sajka,	Phone:	+1.443.300.2200
		sip:janina@asterisk.rednote.net

Chair, Open Accessibility	janina@a11y.org	
Linux Foundation		http://a11y.org

Chair, Protocols & Formats
Web Accessibility Initiative	http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)

Received on Saturday, 25 September 2010 05:17:22 UTC