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).

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.

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.

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)

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.)

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.

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?

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?

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.

(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?

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.

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".

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.

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?

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".

(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?

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.)

(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).

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?

> 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.

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?

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.

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.

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.

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.