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?
(Resummarizing since highlighting is already covered by ye olde bug 56701.)
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.
(If you disagree with what I'm saying, please mark the bug wontfix, don't morph it into something totally different.)
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".
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.
(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?
Why is dropping the feature entirely acceptable when making it slightly slower to use is not acceptable?
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.)
*** Bug 330400 has been marked as a duplicate of this bug. ***
(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).
(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).
*** Bug 332795 has been marked as a duplicate of this bug. ***
I'd rather WONTFIX this bug in favor of bug 340902 (using the hardly used Alt/Ctrl+Shift modifier combination for content accesskeys).
Here are a few URLs that uses accesskeys systematically. http://www.robodesign.ro/site/index.php http://www.pixl8.co.uk/index.cfm/pcms/site.home/ http://www.nhm.ac.uk/index.html http://www.northyorks.gov.uk/public/site/NYCC/menuitem.1df599f14619e9412ff8911040008a0c http://www.micatholicconference.org/
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.
I didn't understand the distinction between content accesskeys and html accesskeys (and general accesskeys?). My apologies for the tangential add.
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 188.8.131.52 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.
That doesn't belong in this bug. It should probably be filed as its own bug unless there's an appropriate one already.
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 184.108.40.206? 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.
This would be the best way to solve bug 359638 comment 59.
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.