Open Bug 1194528 Opened 9 years ago Updated 2 years ago

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)

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.

You need to log in before you can comment on or make changes to this bug.