Re: UAAG v2 Draft - Review

Hi! Here are some comments on keyboard items in the current draft, some of which address comments by other reviewers:

*#1 Delete 1.9 Provide An Effective Focus Mechanism
*
Guideline 1.9 (Provide and Effective Focus Mechanism) is still around, but the reorganization that Kim and I proposed would have deleted it and scattered its success criteria into other, more targeted guidelines.  Some of that was done, but if all of our recommendations are implemented the few remaining there now will be gone:

1.9.3 (User Interface Focus: An active input focus is provided) was to be deleted as redundant to 2.1.2 (2.1.2 Keyboard Focus: Every viewport has an active or inactive keyboard focus at all times).

1.9.4 (Extensions Focusable) was to be deleted because the definition of user agent in the implementing document made clear that UI extensions and plug-ins are user agents and that all success criteria therefore apply to them.

1.9.6 (Retrieve Focus) has been moved to 4.2.2, so the original at 1.9.6 should be deleted.

1.9.7 (Return Focus) has been moved to 4.2.2, so the original at 1.9.6 should be deleted.

1.9.10 (Only on User Request) has been moved to 3.4.1, so the original at 1.9.10 should be deleted.

1.9.11 (On Focus) has been moved to 3.4.2, so the original at 1.9.11 should be deleted.
*
**#2 Rename 2.1.3 Keyboard Navigability*

2.1.3 (Keyboard Navigability) has been whittled down from our original proposal, which required the user be able to move the keyboard focus to any viewport and anything that takes input, to only discussing viewports. That may be acceptable because the ability to move between other controls may be handled adequately by 2.1.1 (Keyboard Operation). In fact, one could argue that 2.1.3 (Keyboard Navigability) is *entirely* redundant to 2.1.1 (Keyboard Operation). But if the group wants to keep 2.1.3 (Keyboard Navigability) as it currently reads, then we should at least change its title to reflect its reduced scope, perhaps to something like "Viewport Navigation".

*#3 2.1.6 Separate Selection from Activation**vs. 3.4.2 Avoid Side Effects of Navigation*

This SC seems entirely redundant to 3.4.2 (Avoid Side Effects of Navigation). They currently read:

2.1.6 Separate Selection from Activation: The user can specify that selection is separate from activation (e.g., navigating through a set of radio buttons without changing which is the active/selected option).

3.4.2 Avoid Side Effects of Navigation: The user can move the keyboard focus to or from any enabled element without causing the user agent to take any further action.

I think the latter is clearer and has a better title is better, although the former's inline example is also helpful. Perhaps copy it into the latter?

*#4 Revise 2.1.7 Follow Text Keyboard Conventions*

The phrase "including, but not necessarily limited to," should probably be replaced by something like "such as", in order to avoid implying that the listed commands be implemented even on platforms where they are not part of the operating conventions. Or, more precisely but longer, it could end with something like "on platforms where those are standardized".

*#5 Delete 2.2.3 Default Navigation Order*

Kim and I had meant for what is now 2.2.3 (Default Navigation Order) to be moved to Guideline 3.4 (The user agent must behave in a predictable fashion) because, as its IER makes clear, its intent is to provide a consistent user experience across sessions and browsers, and that's what 3.4 is all about. While that was in our working notes, we failed to put it into the Wiki page so it didn't make it into the latest editor's draft. I suggest we complete the move.

*#6 Elaborate on 2.3.2 Direct Activation and 2.3.3 Present Direct Commands*

The first might be clearer if we include an inline example, such as "2.3.2 Direct activation: The user can move directly to and activate any operable elements in rendered content (e.g. by having the user agent create shortcuts for each). (Level AA)"

Similarly, we could elaborate on 2.3.3 by expanding its inline example to reference 2.3.2, such as "2.3.3 Present Direct Commands in Rendered Content: The user can have any recognized direct commands (e.g. accesskeys <ins>defined by the author or shortcuts added by the user agent</ins>) in rendered content be presented with their associated elements (Level A)"

*#7 Rename Principle 4*

In Kim's and my working notes we'd renamed Principle 4 and added moved some success criteria into a new Guideline 4.2, so the new organization was supposed to be:

     4. Facilitate programmatic access
         4.1 Assistive technology
         4.2 Nested user agents

Unfortunately we'd neglected to change the title of Principle 4 in the Wiki page, so it wasn't changed in the latest editor's draft where it's still titled "Assistive Technology" just like 4.1. I recommend it be renamed to "Facilitate programmatic access" or something similar.

*#8 Clarify/fix 4.3.2 Return Focus*

This currently reads "4.2.3 Return Focus [former 1.9.7, before that 3.11.7]: AAt any time, the user agent is able to retrieve input focus from a nested viewport (including nested viewports that are user agents). (Level A)"

The AAt should be "At".

But what is really the goal of this SC? Having the user agent be able to retrieve focus seems less important than allowing the user to be able to do so, and particularly doing so using the keyboard. (Are there any cases where one cannot get back even using a mouse?)

We could change "user agent" to "user", as in "the user is able to retrieve input", and/or add "using the keyboard" or "using any supported input device" (modality?).

If changed to be user-centric it would no longer belong in Principle 4, Programmatic Access.

*#9 Change formatting of deleted links*

It would be helpful if we could adjust the style sheet so that deleted links show up in a color that contrasts with the brown background used for deleted text.

     Thanks,
     Greg