Re: activation / focus and users Re: Access Key

Ideally the behavior of accesskeys should be configurable by the user and 
that the user agent should provide users with options on the behavior.  I 
will add this a useful technique to the User Agent Accessibility 
Guidelines.  But maybe this type of requirement should be considered by the 
HTML working group in a future recommendation.

Jon


At 11:21 PM 10/1/2002 -0400, Al Gilman wrote:
>Let me throw in another curve ball, here.
>
>I think that one problem with ACCESSKEY is that it is amenable to 
>interpretation as
>either of two kinds of service.
>
>One is a site-wide user interface extension.  This is a verb like 'home' the
>result of which is the same across the site, or like 'help' where the
>mnemonic sense is the same even 'though sometimes it leaves you in a
>context-sensitive resulting state.  For these things, the activateImmediate
>behavior is almost always what one wants.
>
>But the HTML markup does not limit its use to this case.  The markup can be
>used in a way where the user will almost certainly have the function and its
>key binding in recall memory, but equally it can be used in ways where 
>they won't.
>
>The problem is that the optimum behavior is something that has to take into
>account and balance the cost of input symbol activations and the risk of
>erroneous function activations.  Both device and disability contribute to
>making either the cost of input symbol activation unusually high (motor
>disability; mobile phone keypad) or the risk of erroneous function
>activation unusually high (low/no vision; tremor).  So there is no one bias
>that fits all persons with disabilities, or others in varying situations or
>delivery contexts.
>
>One thing to think about is to try to create two markup constructs which can
>be divided between the two default behaviors (overridable in the User 
>Agent all
>the same).
>
>One approach to this would be to have access keys bound to LINK elements 
>default
>to justDoIt and access keys bound to A elements default to 
>focusAndWait.  Maybe
>that has continuity problems (small but annoying differences from existing
>behavior patterns).  But it gives an example of the kinds of things we might
>think about.
>
>Al
>
>
>At 05:41 PM 2002-10-01, Tantek Çelik wrote:
>
>>I actually agree precisely with the example of mobile devices that Doug
>>presents and his reasoning.
>>
>>To that extent, I think it should not only be hyperlinks that have the
>>"activate immediate" behavior on mobile devices.  Buttons for example
>>(<button>, <input type="button|submit|reset|radio|checkbox">) should also
>>have that behavior.  This will help with consistency for those UAs.
>>
>>I still think that for other interactive user agents (e.g. desktops,
>>laptops, TVs), the "focus immediately" behavior is strongly preferred, and
>>thus should be the default.
>>
>>I believe that the right thing to do is to add an exception clause to HTML4
>>for when rendering to a 'handheld' medium.  E.g.
>>
>>  "When presenting an HTML document to a mobile device (e.g.
>>media='handheld'), typing an accesskey should focus _and_ activate the
>>respective element, e.g. hyperlinks should be activated and navigated, and
>>buttons should also be similarly activated."
>>
>>By tying this difference in behavior _precisely_ to the 'media'
>>attribute/concept, it provides authors a single place to make distinctions
>>regarding presentation and behavior when designing the interaction for
>>various different media.  It also provides clear guidance to user agent
>>implementers.
>>
>>Thanks,
>>
>>Tantek
>>
>>
>>On 10/1/02 1:46 PM, "Doug Dominiak" <doug.dominiak@openwave.com> wrote:
>>
>> > I would like to present the view of the mobile browser community and
>> > say that we very much require the "activate immediately" behavior of
>> > access keys as they relate to hyperlinks. With the usability of current
>> > interfaces somewhat strained, every keystroke by the end user matters.
>> > Movement of focus with the first keystroke followed by activation of
>> > the link by the second is just not acceptable.
>> >
>> > The notion of allowing duplicate access key bindings is an interesting
>> > one, though not at all compelling for the mobile browser space. I
>> > don't think it motivates the "focus immediately approach", though I
>> > appreciate Tantek's other 4 reasons.
>> >
>> > I feel strongly that "focus immediately" behavior of access key applied
>> > to hyperlinks in mobile browsers in unacceptable and would not be
>> > implemented, so I would like to see a solution that would avoid 
>> divergence.
>> >
>> > Thanks for your consideration.
>> >
>> > Regards,
>> > Doug Dominiak
>> > Openwave Systems
>> >
>> > ----- Original Message -----
>> > From: "Tantek Çelik" <tantek@cs.stanford.edu>
>> > To: "Jon Gunderson" <jongund@uiuc.edu>; "Charles McCathieNevile"
>> > <charles@w3.org>
>> > Cc: "WAI Cross-group list" <wai-xtech@w3.org>; "HTML WG" 
>> <w3c-html-wg@w3.org>
>> > Sent: Tuesday, October 01, 2002 11:42 AM
>> > Subject: Re: activation / focus and users Re: Access Key
>> >
>> >
>> >>
>> >> It appears that we are talking about two different (but at times
>> >> overlapping) communities of users.
>> >>
>> >> (1) Accessibility
>> >> (2) Power Users
>> >>
>> >> I believe that while serving (1) very often indirectly serves (2) as 
>> well,
>> >> (1) should take priority over (2) when conflicts arise, or when designing
>> >> "default behaviors".
>> >>
>> >> I would assert that Charles' use of his "own case" and reference to
>> >> efficiency places his example in (2).
>> >>
>> >> While I certainly understand the plea for efficiency, is there really 
>> that
>> >> much difference in efficiency between:
>> >>
>> >> a) type accesskey (with modifier)
>> >> b) type accesskey (with modifier) and press return
>> >>
>> >> ?
>> >>
>> >> As far as overuse of hands, consider that typical typist convention is to
>> >> use the right pinky finger to press the return key, and the right pinky
>> >> finger is one of the least used from a frequency of keypresses 
>> standpoint.
>> >>
>> >> I concur with Jon Gunderson's point about sequentially moving the focus
>> >> among form controls/links with the same accesskey.[2]
>> >>
>> >>
>> >> As far as changing implementations, this is specifically why I raised 
>> this
>> >> issue as a necessary clarification to HTML4.[2]
>> >>
>> >> In IE5/Mac we implemented the "activate immediately" behavior of 
>> accesskey
>> >> on hyperlinks based upon literal reading of the informative example(s) in
>> >> HTML4.
>> >>
>> >> Given experience and understanding since, I think this was a mistake.
>> >>
>> >>
>> >> I want to change this in our next major release to "focus immediately"
>> >> behavior which will have the following advantages (raised by the
>> >> participants in this discussion):
>> >>
>> >>  a) consistent behavior between IE/Mac and IE/Windows (authors like that)
>> >>  b) consistent behavior among elements (users like that)
>> >>  c) ability to gracefully handle duplicate accesskeys by rotating focus
>> >>  d) ability to have focus event handlers actually do something on links
>> >>  e) increased safety by reducing the chance of accidental link activation
>> >>
>> >> The only argument/advantage that I have seen/heard for the "activate
>> >> immediately" behavior is:
>> >>
>> >>  a) greater efficiency
>> >>
>> >> Which I believe is not that much anyway, as explained above.
>> >>
>> >> The specific errata to HTML4 that I proposed to fix this is documented in
>> >> [2].
>> >>
>> >> If there is sufficient direction of opinion on this issue, would it be
>> >> possible to achieve a consensus so I that I may move forward with making
>> >> this change in our implementation in concert with that consensus?
>> >>
>> >> Thanks,
>> >>
>> >> Tantek
>> >>
>> >> [2]
>> >>  http://lists.w3.org/Archives/Member/w3c-html-wg/2002JulSep/0549.html
>> >>
>> >> 
>> ---------------------------------------------------------------------------
>> >> Tantek 
>> Çelik                                         tantek@cs.stanford.edu
>> >> Tasman Development Lead, Microsoft 
>> Corporation        tantekc@microsoft.com
>> >> Representative to W3C CSS and HTML working groups
>> >> 
>> ---------------------------------------------------------------------------
>> >>
>> >>
>> >> On 10/1/02 8:49 AM, "Jon Gunderson" <jongund@uiuc.edu> wrote:
>> >>
>> >>>
>> >>> The other advantage of only moving focus is that if the same 
>> accesskey is
>> >>> used multiple times on a page focus can move sequentially between 
>> the form
>> >>> controls or links.
>> >>>
>> >>> The HTML spec [1] seems to indicate that links should be automatically
>> >>> activated.  But the two implementations of accesskey Internet 
>> Explorer 5.0+
>> >>> and Netscape Navigator 6.0+ differ on their interpretation.  IE only 
>> moves
>> >>> focus and NN moves focus and activates the link.  Each technique has its
>> >>> own advantages and disadvantages, but I think it would be better for the
>> >>> user if browsers were consistent, and therefore the feature more
>> >>> predictable for end users.  But I guess this is a mute point since 
>> IE and
>> >>> NN both do something different.  I doubt either will change their
>> >>> implementation.
>> >>>
>> >>> Jon
>> >>>
>> >>> [1] http://www.w3.org/TR/html401/interact/forms.html#adef-accesskey
>> >>>
>> >>> At 11:27 AM 10/1/2002 -0400, Charles McCathieNevile wrote:
>> >>>> What kind of users are we talking about here?
>> >>>>
>> >>>> It seems there is a consensus that there are some users for whom 
>> the focus
>> >>>> then activate sequence is an important safety feature - people using
>> >>>> primarily voice interaction, who may not remember all the access keys,
>> >>>> people
>> >>>> who are likely to bounce on keys by accident.
>> >>>>
>> >>>> My own case is different - I have a problem with overuse of my 
>> hands, but I
>> >>>> can (normally) see a lot of information presented visually and it 
>> is rare
>> >>>> that I hit the wrong key, or am surprised by what happened if I did. I
>> >>>> believe there are a number of people in related situations (I know a
>> >>>> handful
>> >>>> personally) who appreciate the efficiency of the direct activation 
>> method
>> >>>> above all.
>> >>>>
>> >>>> I presume there are people who are somewhere between the two - in some
>> >>>> circumstances they appreciate the efficiency, but in other cases 
>> they want
>> >>>> to
>> >>>> use the safety feature. (This is also relevant to Jonny's comment about
>> >>>> triggering focus events)
>> >>>>
>> >>>> Can anyone help provide more data about the user scenarios they are
>> >>>> outlining?
>> >>>>
>> >>>> Cheers
>> >>>>
>> >>>> Chaals
>> >>>>
>> >>>> On Tue, 1 Oct 2002, Jon Gunderson wrote (among other things):
>> >>>>
>> >>>>>
>> >>>>> Accesskeys are important for allowing direct navigation to links 
>> and form
>> >>>>> controls, especially web based applications that people use on a daily
>> >>>>> basis.  When I use accesskeys I always provide built-in 
>> documentation to
>> >>>>> what accesskeys are available in addition to the underlining 
>> technique of
>> >>>>> the key letter in the link or form label.  We have developed a web 
>> based
>> >>>>> database to keep track of disability services here at UIUC that uses
>> >>>>> accesskeys and works very effectively to speed navigation for screen
>> >>>>> reader
>> >>>>> users.  We have a internal link on each page to a list of the 
>> available
>> >>>>> accesskeys on the page[1].
>> >>>>>
>> >>>>> My criteria for accesskeys:
>> >>>>> 3. I think moving focus is better than automatic activation (the 
>> IE rather
>> >>>>> than NN way)
>> >>>>>
>> >>>>> Jon
>> >>>>>
>> >>>>> And at 10:14 PM 9/30/2002 +0200, Jonny Axelsson wrote (among other
>> >>>>> things):
>> >>>>>
>> >>>>>> Here is a collection of my opinions on accesskey.
>> >>>>>>
>> >>>>>> I would agree with Tantek on the effect of triggering an accesskey.
>> >>>> While it
>> >>>>>> is more efficient to do actions with no confirmation, the risk of
>> >>>> triggering
>> >>>>>> an accesskey accidentally, together with the possibility that the
>> >>>> action may
>> >>>>>> be irreversible (like a POST or even a GET under some 
>> circumstances, or
>> >>>> some
>> >>>>>> scriptable control), has convinced me that giving the element 
>> focus is
>> >>>>>> the
>> >>>>>> best and most predictable alternative.
>> >>>>>>
>> >>>>>> While there are conflicting opinions on whether keyboard navigation
>> >>>>>> should
>> >>>>>> trigger events (navigating using a keyboard would normally 
>> traverse all
>> >>>>>> intervening elements on the way to the target, you would not want to
>> >>>> trigger
>> >>>>>> those elements), accesskey should trigger a focus event. It is the
>> >>>>>> keyboard
>> >>>>>> equivalent to point and click (or rather point and mousedown).
>> >>>>>>
>> >>>
>> >>> Jon Gunderson, Ph.D., ATP
>> >>> Coordinator of Assistive Communication and Information Technology
>> >>> Division of Rehabilitation - Education Services
>> >>> MC-574
>> >>> College of Applied Life Studies
>> >>> University of Illinois at Urbana/Champaign
>> >>> 1207 S. Oak Street, Champaign, IL  61820
>> >>>
>> >>> Voice: (217) 244-5870
>> >>> Fax: (217) 333-0248
>> >>>
>> >>> E-mail: jongund@uiuc.edu
>> >>>
>> >>> WWW: http://www.staff.uiuc.edu/~jongund
>> >>> WWW: http://www.w3.org/wai/ua
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>> >

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
MC-574
College of Applied Life Studies
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL  61820

Voice: (217) 244-5870
Fax: (217) 333-0248

E-mail: jongund@uiuc.edu

WWW: http://www.staff.uiuc.edu/~jongund
WWW: http://www.w3.org/wai/ua

Received on Wednesday, 2 October 2002 10:16:32 UTC