hotkey requirements redux

<note
class="coordination DRAFT coverMemo">

on the WAI CG call today, I offered a fresh summary of requirements as a draft
of what I could take to the Hypertext CG for Friday.

Jim has offered that you might discuss this on your call tomorrow.  Here's
a version for tomorrows review.

Al

PS: for reference, the last time we went around on this was at:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2005JulSep/0005

</note>

<draft>

Topic: accessibility requirement for shortcuts a.k.a. ACCESSKEYs

* Background: the Hypertext CG asked the WAI for some use cases.
the HTML WG asked if WAI would authenticate that there is a requirement
for ACCESSKEYs (or for access keys, along the lines of the XHTML 2.0 draft,
give or take).

* Summary and Requirements:

The answer is roughly "in part."
Yes, the WAI believes that formats should support shortcuts and that
these have to be activatable from the keyboard.
On the other hand, it is debatable (there are substantive arguments
for and against) as to whether the authors should be afforded a means
to set what key should be used to activate these shortcuts).

+ Firm requirements:

   - content [allowing for implicit in role] MUST have
       [machine identifiable functional equivalent of]
       labels for shortcut action/outcome
      compare with WCAG2: 
http://www.w3.org/WAI/GL/WCAG20/guidelines.html#understandable
      compare with UAAG1: 
http://www.w3.org/TR/UAAG10/guidelines.html#tech-ui-text-eq
      compare with UAAG1: 
http://www.w3.org/TR/UAAG10/guidelines.html#tech-info-current-author-config

   - User Agents MUST afford shortcut activation somehow (work around 
key collisions)
     compare with UAAG1: 
http://www.w3.org/TR/UAAG10/guidelines.html#tech-device-independent-handlers

   - User Agent SHOULD let user pick key bindings as much as possible.
     compare with UAAG1: 
http://www.w3.org/TR/UAAG10/guidelines.html#tech-configure-input

+ Debatable issue:
   ? content+UserAgent MAY let author suggest mnemonic keys for 
shortcut activation

* Use cases

+ case 0
    user: Temporarily Able Bodied
    method of use:
    -- mix of recall and recognition; user may recognize hotkey styling in
       page or may recall hotkey for repetitively-used function.  recalled
       function may be a web idiom like 'home' or an application-specific
       notion such as 'previous in thread' or "I'm feeling lucky."
    -- mix of focus and activate-immediate responses (emulates mouse
       click).  Checkbox toggles; text box focuses only.
         http://lists.w3.org/Archives/Public/w3c-wai-ua/2006JanMar/0012.html

+ case 1
     user: has Repetitive Stress Injury, must avoid mouse use, full vision
     method of use:
     -- visual review of page;
     -- detects short-cut items by styling,
     -- decides to activate by reviewing [action label-equivlent] in scene;
     -- activates keycode;
     -- desires activate-immediate system response
    -- Note:  this user derives added value from author-defined, 
application-unique shortcuts,
        over and above web-generic concepts that can be bound by role.
+ case 1A
    user: single-switch or bio-feedback
    as per case 1, but it gets more important to afford the 
activate-immediate behavior

+ case 2
     user: blind; using screen reader
     method of use:
     -- AT pushes page summary on load
     -- page summary contains alert that the page offers shortcuts
     -- review of shortcuts at this point is a pull option; requires 
overt user request
     -- memorizes mapping of hotkeys to concepts
     -- activates hotkeys by recall, primarily
     -- can live with always-focus behavior; full keyboard agility, can use
         <MODIFIER-key><ENTER> as key sequence when wants 
activate-immediate response
     -- response may yet better be profiled so that accelerators bound 
to standard role values
        that are known to have unique outcomes (home, logout)  may 
behave as activate-immediate
        while others focus only and require the user to make another 
action to activate anything.
     -- note: this user is critically dependent on having something 
that functions as a usable label
        for the shortcut action available in a machine-recognizable 
way. Need the functional
        equivalent of API resources to synthesize a context-menu entry.
    -- in terms of author uptake, there is a risk that if the author 
can define "what does it" and
        can get by without adequate labeling of "what it does" that 
most shortcuts will be so
        under-described.
    -- Note: for this user, the author's nomination is of little 
benefit, aside for use in existing
        browsers that haven't implemented a new design.  Keys are much 
more plentiful in
        the screen reader case, but so heavily used as to still be 
quite scarce and the usable
        binding is one worked out in the client context.

* Pro and con on debatable issue:

Q: Should author be able to irrevocably bind keys to accelerators?
A: No (i18n, OMA, WAI).  Doesn't work across keyboards, OS, browser, etc.

Q: Should author be able to nominate keys so long as user agent will 
repair non-available?
A: Maybe.  Consider:
Pro: makes shortcuts available for application-specific actions. 
Makes shortcut-creation more
appealing to look-and-feel-obsessed author/designers.
Con: Confusing when keys have to be reprogrammed and page elsewhere 
assumes original key, e.g.
Con: hard to feed back actual key into styling of label.
Con: Lacking ironclad enforcement of label-euqivalent for "what it 
does," can't allow field
option to only specify "what does it."

</draft>

Received on Wednesday, 1 February 2006 22:54:28 UTC