728103 - Shouldn't we change modifier for HTML accesskey from Control to Control + Option?

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch

I'd like to suggest that we should change the modifier for HTML contents on Mac, from Control to Control+Option.

The most serious problem of the current modifier key (only Control) is, Control+Something is used by emacs like keyboard shortcuts on Mac. They are important for a11y and useability of Mac users because they're the "native behavior" of Mac platform.

Nowadays, WebKit browsers (Safari and Google Chrome) use Control+Option for content accesskeys on Mac. I think that it's safe for all Mac users because Control+Option shouldn't be used for other global shortcut keys due to used by Safari.

Bug 303192 discussed about new solution for avoiding all problems on current content accesskey related issues. However, I think that for improving Mac users' experience, we should fix the conflict between emacs like keyboard shortcuts and our HTML content accesskeys quickly.

Any idea? (I'm not sure who should be CCed from UI team)

# Note that I don't want to discuss the ideal solution for content accesskey in this bug. This bug is only for deciding what should I do for now against the keyboard shortcut conflict issues.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.1 Change modifier for HTML accesskey from Control to Control + Option

I think the merits of this change:

* Never conflicts with Emacs key bindings.
* Improve consistency between Gecko and other browsers, especially Safari which is default browser of Mac.
* Using same key combination with Safari, OS global key bindings shouldn't be conflict in the future.

demerits:

* Our users might be confused by this change. However, I don't think a lot of users use content accesskey.

I'm not sure about the chrome accesskey. Using same accesskey for chrome accesskey might be better. But I don't know whether Mac's chrome is using accesskeys on chrome.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.2 Fix new test failures

fixes new test failures by part.1's change.

Comment 3

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 601536 [details] [diff] [review]
part.1 Change modifier for HTML accesskey from Control to Control + Option

I'm fine with this in principle.  But let's land it early in a release cycle, to give us the best chance to catch (and evaluate) user objections before this gets into a release.

Comment 4

[Alex Limi (:limi) — Firefox UX Team]

Comment on attachment 601536 [details] [diff] [review]
part.1 Change modifier for HTML accesskey from Control to Control + Option

If this is what Safari and Chrome do, we should too.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Thank you. I'll land them after I confirmed all tests passed on tryserver again.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/7f91620584d3
https://hg.mozilla.org/integration/mozilla-inbound/rev/69a0d319fa74

Comment 7

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

https://hg.mozilla.org/mozilla-central/rev/69a0d319fa74
https://hg.mozilla.org/mozilla-central/rev/7f91620584d3

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

FYI:

If you think that chrome's accesskey modifier should be changed, please file a new bug for it and cc me. I'm going to work on it.

If you think that other platforms' accesskey modifier should be changed, please work on them yourself because I guess that they were decided by enough discussions and I think current default settings are better than others.

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I should append some information.
https://developer.mozilla.org/en/HTML/Global_attributes#attr-accesskey

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Added a table which compares the accesskey behavior between each implementation.

Comment 11

[Tantek Çelik]

I'm going to take a wild guess that neither the filer of this bug nor anyone else in the above comments regularly uses web apps with accesskeys - this change makes our UX *worse* in a case where it was actually better than Safari/Chrome. 

Can we please stop blindly copying Safari/Chrome UX?

If there's any chance of getting this reverted, I'd like to see it.

For folks using accesskey UIs in webapps, ctrl-key is *much* easier to hit than the 3 finger coordination required for ctrl-opt-key. Thanks for the consideration.

Comment 12

[Tantek Çelik]

(In reply to Alex Limi (:limi) — Firefox UX Team from comment #4)
> Comment on attachment 601536 [details] [diff] [review]
> part.1 Change modifier for HTML accesskey from Control to Control + Option
> 
> If this is what Safari and Chrome do, we should too.

We should NEVER do something just because Safari and Chrome do it. If we can't independently rationally explain why and how it improves the product, we shouldn't do it.

In this case we actually had a feature that was an *advantage* for Firefox users, namely a much more usable/accessible accesskey feature, and copycatting destroyed that advantage.

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Tantek:

Please read comment 0 for the changing reason. This isn't just copying the WebKit's UX. I believe that the solution is better except the UX you mentioned. Note that on other platforms, content accesskey needs Alt+Shift. So, not only Mac users need to use 3 fingers.

If you want to revert the change on your environment, change the "ui.key.contentAccess" from 6 to 2. Then, the accesskey behaves same as Fx13 or earlier.

Anyway, I think that if we want to provide better accesskey UX, we need to design new UI/behavior like Opera or MS Office for Windows (Ribbon).

Comment 14

[Tantek Çelik]

Masayuki,

The comment 0 reason "The most serious problem of the current modifier key (only Control) is, Control+Something is used by emacs like keyboard shortcuts on Mac." makes no sense.

1. What is the specific user-scenario where a conflict results? Running emacs in a browser? URL? Steps to reproduce?
2. Who here (anyone?) is using that user-scenario, and if no one here, show me a study demonstrating real users encountering real problems or else I call hypothetical problem.
3. I assert than neither you nor anyone else approving this bug actually uses accesskeys on Mac, thus you have recommended a change which makes things worse for a class of people not represented by those pushing for this bug. That's a very bad practice.

regarding: "if we want to provide better accesskey UX, we need to design new UI/behavior" - that's a separate issue.

First, do no harm (as "fixing" this bug has done), improvements can be made later.

Frankly I find this change capricious and without practical merit. (theoretical merit of some sort of keyboard consistency with Safari - only theoretical because in practice, it *hurts* an area we have an advantage on Mac over Safari and Chrome).