Add a preference to allow a custom go to toolbar keyboard shortcut

[priethor]

What problem does this address?

There are a few instances in the block editor where industry-accepted shortcuts conflict with existing editor shortcuts, for example:

• Tabbing to indent items in the List block is a common pattern in software, but shift ⇧ + tab to unindent would conflict with the current keyboard shortcut to go to the current block's toolbar. (see List: allow indenting with Tab  #45404)
• cmd ⌘/Ctrl + k is commonly accepted to launch the equivalent to the editor's command palette, but it conflicts with the shortcut to add/modify links (see Command Palette: Global command shortcut conflicts with existing shortcut #51737)

What is your proposed solution?

Adding a new preference under the accessibility tab allowing a custom go to toolbar keyboard shortcut would help prevent the interference between (un)tabbing to (un)indent in the List block and unblock #59199, as seen in the mockup below created by @ajlende:

Possible improvements:

• Adding a toggle to enable/disable the custom shortcut completely.
• When editing the shortcut, adding buttons to save/cancel the edition, apart from allowing Enter ↵ and Esc to accept and cancel, respectively, following the a11y pattern suggested in the List View inline name editing PR.

This issue is a first step to enabling more custom shortcuts, as described in #3218.

[jasmussen]

My instinct would be to allow customizing virtually any keyboard shortcut, and thus have it live in the existing Keyboard shortcuts modal:

This would be similar to Macos, in the Settings > Keyboard shortcuts section:

The above GIF shows the MacOS shortcuts panel, where you have to double click a particular shortcut to customize it. I feel like we could take a simpler route there, and simply have each shortcut being an input field, so you could just type out your preferred shortcut and press Enter to set it.

[jasmussen]

One challenge that may suggest starting with just a single keyboard shortcut — the most important one, go to toolbar, as you suggest — is that when you have more than one keyboard shortcut you likely need some conflict detection to see whether a chosen shortcut is already in use. That's less of a case when only a single one is customized. So by starting with just this one, we could potentially lay the plumbing for broader customization, address an accessibility concern, and make progress.

It's not clear to me that putting it in "Accessibility" is useful, though; would it make sense to have a "Shortcuts" section if it only contained that one shortcut?

[jasmussen]

Thinking more about this, and in order to land this important piece, and since there would only be a single shortcut in a new "Shortcuts" section to start, the accesibility section does seem the right place to put this after all.

[ajlende]

It's not clear to me that putting it in "Accessibility" is useful, though; would it make sense to have a "Shortcuts" section if it only contained that one shortcut?

I added it to "Accessibility" as we were discussing it in the context of accessibility. It felt a bit weird to have only one of the options editable in the existing modal, and it felt a bit weird to have only one option in a new place. I figured we could move it later once we start adding more, but it will probably be a while before we can build the infrastructure and refactor the code to support better keyboard shortcut customization.

[ajlende]

One challenge that may suggest starting with just a single keyboard shortcut — the most important one, go to toolbar, as you suggest — is that when you have more than one keyboard shortcut you likely need some conflict detection to see whether a chosen shortcut is already in use.

Adding this particular shortcut is useful for unblocking #59199, so I figured we'd be able to do an ad-hoc solution for remapping this particular shortcut and think about the input mechanism for registering more shortcuts (and detecting conflicts) when we add a second shortcut.

There is the opportunity for someone to reset this to an existing hard-coded shortcut, but I think it's okay to trust the user (for this first iteration) to not do that. If they do, they'll see something is wrong and be able to reset the shortcut to the default value to fix the issue.

[ajlende]

Here's a rough Figma prototype that shows a few more things on a happy path.

• Click an input to enter input mode OR tab to the input and press Enter.
• Press your key chord (all buttons together as if you were using the shortcut).
• Pressing another key chord before confirming will replace the previous one.
• Press Enter to confirm the shortcut.
• Click the reset button to reset OR tab to the reset button and press Enter.

There are a few things that I'd like changed from this rough prototype.

• The [-] icon that's labeled reset didn't communicate the reset very well, so I used [⟲] rotate-left for now, but we may need a better icon.
• The keys should start showing up as you press them rather than all at once for more immediate feedback.
• Maybe some more feedback that you're in edit mode like blue text or something?
• The order of the modifiers should be the same as in the existing shortcuts modal.

[jeryj]

@ajlende and I have been talking about the UX flow for this. Here's some rationale and justification for each of the design decisions:

Input Activation: Enter or Click to begin editing vs Edit button

To begin editing a shortcut, we could offer an Edit button or allow an enter keypress/click on the input to begin recording the shortcut keypresses. Initially, I thought Edit buttons would be best as this is the standard process for keyboards and screen readers, but it begins to break down when working with shortcut inputs since we need to override standard keycontrols while in editing mode. For example, Escape would typically cancel editing, but Escape could be part of a valid keyboard shortcut keypress.

Also, having an edit button for one shortcut isn't cluttering, but once we allow this pattern for all shortcuts, it becomes quite overwhelming for the UX. Also, if one were to edit all their shortcuts, many edit buttons would greatly increase the number of clicks/keypresses to change all the shortcuts.

The shortcuts can't be an open input field, otherwise it becomes a keyboard trap once it is tabbed to.

With all this in mind, to begin editing the input, you'll have to press Enter. This is a non-standard way to begin editing a field, but it also can't have a standard way of exiting the input, as Escape and Tab are both a valid shortcut keypresses. Escape can't clear the input and Tab can't tab out of it, otherwise you can't use Escape or Tab within you shortcut. Because of this, I think we're justified in offering a short learning curve: Enter to begin editing the shortcut, Enter again to save. Other inputs within the Preferences modal save at the time they are modified, so saving after edit also follows the existing pattern of the context.

Recording the shortcut value - Key by Key Input (normal typing) vs Chorded

Key by Key Input: Allow for keys to be pressed in succession, just like typing in a normal input field.
Chorded: Press all the keys you want at the same time, the same as you'd do to use the shortcut. If you release the keys and press a new key combo, it will overwrite your previous value. For example, if I want my shortcut to be Shift + J, I will need to press Shift + J at the same time.

Key by Key

• More likely to be right: On the chorded input, if you press key by key, it will overwrite your change (Shift + J pressed in series will end up with J, as the J would overwrite the Shift keypress). If we allow key by key, then pressing a chorded Shift + J or a series of Shift + J would end up with the desired shortcut. So key-by-key allows for both chorded and typed shortcuts. That's a big positive. However...
• It's really annoying if you have a typo: If I accidentally pressed Shift + H, and I wanted Shift + J, I might instinctively press Delete, which would make my incorrect shortcut become Shift + H + Delete. Then maybe I press Escape to cancel, which makes the shortcut become Shift + H + Delete + Escape. To undo this, I'd have to press Enter to intentionally save my error, admitting my shame to the world, and do it again. At this point, I would be quite annoyed.

Chorded:

Faster to understand and undo if you make a mistake. For the chorded input, if I press Shift, release, then J, I will end up with J as my shortcut. Maybe I try Escape to clear it and see the J overwritten with Escape. At this point, I would try the chorded input of Shift + J at the same time to get to the shortcut I want. I don't have to save my error and start again on a typo. The simpler error correction is quite worthwhile here to avoid larger frustrations.

Errors are likely to happen with either method. A user faced with a key by key error is going to be frustrated. An error on the chorded input is just a quick lesson in how the input works. With how poor the UX is to undo a mistake on the key-by-key, I think a chorded input is the better option.

Resetting Fields

After a new shortcut is entered, a reset button is offered for that input.

[ajlende]

One more thing about conflicting shortcuts is that some shortcuts may need to be contextual.

The ⇧Tab example in the mockup, for example, is intended as a way for users to override indenting behavior and navigate to the block toolbar instead (see #59199).

We wouldn't want ⇧Tab in this example to be a global shortcut as it conflicts with basic editor navigation like navigating between input fields.

Potentially we could separate the global shortcuts from the contextual ones. This particular contextual shortcut can be unset initially.

[afercia]

Looking into this issue I'd tend to think it moves from some assumptions that don't sound entirely correct to me. The behavior of these shortcuts has been discussed in many other issues and PRs but I'd like to point out a couple considderations one more time.

Tabbing to indent items in the List block is a common pattern in software

That may be true for document editors but it's not true in all software. Document editors like Word or Google Docs, whether they are operating system apps or web abbs doesn't matter, are meant to edit a document. Instead, the Gutenberg editor is a web app where the native behavior of Tab and Shift+Tab needs to be preserved.

I think #59199 is a good compromise and does what Google Docs. Indentation with Tab / Shift+Tab works when the cursor is at the start of the selection. Otherwise, it preserves the nativ ebehavior.

cmd ⌘/Ctrl + k is commonly accepted to launch the equivalent to the editor's command palette

I'd argue that this is an incorrect assumption. For ages, cm/Ctrl + k has been an industry standard to insert a link in most of the web editors I can think of. It's a standard since more than 20 years. Command palettes came way after and if htey use the same shortcut they're just doing it wrong.

[priethor]

I'm not sure I follow this part entirely:

they are operating system apps of web abbs

and

the Gutenberg editor is a web app where the native behavior of Tab and Shift+Tab needs to be preserved

What's the difference, then? If they are all web apps, what's the rationale for stating so strongly that needs to be preserved? In fact, I would argue that the Gutenberg Editor is, well, intended to edit documents as well; the challenge is that it's a complex app where sometimes users are in a document-editing context, and sometimes they are not, hence the argument to make the shortcut context-based.

[afercia]

I fixed a typo whether they are operating system apps of web abbs vs. whether they are operating system apps or web abbs I hope that helps clarify the first part.

In fact, I would argue that the Gutenberg Editor is, well, intended to edit documents as well

There is large disagreement on whether the Gutenberg editor is closer to a text document app or a web app based on form controls. To me, it's not a text document editor. The editor UI makes use of form controls: inputs, selects, buttons, contenteditable elements that are equivalent of textareas etc. As such, the Tab key needs to be preserved to its native functionality that is: navigating through interactive controls. Any other usage of the Tab key on a page that is basically a form-based web app would be totally unexpected.
Google docs and similar apps are an entirely different matter. Their main purpose is to edit a text document. It's not a case that they use a role=application that wraps the entire app canvas.