Access keys appear not to work in in-content settings because they require content access key modifiers (ie alt-shift instead of alt-, on Windows, ctrl-alt instead of ctrl on macOS)
Categories
(Firefox :: Settings UI, defect, P3)
Tracking
()
People
(Reporter: glandium, Unassigned)
References
Details
(Keywords: ux-consistency)
STR: - Open preferences - Use, for example, the alt-v shortcut (Linux here) Expected Result: - Jumping to the "Save files to" field Actual Result: - "View" menu opened. Even shortcuts without (obvious) conflicts with the menu bar or other things don't do anything.
Reporter | ||
Comment 1•9 years ago
|
||
Ian Zimmerman tells me this works with Alt+shift+letter, which I can confirm, but shift wasn't required in the previous preferences dialog.
Comment 2•9 years ago
|
||
pref("ui.key.chromeAccess", 4); // Alt pref("ui.key.contentAccess", 5); // Alt+Shift (or Ctrl and Ctrl+Alt on the Mac)
Updated•7 years ago
|
Comment 5•7 years ago
|
||
Sounds like this is still a problem in current versions from the duplicate bug 1336141. I will mention the workaround in the duplicate.
Updated•2 years ago
|
Comment 9•2 years ago
|
||
The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates.
:jaws, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Comment 10•2 years ago
|
||
It's not particularly clear how to fix this in a way that wouldn't be confusing, because the in-content shortcuts could conflict with parent browser window ones (e.g. alt-t, alt-f, alt-v, alt-e, alt-s and alt-h are all unavailable on English windows/linux). It's also unclear that this is still a pressing issue with the functioning search box.
Comment 11•2 years ago
|
||
I'd say it is still an issue since the settings window still shows underlined characters. It advertises this well-known accessibility feature but it doesn't actually work the way that everyone expects it to. The only reason I know that I have to hit ctrl-shift-char is because of this bug tracker. I would have never guessed that on my own since there is no indication that I have to do anything different.
Comment 12•2 years ago
|
||
(In reply to JT Hundley from comment #11)
I'd say it is still an issue since the settings window still shows underlined characters.
So to be clear, I don't disagree - if I thought this wasn't an issue I would have closed the report entirely. My point was specifically that it wasn't pressing - ie not a "stop everything, must fix this immediately" issue, because various workarounds exist, and I would argue more people know how to use that searchbox than know how to use access keys.
I'm open to good ideas - I'm just honestly not sure what we should do here. Removing the accesskeys altogether would be a loss of functionality, but I suppose would solve some of the confusion... Not showing the access keys underlined like this but keeping the functionality would be band-aidy at best and confusing for users who accidentally press the right key combinations at worst.
It would be pretty confusing to most users to try to show a message telling them how to use these keys (and anyway that's not a "real" fix, it only works around the crux of the issue - "this software is confusing, let's try to un-confuse you").
And "just" using the "normal" access key modifiers isn't a straightforward solution either (neither technically nor in terms of ease of use - it would perhaps also cause significant localization churn as I expect we'd want localizers to re-evaluate the access keys they've specified so far).
So it's not clear to me how to move forward here.
Comment 13•2 years ago
|
||
Agreed 100%. The best thing to do of course would be to make regular alt-char accelerator keys work in that menu, but it sounds like that's much more difficult than it sounds.
Description
•