Re: AccessKey Behavior based on media

Jon Gunderson wrote:
> Steven,
> 
> Could the note also encourage features that allow the user to review the
> current access key bindings of a resource.

Hi Steven,

I have a few questions and comments.

1) Does "activate" mean "move the focus, then activate"? For
    instance, if I go to another page and then do "back",
    will the focus be on the hyperlink I reached through
    that accesskey?

2) Is the proposed errata text based on the behavior of
    deployed user agents? Has there been demand for the
    "set-focus-only" behavior, or is that just how some
    user agents implement this feature of HTML?

    I reviewed UAAG 1.0 and I believe that the document
    is silent on the matter of separating focus from activation
    in the case of direct access (e.g., through accesskey).
    That may be an oversight, or simply lack of demand for
    that feature. I would like UAAG 1.0 to support the
    HTML WG's approach, and one way to do this (though we
    are extremely late in the game) is to mention this type
    of configuration in the Techniques Document.

    I think that in any case, the HTML spec should explain
    a little bit why this type of configuration is useful,
    and that may require a bit more explanation about the
    purpose of focus; in UAAG 1.0, focus is a navigation
    tool that preserves context. Direct access techniques
    such as accesskeys can serve two purposes:

     a) To allow the user to perform some task quickly.
     b) To provide more efficient navigation (i.e.,
        focus displacement) than sequential navigation.

    In the UAAG 1.0 document, we use the "c" accesskey
    for direct access to the table of contents. The purpose
    is not to allow users to quickly follow the first link
    in the table of contents, but to navigate to it
    efficiently.

    I think that format specifications should
    allow authors to specify these two behaviors independently,
    so that users are not required to reconfigure their browsers
    at all. This seems to me to be a case where the author
    knows the desired effect (navigation or activation) and
    should encode it as such; the burden should not be on the
    user.

    For direct access with intent to activate, I don't
    think the "focus only" option is very interesting: the user
    would generally only use those accesskeys once the binding
    between key and task is known. In this case, there is no
    longer a need for orientation, and the user is unlikely to
    want to focus first then activate. I also note that the user
    is unlikely to want to discover available accesskeys by randomly
    testing key combinations; the focus-but-don't-activate should
    not be taken as a mechanism for allowing binding discovery
    (see instead UAAG 1.0 checkpoint 11.2).

    I can imagine the focus-but-don't-activate setting as a repair
    technique to generate additional direct navigation stops.
    However, since UAAG 1.0 includes requirements designed to
    improve efficient navigation, I don't know that the repair
    technique of turning activation hints into navigation hints
    should be condoned.

    I realize that for HTML, there's no question of including
    markup that would allow the author to distinguish navigation
    stops from task shortcuts. XAG should include this type
    of recommendation if it passes muster in WAI PF. However,
    the HTML 4 spec might at least say a word more about
    why the configuration can be useful to users.

3) I'm not sure why handhelds are singled out. Is the reason
    "that's how things work today" or is there some other
    design reason?

    If there is no design justification (i.e., if all
    users of any device might find both configurations
    useful) then I recommend the following approach instead:

    a) Requirement: "User agents SHOULD provide at least
       two configurations for accesskeys: set focus only,
       and set focus and activate.

    b) Requirement: User agents rendering to the 'handheld'
       medium SHOULD use the default configuration "set focus
       and activate." Other user agents SHOULD use the
       default configuration "set focus only".

   Whether or not there is a design justification, I think
   the spec should say something about why handheld devices
   are singled out. And, as I mentioned earlier, I think the
   spec should explain why the configuration is useful to
   some users.

Thank you,

  - Ian


[1] http://www.w3.org/TR/2002/PR-UAAG10-20021016/

On Wed, 30 Oct 2002, Steven Pemberton wrote:


 >
 > Dear WAI XTech,
 >
 > Here is the proposed HTML 4.01 errata text for handling of access 
key.
 > Please feel free to review now, or later when we publish the next 
proposed
 > errata document, or both.
 >
 > Best wishes,
 >
 > Steven Pemberton
 > Chair HTML WG
 >
 > <blockquote>
 > <p>
 > When rendering to the "handheld" medium, pressing an accesskey for a
 > hyperlink or button SHOULD activate.  When rendering to all other 
mediums,
 > pressing an accesskey SHOULD transfer the focus, even for 
hyperlinks and
 > buttons.
 > </p>
 > <p>
 > User agents MAY (and are encouraged to) provide a user preference to
 > override the default behavior, and allow accesskeys to always 
activate
 > hyperlinks and buttons, or always focus hyperlinks and buttons.
 > </p>
 > <blockquote>
 >
 > See: 
http://lists.w3.org/Archives/Member/w3c-html-wg/2002OctDec/0042.html
-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

Received on Friday, 1 November 2002 10:24:48 UTC