Re: activation / focus and users Re: Access Key

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 17:30:53 UTC