Open Bug 1194528 Opened 10 years ago Updated 6 months ago

Access keys appear not to work in settings (about:preferences) because they require content accesskey modifiers (ie alt-shift instead of alt-, on Windows, ctrl-alt instead of ctrl on macOS)

Categories

(Firefox :: Settings UI, defect, P3)

Desktop
All
defect

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.
Ian Zimmerman tells me this works with Alt+shift+letter, which I can confirm, but shift wasn't required in the previous preferences dialog.
pref("ui.key.chromeAccess", 4); // Alt pref("ui.key.contentAccess", 5); // Alt+Shift (or Ctrl and Ctrl+Alt on the Mac)
No longer blocks: 1271779
Summary: Keyboard shortcuts don't work in In-content preferences → Access keys appear not to work in In-content preferences because they require content access key modifiers (ie alt-shift instead of alt-, on Windows, ctrl-alt instead of ctrl on OSX))
Sounds like this is still a problem in current versions from the duplicate bug 1336141. I will mention the workaround in the duplicate.
Keywords: ux-consistency
Severity: normal → S3
OS: Unspecified → All
Priority: -- → P3
Hardware: Unspecified → Desktop
Summary: Access keys appear not to work in In-content preferences because they require content access key modifiers (ie alt-shift instead of alt-, on Windows, ctrl-alt instead of ctrl on OSX)) → 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)
Version: 38 Branch → Trunk

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.

Flags: needinfo?(jaws)

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.

Flags: needinfo?(jaws)

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.

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

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.

Consider updating the the title so this issue is better searchable: I nearly submitted new dupe "No alt-key accesskey accelerator works in about:preferences" (I hope these keywords will help).

(And +1 (voted), obviously; seeing underlined letters in labels and not being able to Alt+them is frustrating. Glad I've learned about the …+Shift workafix.)

Summary: 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) → Access keys appear not to work in settings (about:preferences) because they require content accesskey modifiers (ie alt-shift instead of alt-, on Windows, ctrl-alt instead of ctrl on macOS)
You need to log in before you can comment on or make changes to this bug.