W3C home > Mailing lists > Public > wai-xtech@w3.org > October 2002

RE: activation / focus and users Re: Access Key

From: Gregg Vanderheiden <gv@trace.wisc.edu>
Date: Wed, 02 Oct 2002 22:50:29 -0500
To: "'Tantek Çelik'" <tantek@cs.stanford.edu>, "'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>
Message-id: <002401c26a90$04adf760$09c10681@GV6101>

Hmmm

This is exactly the topic we had to deal with in the WCAG.

That is.

a)  what is a power feature for one person -- is access for another.
b)  where "more efficiency and speed"  may be frosting for some items or
people it is not for others.

e.g.

- it is ok if the power switch takes 10 times as long to activate -- but
not the letters on the keys on the keyboard take 10 times as long... the
person can do one days writing every two weeks.

- quickly jumping to an item without having to reach for a mouse may be
convenient for some-  but may be the only way of getting to the function
without 47 tab keypresses for another.

 

Gregg

------------------------------------

Gregg Vanderheiden Ph.D.

Ind Engr - Biomed - Trace, Univ of Wis

gv@trace.wisc.edu


-----Original Message-----
From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On
Behalf Of Tantek Çelik
Sent: Tuesday, October 01, 2002 1:43 PM
To: Jon Gunderson; Charles McCathieNevile
Cc: WAI Cross-group list; HTML WG
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 Wednesday, 2 October 2002 10:51:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:15:37 GMT