Last Comment Bug 303192 - HTML accesskeys should require key combination (and show overlaid visual indicator in the middle)
: HTML accesskeys should require key combination (and show overlaid visual indi...
Status: NEW
: access
Product: Core
Classification: Components
Component: Keyboard: Navigation (show other bugs)
: Trunk
: x86 Linux
: -- major with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 330400 332795 395203 (view as bug list)
Depends on: 824478 728103
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-02 22:58 PDT by David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
Modified: 2013-03-15 08:12 PDT (History)
18 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-08-02 22:58:39 PDT
I think our HTML accesskey implementation is generally harmful to keyboard
accessibility.  (Not that any other browsers do it better.)  The most serious
problem is that accesskeys allow the Web page to take over the application-level
shortcuts typically used to access the menubar, which breaks user expectations
and muscle memory and can lead to erroneous and unintentional input into form
controls.  A secondary problem is that there is no visual indication of the
presence of accesskeys, which means they are unlikely to be discovered except
when *unintended*.

Both of these problems could be solved by making accesskeys require a series of
keystrokes.  In particular, the way I think it should work is roughly the following.

Current behavior:
  Currently, the accesskey "Z" is triggered when the user presses Alt+Z.
  Gecko does not add any visual indication of the presence of the accesskey.

Proposed behavior:
  The accesskey "Z" should be triggered by the sequence Ctrl+K, Z.  (I'm
  using Ctrl+K because it's obvious.  Firefox already uses it for the
  search box, but maybe we could get it back.  But if other sensible keys
  are available that would be great.)
  Furthermore, when Ctrl+K is pressed, we should display a visual indication
  of what accesskeys are present by showing each accesskey letter at the
  position of the control that it activates (perhaps with the letter on a
  circular or square background, the whole thing at some opacity).
Comment 1 Mike Beltzner [:beltzner, not reading bugmail] 2005-08-02 23:24:25 PDT
The whole point of HTML accesskeys, as I understood it, was to provide speedy
keyboard access to web-app features using familiar shortcuts. Putting a "get
into web app accesskey mode" step in there seems to pretty much defeat the
purpose, and make accesskeys somewhat irrelevant. (Also, on platforms like Mac
where HTML accesskeys are obtained through CTRL instead of ALT, this would be an
unneccessary step)

Your points are all valid, but I'd prefer trying to find a solution  one where
we only make this an issue for the user in cases where accesskeys conflict, and
further one where we try and keep that set of conflicts to a minimum. The former
can perhaps be handled with some sort of visual indication of the conflict
(maybe a transparent overlay) and a mechanism for resolving it (maybe pressing
ALT+ALT+acesskey for the HTML one, if we think the OS level ones should take
precedence?) The latter should be handled by making it clear to web developers
which accesskeys the browser needs, and which they shouldn't override.
Comment 2 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-08-02 23:30:23 PDT
The accesskeys the browser needs vary by localization and by browser, so it's
effectively all of them.

I sure hope we've given up on the idea that a Web app should be
indistinguishable from a native app.  It's a security nightmare, and I think a
usability nightmare as well.
Comment 3 Mike Beltzner [:beltzner, not reading bugmail] 2005-08-02 23:42:30 PDT
Indistinguishable, no, but that doesn't mean that we should throw up barriers
that make web apps less functional in terms of UI than native apps.

What about using an additional modifier, instead of a sequence? So Alt+Shift for
accesskeys on w32/linux, Ctrl on Mac.

Also: I like the idea of some visual indicator, especially if it's subtle and
just declares the presence of the accesskeys, but then does something clever
like show a list of available accesskeys in a transparent overlay when the user
presses and holds the invoking modifier (i.e.: Alt+Shift)
Comment 4 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-08-02 23:50:06 PDT
Double-modifier combinations tend to duplicate shortcuts in the system, window
manager, etc.  Alt+Shift *might* be acceptable on Windows (I haven't used
Windows much for about 6 years, so I've forgotten many of the shortcuts); I know
that Ctrl+Shift and Ctrl+Alt+Shift aren't, since the user can create global
shortcuts using them.  There's probably still too much variation in the X11
world to pick any multiple modifier combination, although I could be wrong. 
(GNOME defaults on FC3 include one Ctrl+Alt combination.)
Comment 5 Mike Beltzner [:beltzner, not reading bugmail] 2005-08-03 00:10:08 PDT
FWIW, after some quick testing it seems that Alt+Shift == Alt on XP.

I note that the HTML 4.0 spec is pretty light on recommendng ways for browsers
to invoke accesskeys, other than to say that they should just use the default OS
mechanism.

Comment 6 Aaron Leventhal 2005-08-03 03:09:24 PDT
I think Alt+shift is acceptable on Windows and Linux, for content accesskeys,
would be acceptable. This was discussed in another bug and the reaction was good.

David, is this something you want to propose for Firefox 1.5 because of security?
Comment 7 Aaron Leventhal 2005-08-03 03:12:35 PDT
David, the highlight HTML accesskeys is bug 56701. It is a tough layout problem.
I proposed a number of patches when I fixed XUL checkbox and radio button
accesskey highlighting that also fixed bug 56701 but those attempts were
rejecting as changing too much of layout. Want to take a look at that problem?
Comment 8 timeless 2005-08-03 08:49:39 PDT
alt-shift is something that windows shortcut keys use (open a properties for a 
shortcut, click the shortcut key field, press and hold shift-alt, note the key 
field changes to "Shift + Alt + ").

shift alone would be fine with me, and for the time being, how about we just 
fix the code to allow shift [i filed this bug somewhere a long time ago] (don't 
hook it up to be used)? crossing the bridge of actually connecting whatever can 
be done later after the paths are available.
Comment 9 Aaron Leventhal 2005-08-03 08:53:18 PDT
(In reply to comment #8)
> alt-shift is something that windows shortcut keys use (open a properties for a 
> shortcut, click the shortcut key field, press and hold shift-alt, note the key 
> field changes to "Shift + Alt + ").
You can put any hotkey there. In that case we shouldn't use Ctrl+shift either.

> shift alone would be fine with me, and for the time being, how about we just 
> fix the code to allow shift [i filed this bug somewhere a long time ago] (don't 
> hook it up to be used)? crossing the bridge of actually connecting whatever can 
> be done later after the paths are available.
That's too confusing. What if you have a <select> <input type="text"> or
<textarea> focused?
Comment 10 Matthew Paul Thomas 2005-08-03 10:11:04 PDT
(Resummarizing since highlighting is already covered by ye olde bug 56701.)
Comment 11 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-08-03 11:40:56 PDT
No, the highlighting this bug is proposing is *very different* from what is
proposed in bug 56701.  Bug 56701 is proposing highlighting that is always
present.  That's hard, and involves messing with the display of the page in very
limited ways.  This bug is proposing an overlay that is present only when the
initial key sequence is pressed.
Comment 12 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-08-03 11:44:13 PDT
(If you disagree with what I'm saying, please mark the bug wontfix, don't morph
it into something totally different.)
Comment 13 Matthew Paul Thomas 2005-08-03 12:06:27 PDT
I don't own the Keyboard Navigation component, so I'm not wontfixing 
anything. But from a usability POV, "highlight access keys too late for it 
to be useful" would be best as a duplicate of "highlight them all the time".
Comment 14 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-08-03 12:21:13 PDT
The power to morph bugs into something completely different and the power to
mark wontfix are essentially equivalent, so marking wontfix for mpt, who seems
to fear the power of the wontfix button, and who seems to agree with the other
commenters.
Comment 15 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-11-14 20:40:46 PST
For what it's worth, the fact that our accesskey key combination conflicts with our own keyboard shortcuts means that pages with accesskeys make the browser itself much less usable.  For example, I can't get to the Edit menu on this very bug page because there's an accesskey for "e" in the page.

mpt, aaronlev, beltzner, since you don't like dbaron's proposal (which is the ONLY one I've seen in a few years now that promises to make accesskeys somehow coexist with our own UI), what are your suggestions for making this suck a little less?
Comment 16 Matthew Paul Thomas 2005-11-16 18:47:07 PST
As far as I know, every non-Mac browser has become less usable in direct proportion to the degree it has tried to make accesskey= usable. A page containing accesskey="d" breaks Alt+D's normal function in Windows Internet Explorer and Firefox identically; Opera solves this problem using Shift+Escape, but at the expense of making accesskey= much slower to use. My best ideas for making accesskey= usable on non-Mac platforms have been described for the past five years in bug 51940 comment 4 and bug 56701, but if they are not enough (which wouldn't surprise me, since they don't solve the Alt+D problem), my next suggestion is to drop support for accesskey=. I don't think there should be any shame in saying "sorry, the W3C specced it, and we tried it, but it just wasn't practical".
Comment 17 Boris Zbarsky [:bz] (Out June 25-July 6) 2005-11-16 21:42:27 PST
I think making accesskeys slower to use (which was the suggestion made in this bug) sounds ok to me.  Hence me commenting on this bug.
Comment 18 Mike Beltzner [:beltzner, not reading bugmail] 2006-01-19 02:40:44 PST
(In reply to comment #15)
> mpt, aaronlev, beltzner, since you don't like dbaron's proposal (which is the
> ONLY one I've seen in a few years now that promises to make accesskeys somehow
> coexist with our own UI), what are your suggestions for making this suck a
> little less?

Of all of these, I've kind of liked timeless' simple "use Shift" idea, although it does require that focus isn't in a text input area of the page. Aaronlev, does that truly screw things up from an accesibility perspective?
Comment 19 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2006-01-31 19:24:26 PST
Why is dropping the feature entirely acceptable when making it slightly slower to use is not acceptable?
Comment 20 Matthew Paul Thomas 2006-02-01 07:49:19 PST
Because once something has been made sufficiently slow or non-obvious, the majority of times it is used will be accidents. And unfortunately, I don't think any accesskey modifier or mode exists that would be both fast enough and obvious enough to be used more often intentionally than unintentionally. (Meanwhile, find-as-you-type followed by (Shift+)Tab could be made to perform this function a little more slowly, but much more universally.)
Comment 21 Rahul Abrol 2006-03-14 05:17:00 PST
*** Bug 330400 has been marked as a duplicate of this bug. ***
Comment 22 Rahul Abrol 2006-03-14 05:34:44 PST
(In reply to comment #16)
> As far as I know, every non-Mac browser has become less usable in direct
> proportion to the degree it has tried to make accesskey= usable.

the mac is no exception here; accesskeys still override emacs keybindings.

> Opera solves this problem using Shift+Escape,
> but at the expense of making accesskey= much slower to use. 

not really, since Shift+Escape can be changed to anything else via keyboard customization.  e.g. [ctrl-space, key] seems to me to be just as good as [ctrl-mod2+key] (s/ctrl/alt/g for windows/GliNUx).
Comment 23 Simon Bünzli 2006-06-22 10:56:26 PDT
(In reply to comment #5)
> FWIW, after some quick testing it seems that Alt+Shift == Alt on XP.

That's due to a limitation in our accesskey handling code which could quite easily be fixed (see the attachments to bug 340902 and attachment 226623 [details] [diff] [review] to bug 128452).
Comment 24 Aaron Leventhal 2006-06-29 17:31:39 PDT
*** Bug 332795 has been marked as a duplicate of this bug. ***
Comment 25 Simon Bünzli 2006-07-08 09:45:59 PDT
I'd rather WONTFIX this bug in favor of bug 340902 (using the hardly used Alt/Ctrl+Shift modifier combination for content accesskeys).
Comment 27 Mats Palmgren (:mats) 2006-10-28 21:40:33 PDT
I have a WIP that implements this. It traverses the document collecting
elements that has an 'accesskey' attribute and builds a popup-menu from that.
The menu items get the same accesskey, so you can just type the key without
modifiers to activate it. If the element has a 'title' attribute then
that is added to the label too. It's very much like the menu in Opera 9
that you get with Shift+Esc.  Here's a screenshot:
http://img221.imageshack.us/my.php?image=303192vd0.png

Comments?
Comment 28 Krishna Sethuraman 2007-01-05 12:19:26 PST
> Furthermore, when Ctrl+K is pressed, we should display a visual indication
> of what accesskeys are present by showing each accesskey letter at the
> position of the control that it activates (perhaps with the letter on a
> circular or square background, the whole thing at some opacity).

Konqueror implements this, IMHO, perfectly.  Tap Ctrl to display the accesskeys, then strike the desired accesskey.  In addition, it assigns unassigned accesskeys dynamically to other controls on a first-seen-first-served basis.  This way:

* The web site can assign accesskeys to the most common links/controls, and
  konqueror can fill in some of the rest (up to the rest of the unassigned
  [a-z0-9] bindings).
* No chording needed (which seems disabled-friendly)
* Completely avoids the conflict with existing key combinations.
* Works so well for me that that I fall back on it when konqueror's
  find-as-you-type (which works excellently in Firefox and Opera) is flaky.
* Also works well enough that I can usually navigate 'prev' and 'next'
  links, even when those haven't been assigned 'link' attributes or
  accesskeys.  Opera has bindings for 'prev' and 'next', firefox has
  'linktoolbar'; konqueror doesn't have these, but its accesskey
  implementation is usually good enough to use instead. 
* See also http://bugs.kde.org/show_bug.cgi?id=123319 for something it
  could implement to make it even better.
Comment 29 Krishna Sethuraman 2007-01-05 12:20:45 PST
I didn't understand the distinction between content accesskeys and html accesskeys (and general accesskeys?).  My apologies for the tangential add.
Comment 30 Rimas Kudelis 2007-02-20 09:56:10 PST
Krishna: Content accesskeys == HTML accesskeys. General accesskeys are those that Firefox itself uses (like Ctrl+F for find, Alt+F for File menu etc.)

I quite like Mats' approach shown in comment #27. It's still way slower than Alt+Shift+Something, but way better than nothing. Ant it would work in ALL cases independently of keyboard layout and other factors. Maybe it could find its way into the interface, after some retouching (e.g., try to underline an existing capital letter first, then small letter, and only in case both are absent, state the accesskey letter explicitly). Maybe this could become a submenu of the context menu, or a separate item in main menu?
Comment 31 jra 2007-11-02 06:44:40 PDT
Well, since this bug is showing NEW, even though it's 2 years old, I assume *it* is not the bug which engendered the 2.0.0.9 release notes entry:

HTML Access Keys now require Shift-Alt

?

I'm one of the people who, while understanding perfectly well what the implications might be of allowing HTML "apps" to override browser-default hotkeys, also believes that the whole point of HTML apps is that you have to be able to make them work like traditional local apps, or the training hill is too hard to get people over.

So *which* application of the Principle of Least Astonishment is the more important one not to screw with?  Well, I'd say that's the domain of the person who installed the browser.

Can we at least get an about:config knob to return to the old Alt- behaviour, at the users option?  Best would be a list of sites for which it works that way, I suspect, but that's an even bigger implement.
Comment 32 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-11-02 11:01:10 PDT
That doesn't belong in this bug.  It should probably be filed as its own bug unless there's an appropriate one already.
Comment 33 jra 2007-11-02 14:32:32 PDT
Ok.  I put a thinko in my opening sentence.  So I can't bitch about that reply.  I'll try again, though:

Is *this* the bug which caused that change in 2.0.0.9?

If not, can anyone more effectively than I identify which bug it *was* so I know where to comment?

I've already commented to Hendrix that the release notes should include bug numbers.  I'll comment to you that your response is a bit sharper than is strictly necessary.  I *opened* with "where should i put this?"; I really did.

Even if I can't type.
Comment 34 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-11-02 20:15:58 PDT
I don't know the answer to "where should I put this?" but the answer is definitely NOT here.  Please don't add further comments to this bug, as it just makes this bug more confusing and less likely to be fixed.
Comment 35 jra 2007-11-02 21:25:28 PDT
The question wasn't "where should I put this".  

Clearly, I'm not going to get an answer to the actual question, even from someone who appears a) to be a developer b) in the area of the issue I care about, so c) I'm off the CC list, and you have a nice day.
Comment 36 Simon Bünzli 2008-01-13 14:43:22 PST
*** Bug 395203 has been marked as a duplicate of this bug. ***
Comment 37 Karl Tomlinson (ni?:karlt) 2008-05-12 15:19:24 PDT
This would be the best way to solve bug 359638 comment 59.
Comment 38 Michael Zajac 2009-02-25 12:42:16 PST
FYI: Safari 4 beta just came out, and it has changed the accesskeys meta from ctrl+ to ctrl+opt+ (that's ctrl+alt+ to some), to reduce OS keyboard shortcut conflicts.

Note You need to log in before you can comment on or make changes to this bug.