RE: Should accesskey focus or activate?

First off, I'm assuming by access key, you're talking about the hotkeys
that can be used to jump to specific portions of a dialog.  I'm afraid I'm
going to have to agree with Dean on how this should work.  Now, I've never
seen access keys used in HTML forms, for example, I've never been able to
press alt+t to jump to a text box in a form, so I guess I'd ask is this
going to apply to HTML forms or just the dialogs in the program?  Even if
it is going to apply to HTML forms, I'd still tend to go along the lines
that Dean mentioned, those are what is going to be expected by a Joe Blow
average user.  If I pushed, for example, alt+S to activate a button, if it
just focused the button that would mean I'd need to press two keys instead
of one to activate that button, which is inefficient as well as not
standard.  Obviously controls like edit and combo boxes when the access
key is used should simply focus, although most check boxes will alter
their state when the access key is used, AKA if a checkbox is checked, it
will focus and uncheck.  There doesn't seem to be as clear of a standard
for radio buttons, my personal preference is that each one has its own
access key, and if the button is unchecked, pressing the access key checks
it.  
Personally, my personal message I tend to give is whenever possible,
follow standards.  Not standards are excelent, but especially in the case
of access software, the users and to an extent the various access programs
are going to expect that you follow the standards.  If a blind person who
relys on standards downloads an app that doesn't follow standards, first
off they won't know it doesn't follow standards the first time they run
it, and will get confused until they figure it out.  How long this takes
depends on how much computer experience the individual has, how much time
they're willing to spend with the program, and how much exposer they've
had to other programs that don't follow standards.  
Again, remember I'm speaking from a Windows viewpoint, and other operating
systems might handle this completely differently.  My response to this is
the browser needs to follow the user interface of the OS its running on.  
Hope this helps.
Ryan


On Tue, 24 Apr 2001, Charles McCathieNevile wrote:

> But common HTML practice is to provide an accesskety for the collection of
> radio buttons, rather than the individual buttons. I am abivalent on this for
> checkboxes and radio buttons, but I think it is important for links that they
> only focus. Likewise buttons like reset/submit in a form.
> 
> Anyone got better usability backgrounds?
> 
> Charles
> 
> On Tue, 24 Apr 2001, Dean Tessman wrote:
> 
>   Standard windows behavior is that an access key clicks a button/radio
>   button/check box, and focuses an object where more input is required, such
>   as an edit box/combo box/list box.  If we deviate from this, it's going to
>   become really confusing to anyone that uses programs other than Mozilla
>   (read: everyone).
> 
>   > -----Original Message-----
>   > From: Charles McCathieNevile [mailto:charles@w3.org]
>   > Sent: Tuesday, April 24, 2001 2:13 PM
>   > To: Aaron Leventhal
>   > Cc: w3c-wai-ig@w3.org; mozilla-accessibility@mozilla.org;
>   > joki@netscape.com
>   > Subject: Re: Should accesskey focus or activate?
>   >
>   >
>   > Hi Aaron,
>   >
>   > In my opinion they should focus. The problem if they activate
>   > without warning
>   > is one of discovery, and also of reducing the value of
>   > accesskey (which
>   > enables you to move from chunk to chunk in the "tab order" in
>   > a way that
>   > tabindex does not do properly).
>   >
>   > cheers
>   >
>   > Charles
>   >
>   > On Tue, 24 Apr 2001, Aaron Leventhal wrote:
>   >
>   >   Hello all, a Netscape developer wanted to know whether
>   > accesskey should
>   >   focus or activate controls, or whether it depends on the
>   > type of control.
>   >   Here's his question in detail:
>   >
>   >   > Hey Aaron,
>   >   >
>   >   > I wanted to get your opinion as accessibility guy on bug
>   > 55020, it's a
>   >   > question of whether or not access keys should just focus
>   > the element in
>   >   > question or focus and activate it.  You're cc'd on the
>   > bug, I'm not sure
>   >   > if you've read it.  The bug has some valid points about accidental
>   >   > activation of access key based items, especially since we
>   > allow the
>   >   > accesskeys to beat out things like alt-F for menu opening.
>   >   >
>   >   > So currently we focus and activate everything.  I tend to
>   > agree with the
>   >   > bug writer that we should move to only focusing things.
>   > All of the
>   >   > items can be keyboard triggered from there so a full
>   > keyboard solution
>   >   > still works.
>   >   >
>   >   > And just for extra info's sake, IE's solution is, I
>   > think, a bit unusual.
>   >   > They use a mix of focus and activation.  Buttons, for example, are
>   >   > activated.  Links, however, are not.  Text fields just
>   > get focus but
>   >   > what does activation of a text field mean anyway.  IE
>   > also overrides
>   >   > stuff like alt-F when an accesskey of that letter is in use.
>   >   >
>   >   > So anyway, I'm just curious if you have an opinion from
>   > an accessibility
>   >   > point of view.  My current stance is to go with the bug's
>   > solution and
>   >   > start doing focus only unless more arguments arise in favor of
>   >   > activation.
>   >   >
>   >   > 	-tom
>   >
>   >
>   >
>   >
>   > --
>   > Charles McCathieNevile    http://www.w3.org/People/Charles
>   > phone: +61 409 134 136
>   > W3C Web Accessibility Initiative     http://www.w3.org/WAI
>   > fax: +1 617 258 5999
>   > Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia
>   > (or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia
>   > Antipolis Cedex, France)
>   >
> 
> 
> -- 
> Charles McCathieNevile    http://www.w3.org/People/Charles  phone: +61 409 134 136
> W3C Web Accessibility Initiative     http://www.w3.org/WAI    fax: +1 617 258 5999
> Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia
> (or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France)
> 
>

Received on Wednesday, 25 April 2001 05:33:28 UTC