Re: Guideline 2.7

Hi! I'm afraid that we have previously-overlooked redundancy between 2.7.1 "Discover navigation and activation keystrokes" and the pair 2.1.6 "Present Direct Commands in Rendered Content" and 2.1.7 "Present Direct Commands in User Interface".

I think the former (2.7.1 "Discover navigation and activation keystrokes") is the weaker version, because:
1. If exposing direct keyboard commands programmatically is required under Guideline 4 ("Facilitate Programmable Access"), we can just reference it here under the Related Resources, rather than repeating it in the SC itself; otherwise we'd end up with lots of SC repeating things in Guideline 4.
2. The title should be either a noun phrase or an imperative directed at the developer, whereas this one sounds like it's addressing the user.
3. I think the phrase "direct keyboard commands" is better than "navigation and activation keystrokes", as the latter would be broad enough to encompass direction keys and the like.

I like some of Simon's proposed content, and would like to see those folded into 2.1.6/2.1.7 so they address both access keys and "mouseless browsing" functionality.

We did not propose combining 2.1.6 and 2.1.7 because they currently have two different priorities. If we change them to be the same they could be combined the way 2.7.1 was.

Also note that as part of our general work on looking at focus and keyboard issues, Kim and I are going to propose splitting 2.1 "Ensure Full Keyboard Access" into several smaller, move specific guidelines, and as such we'll propose renumbering many of them, including 2.1.6 and 2.1.7.

     Thanks,
     Greg

-------- Original Message  --------
Subject: Guideline 2.7
From: Simon Harper <simon.harper@manchester.ac.uk>
To: UAWG list <w3c-wai-ua@w3.org>
Date: 3/11/2011 1:14 AM
> OK so I'm chomping my way through 2.7 - here sc 2.7.1 for your perusal...
>
> 2.7.1(former 4.7.7) Discover navigation and activation keystrokes: Direct navigation and activation keystrokes are discoverable both programmatically and via perceivable labels. (Level A)
> *
> *
> *Intent of Success Criterion 2.7.1(former 4.7.7) :*
> This is sometimes known as mouse-less browsing. Some users have problems controlling the mouse and/or the keyboard. Therefore users often find control buy speech recognition to be advantageous. In this case it is much more efficient for navigation and activation selection points to be both viewable by the user and controllable by their assistive technology.
>
> Examples of Success Criterion 2.7.1(former 4.7.7) :*
> Mary cannot use the mouse or keyboard due to a repetitive strain injury, instead she uses voice control technology. Because the hyperlinks are not presented with their direct navigation **key combination**s, Mary has to say the work 'tab' 12 times to get to her desired hyperlink. If each link had been presented with its **direct navigation key combination Mary could have just said 'select link 12'.*
> *
> *Related Resources for Success Criterion 2.7.1(former 4.7.7)
> Mouseless Browsing Firefox Extension:
> https://addons.mozilla.org/en-us/firefox/addon/mouseless-browsing/
>
> Perceivable navigation and activation keys:
> http://www.mouseless.de/index.php?/content/view/17/30/
>
>
>
> Cheers