i use alt to trigger menus, i'm not alone. bugzilla's pages are driving me nuts. i'd like to be able to use shift instead of alt for web page accesskeys. it's true that i couldn't trigger an accesskey from a form control, but there are a bunch of solutions: f6,f6. tab(sometimes). mouse click. perhaps <escape>. The fact is that when i'm in an edit field, i'm more likely to do alt-f, alt-e, or alt-w than i am to want to jump to some other field, and if i want to jump to a field i can use tab or something else. if a web page has focus, there's very little harm in shift-<key> jumping to a control. <- this is the request

Could we instead support a pref to select the modifier offer alt, shift and Super (the windows key). This bug is a big accessibility problem for gtk+ embedders, because gtk menus always grab accelkeys first, so this feature doesn't work most the time in gtk browsers such as epiphany or galeon. Could someone add the topemebed keyword to this, and change the title to reflect the option of using super?

*** This bug has been marked as a duplicate of 128452 ***

Reopening. The bug is about making Shift usable as an in-page accesskey, which it currently is not. Hence this bug is *not* a dupe of 128452. Steps to reproduce: 1. Set ui.key.generalAccessKey to 16 using about:config 2. Disable typeaheadfind 3. View any bug, and try using Shift as an accesskey

This seems reasonable. Timeless why don't you supply a patch?

aaronl: because i haven't figured out how :)

In Windows the standard is Alt for access keys anywhere in an application. Other apps seem to get by with having access keys in both menus and labels on fields.

(In reply to comment #6) > In Windows the standard is Alt for access keys anywhere in an application. > Other apps seem to get by with having access keys in both menus and labels on > fields. The differences is that applications have a lot more control over what content there is. People are really tired of the current situation on the web. There's no way for a web author to know what accesskeys are being used in the current browser, given all of the language possibilities. Right now the situation is that no one uses accesskeys because they suck. The work around for getting to menu items of pressing alt separately from the letter is awkward and unnatural. I never remember to do that on Bugzilla pages. We should go in a new direction for Windows and Linux and choose Alt+Shift for the default accesskey modifier setting. It doesn't conflict with anything in the browser. People will be free to use the accesskeys in Mozilla and the page without worrying about the conflicts. Alt+shift is not used anywhere in Mozilla so far, I've made sure of that because Mac uses Alt+shift for entering extended characters. However there is no conflict on Win/Lin because Mac will continue to use Control for accesskeys.

(In reply to comment #7) > We should go in a new direction for Windows and Linux and choose Alt+Shift for > the default accesskey modifier setting. No, we shouldn't. That's deviating from the platform standard (speaking only from my Windows experience, Linux may vary). Now I have to remember which application I'm in and whether I'm looking at chrome or content to determine which modifier(s) I need to use to access the field or button indicated with the underlined letter? That doesn't sound very convenient to me. Over in bug 271154 comment 10, bz said just yesterday that we try to be consistent with the platform except in cases where there are serious security considerations. I don't see anything like that here. Changing the default modifier is bad. Providing a way to specifiy what the accesskey modifier(s) is/are is not as bad.

Dean, what I said is that if there are security considerations those override platform consistency. I did NOT say that there are no other considerations that could override platform consistency. Heck, firefox keybindings seem to be just happy not being platform consistent (eg backspace).

> Heck, firefox keybindings seem to be just happy not being platform consistent > (eg backspace). Well, given that the main application on the Windows platform that has a "Go Back" function is IE, I'd say it is being consistent.

Yes, but the backspace thing is being done on _all_ platforms... See the bugs on it and the arguments for platform consistency, happily being ignored...

OK, obviously I'm only speaking from my experience on Windows. I don't have a *nix box these days. Regardless, I don't see the backspace issue as an argument to start throwing platform consistency to the side of the road.

Dean, I'm all for platform consistency but this is an acception. Web browsers need to try to keep the interactive content separate from the browser UI. In HTML accesskey is broken and as a result no one uses it. People hate the way it is now. Let's fix it.

Personally, I like it the way it is, for the reasons I stated before. I really don't think doing this is going to help the acceptance of access keys. I think two of the big problems with their adoption are: 1. Very few people know about them or care about keyboard accessibility; 2. It's not straight-forward to get the access key underlined. Once someone runs into the difficulty in underlining one letter, they may well back off from doing it site-wide.

And I know it's not firm in any spec, but w3c.org does say about the accesskey attribute, 'For instance, on machines running MS Windows, one generally has to press the "alt" key in addition to the access key.'

Yeah it says that, but that's just so readers know what accesskey is. People at the w3c know accesskey implementations are broken. Once a site (such as bugzilla) implements them, it takes over the the keys users use for the application. And it's not hard to show the underline on the letter. It just takes some code to break the letter out into a span, on the page end. Or just use <u> if it's a static page. I think you're the exception in liking it the way it is, let alone understandingthe current situation. Bottom line, most users don't understand why Alt+T no longer brings down the Tools menu.

Comparing IE and Firefox, five of the accesskeys on the menu bar are the same between the two. Yet IE still uses Alt+accesskey because that's consistent with Windows. Sigh. I can see I'm fighting a losing battle to remain consistent with the platform. I like that we battle for consistency until someone doesn't like how it's done on the platform. If you do ignore the platform and change the default, please give at least hidden support so I can change it back to Alt.

(In reply to comment #17) > Comparing IE and Firefox, five of the accesskeys on the menu bar are the same > between the two. Yet IE still uses Alt+accesskey because that's consistent with Windows. That's for English. > > Sigh. I can see I'm fighting a losing battle to remain consistent with the > platform. I like that we battle for consistency until someone doesn't like how > it's done on the platform. There's a balance to be had. > If you do ignore the platform and change the default, please give at least > hidden support so I can change it back to Alt. Of course. I'd also be open to discussing the idea of having alt accesskeys still work when the UI doesn't need them. In other words, the UI could get first grab at them for its mnemonics, as opposed to the situation now. Alt+Shift would guarantee to be for content access. On the down side I think this is a harder rule for users to understand.

(In reply to comment #18) > (In reply to comment #17) > > Comparing IE and Firefox, five of the accesskeys on the menu bar are the same > > between the two. Yet IE still uses Alt+accesskey because that's consistent > with Windows. > That's for English. Exactly. My point was that five out of seven are the same, yet IE still uses Alt. > > Sigh. I can see I'm fighting a losing battle to remain consistent with the > > platform. I like that we battle for consistency until someone doesn't like how > > it's done on the platform. > There's a balance to be had. It's a very subjective balance. :) > Of course. I'd also be open to discussing the idea of having alt accesskeys > still work when the UI doesn't need them. In other words, the UI could get first > grab at them for its mnemonics, as opposed to the situation now. Alt+Shift would > guarantee to be for content access. On the down side I think this is a harder > rule for users to understand. Interesting. What about taking one step back and not implementing Alt+Shift right now? Just have Alt+accesskey always go to the UI first instead of the content? That would be a good start in my opinion, and then we could get feedback as to whether users are frustrated that they can't use an Alt+F access key in content anymore. On a side note: The bugzilla pages ignore me as much as the next guy. Trust me. But I think that's the page's fault and not the browser's menu bar.

> Interesting. What about taking one step back and not implementing Alt+Shift > right now? What would you have against implementing Alt+Shift if we chose that route?

(In reply to comment #20) > > Interesting. What about taking one step back and not implementing Alt+Shift > > right now? > What would you have against implementing Alt+Shift if we chose that route? Good question, and I don't have an answer. That would work for me. That maintains Alt for most access keys, but provides a way of forcing them to work if need be.

I plan to fix this issue in bug 340902. Comments and reviews to plan and code in that bug would be most welcome.

With bug 340902 fixed it is now possible to either set ui.key.generalAccessKey to 12 for Shift or to use Shift in combination with other modifiers for the new prefs ui.key.contentAccess and ui.key.chromeAccess.