55020 - Access key shouldn't activate element but only give focus

Status: RESOLVED WONTFIX

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Antti Näyhä]

OVERVIEW DESCRIPTION

Quoting myself from bug 959:

> Access keys on links should just give the link focus, instead of following
> the link immediately.  [..]  To clarify my point, let's take another example:
>
> A long page has a navigation link at the bottom:
>   <a href="first.html" accesskey="f"><strong>F</strong>irst page</a>
> 
> This link is not visible without scrolling, so the user has no way of knowing
> that 'f' access key is used by the page.  Now, immediately after arriving on
> the page, the user presses Alt+f to bring down the File menu.  Instead (s)he's
> taken to the first page of the site, which makes him/her switch back to IE in
> frustration.  :-)

...and quoting mpt from bug 51940:

> With accesskey, because the contents of the page is out of your control, you 
> cannot be sure that you will produce the desired result if:
> (1) you will produce the expected result if there is a menu in the browser
>     with the same accesskey as the link/button
> (2) there is more than one item in the page with the same accesskey.
> 
> That's why activating an accesskey should give focus to the accesskeyed item
> (and if there are more than one with the same accesskey, cycle between them),
> *not* activate it -- so the user can confirm or change the action before it
> happens.


STEPS TO REPRODUCE

1) View the URL
2) Press Alt-Z


ACTUAL RESULTS

The link is directly activated, eg. you're taken to Netcenter.


EXPECTED RESULTS

Possible solutions:

1) Any access keys only give focus on the element without activating it.

2) Access keys associated with the following elements only give focus on the
   element without activating it:
     <a>, <area>, <button>, <input type="submit|reset|image|button">
   Access keys on any other elements activate the element.

3) There's one or more preferences under "Advanced" for the desired behaviour.
   Might be something like this:

   | Access keys on links and buttons
   |   (*) give focus on the link or button
   |   ( ) follow the link / "push" the button
   |
   | Access keys on other elements
   |   ( ) give focus on the element
   |   (*) activate the element (eg. check/uncheck a checkbox)

   ...or, lose the first preference (make it permanently set on "give focus")
   and only show a single preference:

   | Access keys
   |   (*) activate the element (eg. check/uncheck a checkbox)
   |   ( ) give focus on the element
   |
   | Note: This setting doesn't affect links and buttons. They're never
   | directly activated by access keys, but only given focus.


Solution 1) is the most consistent and probably the easiest to implement.  It 
does take out some of the usefulness of access keys, though, by always requiring 
two keystrokes in order to carry out an action.

Solution 2) might be a good compromise.  IE5/Windows is doing something very 
similar to this.  There is some inconsistency, however, because some elements 
are directly activated on while others aren't.

Solution 3) is great for power users.  For example: users who never use 
application menu shortcuts could select the appropriate options to speed up 
their actions.  Then again, this solution would contribute to Preferences Bloat.

Personally, I'd vote for 2) and/or 3) - but even 1) is a lot better than the 
current situation, which causes serious accessibility problems.

(Another solution would be to have another key combination - such as 
Alt-Shift-accesskey - for document-specified access keys, but that would be 
quite unintuitive and inconsistent with legacy apps.)


BUILD DATE & PLATFORM

Last tested on 2000-10-01-08 (Win32)


ADDITIONAL BUILDS & PLATFORMS

AFAIK, this is an All/All bug, though the access key modifier varies across 
platforms.

Comment 1

[Matthew T (active 1999-2002)]

I vote for solution 1. It's more consistent across element types, and doesn't 
hold the risk of very expensive mistakes (1-click shopping, anyone?) if someone 
has been fiddling with your prefs.

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Argh, hidden, sometimes difficult to spot unwanted behaviour that could actually 
be serious (see comment on 2000-10-03 15:39). Nominating for RTM.

Comment 3

[Antti Näyhä]

Solution 1 has one more advantage brought out by mpt at bug 51940:

> (2) there is more than one item in the page with the same accesskey.
>
> That's why activating an accesskey should give focus to the accesskeyed item
> (and if there are more than one with the same accesskey, cycle between them),
> *not* activate it -- so the user can confirm or change the action before it
> happens.

Given this, I'm starting to lean towards solution 1 as well.  Updating summary 
to reflect that.

Comment 4

[Loco]

I vote for consistency-Solution 1 with the possible later implementation of 3.

Comment 5

[Nisheeth Ranjan]

Marking rtm-.  Not high enough priority given joki's other bugs.

Comment 6

[joki (gone)]

I see your point though the particular spoofing attack you speak of will still 
remain if that was the page's goal.  They could simply have a pixel sized link 
visible on the page with an onfocus handler that caused the same activation as 
the link would have.

The IE5 solution is a bit odd in that, as you point out, its inconsistent.  Some 
things focus, some things activate.  I guess I'd lean towards a focus only 
solution myself if we have to pick one.

Comment 7

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 8

[joki (gone)]

Setting milestone.

Comment 9

[wyrdR]

A 4th SOLUTION?

I think that solution 1) should be implimented as a quick fix, with solution 3) implimented at a later time.

Suggestion 4)

Perhaps Access Key activates by default, the exception being where there is a duplicate in the File Menu or another Element shares the same Access Key.  In this case it toggles focus between each element or Menu option.

CLASHES WITH USER AGENT SHORTCUTS
ALT+F gives focus to the Link in the Document in the first instance, then the File Menu if clicked again.  NB: If the user really needs to get to the File Menu first, they can still press ALT, release, then press F.  (Most important functions of each menu have their own CTRL shortcuts anyway - so the page author's intent for access keys should be given preference).

UNIQUE ACCESS KEYS
If an element is selected by Access Key 'D' (ALT+D), and no other Element or User Agent Function is accessed by ALT+D, it simply activates it.  In the even of an unlikely accidental click, the user can always click BACK.  Given that existing shortcuts already take the user to another page, it is not like this is something new (eg - a user who accidentally presses ALT + leftarrow ends up at the previous page).

SHARED ACCESS KEYS
An example of how this this might be useful: To allow the user to scroll between related CheckBoxes - by setting the same Access Key for all, the user can give focus to then select/deselect as they choose.  (I don't think this does anything useful now...) Alternatively, for some elements, like Checkboxes, it could toggle the current state, move to the next element with the same access key and toggle that, and so on... 

* Combined with Shift, it could be made to move backwards in much the same way as Shift + Tab works.  So ALT + L might move forward between the textboxes, and SHIFT + ALT + L moves backwards.

Comment 10

[Loco]

From above:
"(Most important functions of each menu have their own CTRL shortcuts anyway - 
so the page author's intent for access keys should be given preference)."

I ca't in good conscience agree with this.  The browser is for the *user* and 
NOT for the author of the page.  I can see a scenario where you go to one page 
and Ctrl-D does one thing, so you learn that behavior and expect it, then you go 
to another page and Ctrl-D does something entirely different-is it a bug?  Is it 
a feature?  Did I do something wrong?  Do I need to restart my browser?  What is 
my purpose in life?

Aside from that, I can't see it being easy to check what the application is 
doing (i.e. what Ctrl-[x] combinations are taken up in the particular 
application) especially if the engine will be used in embedding.  Is there an 
easy way to check this with a current application?  If so, then this comment is 
moot-but if this engine will be embedded in a different app, then guessing is 
the wrong way to go as it will probably be hard.  Assuming that the Ctrl-[x] 
combinations will be the same elsewhere as on Moz will be even worse...

Comment 11

[wyrdR]

In reference to my "SHARED ACCESS KEYS" - I just found out that this is exactly
how MSIE works in this situation.  Try it...

As far as remapping keys, this is how it is right now, and in MSIE.  However,
the ALT+F DOES fail to activate the File Menu if an element has F as its
accesskey.  (Surely whatever MS can do, Mozilla can do better!) :)

IMHO - If the File Menu is given priority, the user may never notice the access
key functionality of the web page.  It is kind of like giving CSS priority to
the User Agent and not the Document CSS.  You will never notice it is customised
unless there is no conflict with the existing configuration.

I wholly agree it is important that users should be able to overide this if they
choose, so an option in preferences should exist to specify which takes
precendence (for instance, by giving the User specified CSS priority).

Another possibility is to allow a user controlled setting which will prompt the
user the first time they use an access key on a particular page, if and only if
it conflicts with an existing shortcut.  Something like:

===
This document contains an access key which is in conflict with Mozilla's default
access keys - Overide for this document?

[ ] Yes [ ] No [ ] Always for this site [ ] Never for this site [ ] Apply this
for all documents [ ] Never ask me this again
===

(The Universal version of this would also appear in the preferences)

Access Keys are about making it easy for users, particularly those who might
rely on keyboard shortcuts due to disabilities.  If it is about making things
easy for the user, the user should have the ultimate say, but it is up to the
author to give them the option of shortcut keys.  In fact, I first found out
about Access Keys in HTML reading a document on making it easier for users with
special needs.

Anyway, I still figure that out of the initial suggestions put forth, solution 3
was the best solution.  I just thought my suggestions might help enhance that
solution.

Having already enabled customizable CSS, it would be cool if Mozilla also led
the way for accessibility options as well! =)

Comment 12

[wyrdR]

[ REPOSTING IT WITH WRAP TO MAKE IT READABLE!
- I was using a browser that seems not to understand the Textarea-Wrap attribute
- is it possible to replace the previous instance of this comment?  ]

A 4th SOLUTION?

I think that solution 1) should be implimented as a quick fix, with solution 3)
implimented at a later time.

Suggestion 4)

Perhaps Access Key activates by default, the exception being where there is a
duplicate in the File Menu or another Element shares the same Access Key.  In
this case it toggles focus between each element or Menu option.

CLASHES WITH USER AGENT SHORTCUTS
ALT+F gives focus to the Link in the Document in the first instance, then the
File Menu if clicked again.  NB: If the user really needs to get to the File
Menu first, they can still press ALT, release, then press F.  (Most important
functions of each menu have their own CTRL shortcuts anyway - so the page
author's intent for access keys should be given preference).

UNIQUE ACCESS KEYS
If an element is selected by Access Key 'D' (ALT+D), and no other Element or
User Agent Function is accessed by ALT+D, it simply activates it.  In the even
of an unlikely accidental click, the user can always click BACK.  Given that
existing shortcuts already take the user to another page, it is not like this is
something new (eg - a user who accidentally presses ALT + leftarrow ends up at
the previous page).

SHARED ACCESS KEYS
An example of how this this might be useful: To allow the user to scroll between
related CheckBoxes - by setting the same Access Key for all, the user can give
focus to then select/deselect as they choose.  (I don't think this does anything
useful now...) Alternatively, for some elements, like Checkboxes, it could
toggle the current state, move to the next element with the same access key and
toggle that, and so on...

* Combined with Shift, it could be made to move backwards in much the same way
as Shift + Tab works.  So ALT + L might move forward between the textboxes, and
SHIFT + ALT + L moves backwards.

Comment 13

[joki (gone)]

Okay, here's the patch, which I'll explain the reasoning behind after I get this 
in.

Index: src/nsEventStateManager.cpp
===================================================================
RCS file: /cvsroot/mozilla/content/events/src/nsEventStateManager.cpp,v
retrieving revision 1.269
diff -r1.269 nsEventStateManager.cpp
739,750c739,759
<             //B) Click on it.
<             nsEventStatus status = nsEventStatus_eIgnore;
<             nsMouseEvent event;
<             event.eventStructType = NS_MOUSE_EVENT;
<             event.message = NS_MOUSE_LEFT_CLICK;
<             event.isShift = PR_FALSE;
<             event.isControl = PR_FALSE;
<             event.isAlt = PR_FALSE;
<             event.isMeta = PR_FALSE;
<             event.clickCount = 0;
<             event.widget = nsnull;
<             content->HandleDOMEvent(mPresContext, &event, nsnull, NS_EVENT_FLA
G_INIT, &status);
---
>             nsresult rv = getPrefService();
>             PRBool activate = PR_TRUE;
>
>             if (NS_SUCCEEDED(rv)) {
>               mPrefService->GetBoolPref("accessibility.accesskeycausesactivati
on", &activate);
>             }
>
>             if (activate) {
>               //B) Click on it if the users prefs indicate to do so.
>               nsEventStatus status = nsEventStatus_eIgnore;
>               nsMouseEvent event;
>               event.eventStructType = NS_MOUSE_EVENT;
>               event.message = NS_MOUSE_LEFT_CLICK;
>               event.isShift = PR_FALSE;
>               event.isControl = PR_FALSE;
>               event.isAlt = PR_FALSE;
>               event.isMeta = PR_FALSE;
>               event.clickCount = 0;
>               event.widget = nsnull;
>               content->HandleDOMEvent(mPresContext, &event, nsnull, NS_EVENT_F
LAG_INIT, &status);
>             }

Index: all.js
===================================================================
RCS file: /cvsroot/mozilla/modules/libpref/src/init/all.js,v
retrieving revision 3.235
diff -r3.235 all.js
85a86
> pref("accessibility.accesskeycausesactivation", true);

Comment 14

[Johnny Stenback (:jst)]

sr=jst

Comment 15

[Eric Pollmann]

r=[e-mail], looks good!

Comment 16

[joki (gone)]

So after a lot of discussion with accessibility and an email discussion on the 
W3C WAI mailing list we've decided to continue to activate based on accesskey.  
The discussion included pro and cons for both but the predominant view seems to 
be that accesskey, from an accessibility standpoint, is generally intended to 
cause activation.  For cases where the user is handicapped generally fewer 
keystrokes is better due to difficulty in both choice of keystrokes and 
accuracy of activation.  From the standpoint of dialog design the generally 
acknowledged behavior also tends to include activation.

The main two arguments against activation from this bug seem to be user 
confusion and malicious redirection.  Malicious redirection isn't really valid 
since the author could simply cause activation himself inside an onfocus handler 
which would still be triggered.  The argument of user confusion is valid but the 
discussion seemed to indicate that activation was still the more common and 
intended behavior.

However, as a step towards allowing user control over this I did add a pref to 
enable or disable activation by accesskey.  The pref is 
"accessibility.accesskeycausesactivation".  It has a default value of true but 
setting it to false will stop activation by accesskeys.  It is not currently 
exposed in the UI but there are a number of recent accessibility pref additions 
and hopefully this can be exposed in the UI at some point.

Comment 17

[danielmc]

We are UI frozen for commercial beta now, So any UI changes should be in 0.9.2

Comment 18

[Matthew T (active 1999-2002)]

joki, if you're not going to fix this bug as reported, please don't mark it as 
fixed, or you'll cause confusion amongst people experiencing the problem and 
looking for it in Bugzilla. Thanks.

> the predominant view seems to be that accesskey, from an accessibility
> standpoint, is generally intended to cause activation.

joki, I don't know if you saw the discussion yourself, or if you're just 
relying on Aaron's report of it -- if the latter, please read it yourself at
<http://lists.w3.org/Archives/Public/w3c-wai-ig/2001AprJun/thread.html> (under 
`Should accesskey focus or activate?'). Of the 12 people who responded, two 
thought we should focus the element, two thought we should activate the 
element, two thought we should have two different types of accesskey, one 
thought we should do a usability test, one thought we should `follow 
standards', one said (or seemed to say) we should do whichever was most 
dangerous, one thought it should depend on whether or not the ACCESSKEYed 
element had `child elements', one thought it should be customizable but didn't 
suggest a default, and three were ambivalent. I respectfully suggest that a 
predominant view was not to be found in that discussion.

Oh, and zero people addressed the issue of clashes between permanent chrome 
accesskeys and per-page content accesskeys, and the possible dataloss/
privacyloss/oneclickshoppingmoneyloss/whatever problems that would result from 
such clashes. That issue appears to have been overlooked entirely.

> However, as a step towards allowing user control over this I did add a pref
> to enable or disable activation by accesskey.

Putting aside the impossibility of presenting an understandable UI for this 
pref, I think this is an example of what I call the `checkbox fallacy'. The 
problem isn't that *some* keyboard users are going to be hurt by this bug *all* 
of the time, which a checkbox would fix; it's that *all* keyboard users are 
going to be hurt by this bug *some* of the time, which a checkbox won't fix 
(unless everyone always has the checkbox unchecked, in which case there's no 
point in the checkbox existing in the first place).

> Malicious redirection isn't really valid since the author could simply cause
> activation himself inside an onfocus handler which would still be triggered.

If Web pages are able to use an onfocus handler, that is a different 
accessibility bug which should be handled separately from this one. Let's not 
make this bug more complex than it is already. :-)

Comment 19

[Matthew T (active 1999-2002)]

Resolving as wontfix based on 2001-05-22 comments. joki, please reopen if you 
change your mind about this.

Comment 20

[Ben Bucksch (:BenB)]

joki, thanks for implementing the pref.

5th possible solution (the one I would prefer for me personally): Use a more
strange accesskey-combo that won't be used by the browser.

Comment 21

[Madhur Bhatia]

QA contact updated