Indent list keyboard shortcuts inconsistencies

[afercia]

Follow up to #4181

For accessibility reasons, the Tab key in Gutenberg should keep its native behavior which is navigating through focusable elements. This is the reason why #1826 introduced new shortcuts to increase/decrease the list items indentation in the List block.

As mentioned in #4181 (comment) the Classic Editor and Gutenberg need a different behavior, for a simple reason: in the Classic Editor, there's just one editable area. Users can always press Enter or "exit" the list by other means and have the Tab key back to its default behavior.

Instead, in Gutenberg there are multiple editable areas (the blocks) and the Tab key needs to preserve its native behavior to allow navigation through the UI avoiding a "keyboard trap".

However, there are a few issues.

The new shortcuts work this way:

gutenberg/core-blocks/list/index.js

Line 205 in 02c9edb

if ( keyboardHasSqBracket ) {

meta+[ for list outdent
meta+] for list indent

Where meta means control on windows/linux and command on mac. For keyboard layouts without squared brackets meta+m is used for indent and meta+shift+m is used for outdent.

The first issue is that on macOS (not sure on linux) meta+[ and meta+] conflict with the native shortcuts browsers use to navigate to the previous / next page. I'd tend to think Gutenberg shouldn't break native shortcuts, especially very important ones. Maybe an additional modifier should be used.

The second issue is that while the List block uses the new meta+[ / meta+] shortcuts, the Classic block (TinyMCE) doesn't and still uses the Tab key. This is inconsistent and confusing for users.

The third issue is that none of these shortcuts are visually exposed in the UI. #6605 added some shortcuts to some tooltips in the toolbars:

However, the ones related to indentation are not displayed (see also #6195 ):

Ideally, also the tooltip text should be consistent.

Additionally, in the Custom HTML block the Tab key is used for indentation: that makes a bit more sense since this block is actually a code editor. To Tab away from the block, users need to press Escape first, not ideal but that's the same trick used in other code editors in core.

Ideally:

• there shouldn't be keyboard traps
• consistency is important though, and shortcuts for indentation should be consistent for all blocks

I'd like to discuss this issue during next accessibility team meeting. Also WCEU would be a nice opportunity for some live conversations.

[ZebulanStanphill]

The Decrease indent and Increase indent buttons are not just for indenting list items. They also indent the start of a paragraph with padding. So the indentation buttons in the Classic block have two different functions depending on the context.

[skorasaurus]

Some feedback from a user with 2 ubuntu computers (and 2 keyboards) both with:
ubuntu 16.04
Firefox 61
Gutenberg 3.7.0

One of them (Keyboard X) has a 104 Key QWERTY keyboard, has both square brackets and meta key, default layout for ubuntu.

The other (Keyboard Y) is a thinkpad T450; I don't think it has a meta key on it.

Keyboard 'X'
While in a list block in Gutenberg:
pressing the Meta Key displays the menu that also displays when a user also right-click their mouse; meta+m does not have any effect. meta+[ does not have any effect.
meta+] does not have any effect.
Through trial and error, I figured out that Control + ] and Control + [ indents and outdents list items for me.

While not focused in a specific block but still on an page in editor mode, meta + m creates a bookmark.

Keyboard Y:
Control + ] and Control + [ indents and outdents list items for me.

IBM has some suggestions and background.

[designsimply]

Let me try to help make this issue more actionable and note that I am happy to help test and move actionable items into separate issues if needed.

The first issue is that on macOS (not sure on linux) `meta+[` and `meta+]` conflict with the native shortcuts browsers use to navigate to the previous / next page.

I did a quick test for this and found that on my Mac (macOS 10.13.6) meta+shift+[ and meta+shift+] work to navigate to the previous/next page in each tab's history and meta+[ and meta+] did not. I tested Chrome 69.0.3497.92, Firefox 62.0.3, and Safari 12.0 on macOS 10.13.6.

A keyboard shortcut for indentation would be handy, but I'd recommend to not use Tab.

Source: #4181 (comment)

The second issue is that while the List block uses the new meta+[ / meta+] shortcuts, the Classic block (TinyMCE) doesn't and still uses the Tab key. This is inconsistent and confusing for users.

It sounds like you are advocating to not use the Tab key for list indentation but then you say it is inconsistent and confusing if different keyboard shortcuts are used instead of the Tab key. I don't have a strong preference, and I also see that it seems like it might be a hot topic with opinionated past discussion (not in a bad way) and because of that I would like to observe that if Tab and Shift+Tab are used for indentation the same way they are in the Classic Editor that would be a point for consistency and users should be able to press Enter - Backspace or "exit" the list by other means and have the Tab key back to its default behavior the same way it has worked in the past. It will also solve any possible conflicts for meta+[ and meta+] raised in the first issue (above).

The third issue is that none of these shortcuts are visually exposed in the UI. #6605 added some shortcuts to some tooltips in the toolbars.

Tested with WordPress 4.9.8 and Gutenberg 4.0.0-rc.1 and confirmed that keyboard shortcut tips are not exposed in the UI for Indent list item and Outdent list item buttons in the list block toolbar. Note: if we update to match the behavior in the Classic Editor, the Tabs aren't present as a UI tip there either and so it would be a bit more consistent to leave them off.

[afercia]

@designsimply Thanks for testing and for your thoughts.

and users should be able to press Enter - Backspace or "exit" the list by other means

I wouldn't have objections to pair the behavior with what Classic Editor does. The problem is in Gutenberg pressing Enter creates a new block. That's not necessarily what users want to do. They just want to exit the list. If that can be changed then great, but I doubt it will as it's one of the main Gutenberg features.

Instead, Gutenberg introduces a new UI with plenty of controls that need to be easily navigable. Tab is the standard for keyboard navigation. To me, seems trying to explore a new solution seems more appropriate.

[tofumatt]

I appreciate the want for Tab to move through the controls/content of Gutenberg consistently, and I do agree that maintaining a good Tabing experience overall is a good plan.

In a few specific cases though, not using tab is inaccessible to many more users who expect it to behave like many other editors on the web, like the WordPress Classic Editor they may have been using for years, and like many native content-editing applications like Word behave. For autocomplete and list item indentation, using/restoring an override for Tab/Reverse-Tab seems worth it to me. In those rare scenarios we override Tab behaviour we should provide an obvious escape hatch (Esc key works for me) that would allow the user to move out of the "Tab-trap" and use Tab normally again.

That's the best compromise for the largest group of users to my mind.

Having spoken to other Gutenberg developers about this, it was understood that preserving Tab behaviour in general was a good idea and worth doing, but in a few specific cases it caused more confusion and usability issues than it solved. Software design is often a trade-off, and I think in this case we should accept this reduction in Tab consistency, but again design an escape-hatch.

[designsimply]

I wouldn't have objections to pair the behavior with what Classic Editor does.

Ace! ❤️

The problem is in Gutenberg pressing Enter creates a new block.

In case it helps, I think of it like this: pressing Enter twice from a list in the Classic Editor moves you from editing a list into editing a paragraph and pressing Enter twice from a list in Gutenberg moves you from editing a list into editing a paragraph. In this context, the action of exiting the list seems the same to me (regardless of if you are in a block or not).

[afercia]

Fair enough 🙂 I'd like to see this specific case being tested with real keyboard / assistive technology users, and be included in a future a11y audit see #10318

[nekohayo]

I'd like to throw in my 2¢ as a user story and perhaps (hopefully) this can be reconsidered in light of this additional information.

I'm struggling with this current behavior, not only because Tab and Shift+Tab to indent/unindent is standard in the majority of other applications I use (so I can't really unlearn that muscle memory shortcut) including web apps like Google Documents and Google Calendar, but also because shortcuts using the [ and ] brakets (or, arguably, also curly brackets or parentheses) are hard for me to use on a French Canadian keyboard (or the Dvorak equivalent) because [ and ] require the additional AltGr (right-alt) key... whereas Tab and Shift are always present on all of my keyboards/computers and require one hand with 1 to 2 keypresses at most, instead of two hands with 3 simultaneous keypresses.

I'm 110% fine and happy that Tab would be used for navigation when the text cursor is outside a (bulleted or numbered) list block, but not when it's inside a list. When it's inside a list, I would expect it to adapt its behavior to the context and control the list's indentation. If I wanted to escape this, I would either move the text cursor out of that block (using the up/down arrow keys to navigate, or pressing Enter twice to create a new regular paragraph blog), or press Escape.

Personally, no matter the app, subconsciously I "expect" the tab/shift+tab keys to be mapped to indent/unindent when inside a list block inside a rich text editor, especially when there is a text selection across multiple items. I believe Gutenberg could be smarter in interpreting the user's intent in those contexts.