Re: activation / focus and users Re: Access Key

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
> >>>
> >>>
> >>
> >>
> >
> >
> >

Received on Tuesday, 1 October 2002 23:21:22 UTC