Shift between edit & selection/navigation modes with Esc/Enter

[jasmussen]

The concept of this ticket has been discussed in various tickets and replies, most notably this one. An implementation of this has even been valiantly attemptedy by @ephox-mogran with some success in #3195.

One of the purposes of this is to make it easy select multiple blocks and move them around easily, using just the keyboard, but there are a number of other accessibility related benefits that this has the potential to give us.

Having simmered on how this could work for a while, here is a flow with mockups that has been tweaked based on discussions. It boils down to this:

• When you're writing, pressing Esc selects the block you're in at the block level and Enter takes you back to where you were.
• When a block is selected at the block level, it's also focused, and you can move this focus with the arrow-keys. Or you can select siblings by using Shift + arrowkeys.

This is different from the previously discussed proposal, which added a 3rd focus mode — a highlighted block that wasn't selected, but which could be selected by pressing Space. The new approach is simpler, but it also means you can't select non-contiguous blocks using just the keyboard (similarly to when you select text in an editor using just the keyboard).

Mockups

Focus is on the first paragraph:

User presses "Esc". Now the first paragraph is selected at the block level:

User pressed down arrow key and sets focus on the 2nd paragraph block, which is now selected. If the user had instead pressed Shift + down arrow, both the 1st and the 2nd block would've been selected.

User presses Enter, and edit focus is now on paragraph number 2:

The above flow changes nothing about what works today, but builds on it by adding a few features:

1. Escape selects the block that has focus.
2. Using arrow-keys when a block is selected at the block level changes which block is selected.
3. Using arrow-keys with the Shift modifier pressed, when a block is selected at the block level, expands the selection.
4. When a block is selected at the block level, Enter sets focus back on the block.
5. When a block is selected at the block level, Tab circles around the side UI for said block or blocks.
6. When in edit mode, Tab works similarly: it circles around the side UI for said block — move down, move up, ellipsis, sibling inserter, in that order. It does not set focus on the next block, you use arrowkeys for that. This is inspired by @afercia in Experimenting with navigation and edit modes #3195 (comment)

Use cases

Making lists

Start typing. Type out five paragraphs. Realize you meant to make a list. Shift+uparrow starts a selection. As soon as you cross the boundary between inline level and block level, you're effectively in "selection/navigation mode". Once you've selected all five paragraphs, you press tab three times (focus lands first on move down, then move up, then on ellipsis), then you press Space to open the ellipsis, then you tab down to the "convert to list" transformation.

Deleting blocks quickly

You wrote a draft before lunch. It's elaborate with lots of different blocks. Nothing has focus, so you are in selection/navigation mode, but no block is selected. You start using arrow keys, and because you are in selection/navigation mode, as soon as you press down the first time, the first block is selected. Then you arrow down until you're at the end of the block list. You realize the 2nd to last paragraph is superfluous. You arrow-key up to select it, then you press Delete to delete it. At no point did you use the mouse, or enter Edit mode.

Moving a sequence of blocks from one space to another using basic keyboard shortcuts

You wrote a draft after lunch, and decided that the lavish gallery you created and the little paragraph of text you wrote below it make for a great opener, and want to move it away from where it is. Your focus is on the text block below the gallery. You press Esc to select the text block, hold shift and press up arrow to add the gallery to the selection. Press ⌘X to cut it out of the flow. The block before the gallery is now selected, and you press the up-arrow until you're at the first block, then you press ⌘V to paste.

Other benefits of this approach

• Because we're making it more easy to select a single block (just press Esc while you're typing), we're making it easier to delete at the block level. This is especially important for more complex blocks that have lots of input fields. Imagine a contact form where you have focus on the 3rd input field, and you realize you don't want a contact form after all. Just press Escape and Delete and you're good.
• By making block level selection more easy, we make it more clear that shortcuts you're used to, like ⌘A, will select all blocks. See also Copy and Export a Post #4284.
• Although this is definitely still having two modes — selection mode (with added navigation capabilities) and editing mode — we are keeping it conceptually simpler by adhering closer to how plain text editors work. In a way, this is more like an expansion of what multi-select is, than it is a separate mode.

Other notes

• Any click of the mouse outside the blocklist deselects all blocks. Any click of the mouse inside a block jumps straight into edit mode for that block.
• If you are in edit mode for a block, pressing Esc once selects the block, pressing Esc twice deselects all blocks.
• This ticket may either conflict with, or augment, Expand selection on consecutive ⌘A commands #4369.
• Block-level keyboard shortcuts (yet to be implemented, but think of ⌘+Shift+Uparrow for moving a block upwards one slot) work in either mode (except for Delete as mentioned under "benefits").
• Enable ⌘V without having to focus a block first #2303 would also benefit this approach.

For touch screens

Probably not a blocker for a first stab at this, but on mobile, a tap should always set focus on the text block. A longpress could select the block at the block level. Subsequent longpresses would then add to the selection.

Nested blocks

Nested blocks are coming (follow #428). For this feature, being able to quickly and easily select a block at the block level becomes still more important. The approach would be the same. Let's say you set focus inside a paragraph block nested inside a blockquote:

Press Esc to select this paragraph:

If you press the down arrow, you'd select the 2nd paragraph. If you pressed the down arrow twice, or the up arrow once, you'd select the entire blockquote itself:

Similarly, if you were in selection mode and arrow-keyed down from a paragraph block into a blockquote block, you'd first select at the parent level, subsequent down arrows would select nested paragraphs inside the blockquote.

Next steps

Is this a good approach? Does it feel intuitive? Would you like to see an animated mockup? Would this be hard to build? What are the accessibility implications? Let your thoughts be known.

CC: @mtias @karmatosed @afercia @ephox-mogran

[afercia]

I'm not sure Escape should select or perform any action other than "canceling" whatever is in progress. It's counterintuitive, as Escape it's always used to abort/exit/cancel the current operation. This was also mentioned in the initial Accessibility recommendations see #297

The Esc key should always get me out of whatever thing I am trapped within

I'd rather consider a two-steps process:

• when in Edit mode, Escape exits Edit mode and puts me back in Navigation mode
• in Navigation mode, some other key allows me to select a block; for similarity with checkboxes, I'd suggest Spacebar
• in Navigation mode, I should be able to tab just through blocks. Once on a block, Spacebar should select the block whether it's contiguous or not to another block
• instead, I'd consider to use the arrows/shift-arrows selection when in Edit mode

One of the biggest accessibility challenges in Gutenberg is that there are way too many UI controls "popping out" here and there in the interface. When navigating through the interface using only a keyboard or a screen reader, this multitude of controls makes very hard to understand where you are and what is happening. We've had a few assistive technologies users who just gave up while testing.

Providing a "mode" that makes navigating through the interface way simpler would be great. I'd consider such a mode the only way to give keyboard and screen reader users a chance to be able to use Gutenberg. Also, as I've recommended in previous conversations, I'd strongly recommend to make this "mode" the default for keyboard users.

When I've proposed the "Navigation mode", I meant just that: providing a way to quickly Tab through blocks and get just the blocks, without all the UI controls showing up.

Think at that as sort of switching command/insert mode in VIM 🙂

For example, in a post with 20 blocks, I'd just want to be able to navigate through all the blocks with just 20 Tab presses.

So about:

5. When a block is selected at the block level, Tab circles around the side UI for said block or blocks.
6. When in edit mode, Tab works similarly: it circles around the side UI for said block ...

I'm not convinced about the above. When a block is selected at the block level (which I assume is an equivalent terminology to "Navigation mode") Tab should just navigate to the following bock. Shift+Tab should navigate to the previous one.

[karmatosed]

Overall, this seems good. I have to say it's hard to judge until we get into prototype, but we can do that then.

I really like the focus on writing flow, it's important to smooth out the flow of creating within Gutenberg. Right now it's got a few hitches and I think if you knew about this, it would ease those.

My main point that swims around over this is how discoverable it is. Maybe this is where we expose in some NUX or some other tutorial method. However, I do wonder how we can expose this. I come back to Tips :)

I would like us to consider the mobile experience in conjunction. I don't see it as a blocker, but it's a requirement that has also the same ease.

[jasmussen]

Thanks so much for the detailed thoughts, Andrea, really appreciate it. Definitely a bunch of edges to smooth around when the popout UI shows up, and when it doesn't. Perhaps even reconsidering when it shows up in the first place, i.e. maybe it shows up only in edit mode. As we continue to refine we have to remember that all options are on the table.

As is the option to use Space to select a block, like a checkbox.

However I'd like to give a quick backgrounder on why the version mocked up in this thread makes sense to me as a simplified version.

I'm not sure Escape should select or perform any action other than "canceling" whatever is in progress. It's counterintuitive, as Escape it's always used to abort/exit/cancel the current operation.

I'm aware that Escape should always let you Escape ;) — but in a way this is still the case. When you are in edit mode, you escape to selection mode, but we have to set focus somewhere so your focus is still on the block you were just editing. If you press Escape again, you escape that selection too, but we still have to set focus somewhere, which is the editor canvas. It's like having two modals that you're closing/escaping one by one.

I don't mean to be all Obi-Wan Kenobi "from a certain point of view" on this, but I'm just trying to clarify my thinking and why I don't think it's necessarily wrong to use Escape for this action. It's not that the action is to select the block you were editing, it's about escaping the deepest editing mode, to a higher level selection mode, and you can escape further up to the document level if you like.

The chief benefit of this approach, as I see it is that it's not really a separate mode that could potentially be confusing to users, but it can potentially accomplish the same. The main downside is the lack of ability to select non-contiguous blocks.

Going to the next level — a more explicit navigation mode as you describe — this is an option, but before we go there I'd love to see if the simpler approach can accomplish the same.

• In a navigation mode you'd still have to press Escape twice in order to truly deselect all blocks — pressing Esc from edit mode would put a focus/selection rectangle around the block you were editing, no?
• In both navigation and, let's call it selection mode, you'd be able to arrow-key down the page very quickly. We can tweak what tab does from what I initially suggested here, if tab's where it's at then that's fine too.
• In both navigation and selection mode you'd be able to press Delete or Backspace or ⌘X on any marked block to act upon it. Same with many other shortcuts.

In the end it seems like the chief difference between navigation and selection mode is that in navigation mode, a block is focused, whereas in selection mode, a block is focused and selected. Is that correctly understood?

[afercia]

Perhaps even reconsidering when it shows up in the first place

Yes, please 🙂

it's about escaping the deepest editing mode, to a higher level selection mode

Maybe I'd need to see it in action, and maybe it's just about a different terminology 🙂 Until now, "select" meant to me a block is being edited.

I'd be OK when in navigation mode you land on a block, the block is also selected (meaning not in edit mode, just selected to be highlighted and expose higher level commands like move, delete, etc.). What I'm really interested in, it's to reduce the clutter keyboard users and assistive technologies users experience when navigating through blocks.

So this navigation/selection mode should be the default for keyboard users. They should be able to Tab through 20 blocks with just 20 Tab presses. I'm OK if when tabbing to a block, it becomes also "selected" (highlighted). When landing on a block in this mode, no UI should be shown and no additional controls should be focusable. Just the block.

The focused block wrapper should be the one with the aria-label that announces what the block is, for example: aria-label="Block: Paragraph". The aria-label can be moved to another wrapper, if needed.

[jasmussen]

Focus and Selection mental model for Gutenberg

The aim of this document is to clarify when a block has focus, what that means for the actions you take, and how that looks in mobile, desktop, and nested block environments.

Top level: Canvas layer

For the purpose of this flow, let's assume you've just opened up an existing post full of different blocks, completely fresh. The editor canvas now has focus.

If you instead had clicked "Add New" to write a fresh post, we'd set focus not on the canvas, but on the empty Title block at the top, putting you straight into the editing layer.

When no blocks are selected or being edited, what you see is a preview using the stock Gutenberg stylesheet. Future iterations of Gutenberg might load the theme stylesheet instead.

Canvas layer:

Second level: Selection layer

If you start using the ↓ arrow key, you select blocks (see this ticket). For example:

• Press ↓ three times, now the 3rd paragraph block is selected.
• Hold Shift and press ↓ three times, now the first 3 blocks are selected.
• Click and drag across blocks to select multiple blocks with the mouse.
• Press Escape to deselect all, and go to the top level/canvas layer.
• Click anywhere outside the blocks to deselect all, and go to the top level/canvas layer.

A selected block has a blue selection background around the entire block. Same color as text being selected. One or more selected blocks can be deleted, cut, copied, or transformed.

On a selected block, the block container itself has focus. The previous term for this has been "multi select".

Selection layer, first block selected:

Selection layer, second block selected:

Third level: Editing layer

If you select a block with the keyboard and press Enter, or if you click a block with the mouse, you are now editing that block. For example:

• Press ↓ to select a block, press Enter. You're now editing the block.
• Click any block with the mouse, to start editing the block.

When a block is being edited, it has a thin gray border surrounding the entire block. It may also have a quick toolbar, and the block might surface additional controls not shown in its unselected preview state.

A block being edited has these qualities:

• The element you click on when you first click a block has focus.
• If you clicked on a paragraph block, the editable textarea has focus.
• If you clicked on an image block, you likely clicked the image itself. The image has focus.
• If you clicked the white area next to a button, the block itself has focus. If you tab, you enter the editable button label first, then the URL field.
• Press Escape to go one level up to the selection layer, and the block will be selected (because you're no longer editing it, and we have to set focus somewhere). Press Escape again to deselect all and go up to the top level canvas layer.
• Click anywhere outside the block to deselect all blocks and jump straight to the top level.
• While editing text in a paragraph, if you start a selection by holding Shift and pressing ↓, once you cross the boundary between blocks, you select blocks at the block level, and move up one level to the Selection layer. Pressing Enter takes you back to editing.

Editing layer, second block being edited:

Nested blocks

We need to consider how arrowkey navigation affects nested blocks. Here are the two most obvious approaches.

Option 1, arrow-key enters nested blocks

Animation showing a user pressing ↓ from the top of a document, across nested blocks. In this solution, all nested blocks are selected during, and the nested container itself is selected as a whole both when entering it, and exiting it.

Option 2, arrow-key does not enter nested blocks

In this animation, a user presses ↓ from the top of a document, across only the containing blocks. In this solution, if you need to enter nested blocks, you have to press tab.

This seems less desirable than option 1, but may be necessary for more complex block containers such as a columns block where cycling through first column 1, then column 2, then column 2 may not be sensible.

Implications for complex or nested blocks

For blocks that have a single textfield:

• Click the field directly to set focus there.
• When you are editing, and navigate into the block with ↓ , focus naturally lands on the textfield. Another ↓ jumps to the next block.

For blocks that have multiple edit fields:

• When you are editing and navigate into a block and navigate into the block with ↓ , such as a contact form, the block itself has focus. If you need to access fields inside this block, use Tab to do so. Another ↓ advances to the next block.
• Placeholders (like an image placeholder) work the same way as complex blocks (see above): if you navigate into it with ↓, the placeholder itself gets focus; if you Tab while it has focus, elements inside get focus.
• If you click a field with a mouse, focus jumps straight to where you clicked, and the parent block receives the gray border implying it's being edited.

For blocks that have nested sub-blocks, like a list that has list items:

• A newly inserted, empty, list-block always comes born with a nested list-item that acts as a placeholder.
• When you are editing and navigate into the block with ↓, the list block gets focus. If you press ↓ again, you navigate into the first nested list item, which gets focus.
• If you click a list item, that list item gets focus directly.
• If you start a selection inside the list, you first select list items at the block level. If you cross the boundary between nested list items and the parent container, the parent container gets selected at the block level, and the previous selection of list items is lost.
• Only the block that is being edited has the gray border surrounding it. The parent container does not get a border, or otherwise indication that it is a parent. Note: this is standard for all wysiwyg editors, but we can revisit if it becomes necessary; other options include showing a thin dashed border surrounding the parent container.

For complex blocks that have nested sub-blocks, such as a columns block:

• A newly inserted, empty, columns-block always comes born with nested paragraph blocks, one for each column. These act as placeholders, and let you use the / command to insert.
• When you are editing and navigate into the block with ↓, the columns block gets focus.
  • Option 1: If you press ↓ again, you navigate into the first nested list item, which gets focus. Subsequent ↓ presses then cycles through all nested blocks in the columns block, starting with the column from the left.
  • Option 2: If you press ↓ again, you navigate to the next block adjecent to the columns block. If you need to navigate into nested items in the columns block, you have to do so using Tab, which starts in the top corner and moves down and in the reading direction.
  • Options 1 and 2 depend on the implementation, and what we find makes the most sense in the usage of this. Both approaches are valid.

[jasmussen]

CC: @afercia @iseulde @mtias @karmatosed @aduth, would appreciate your thoughts on the mental model for simplifying selection and focus as shown in #4382 (comment).

[msdesign21]

I can see option 1 being more ideal for something like a product block. As you say it comes down to the usage, does a person need to navigate each element in a block or not. @jasmussen do you have an example of a block that might not want to navigate each element in a block?

Have you considered Option 3: If you press ↓ again, you navigate into the first nested list item, which gets focus. Subsequent ↓ presses then cycles through all nested blocks in the columns block, starting with the column from the left (or first element in a block). Pressing Tab goes to the first element in the next block.

FWIW I found this thread today when I discovered shift + tab does not navigate to the previous block like pressing tab does, navigating you to the next block. I did not expect that hitting shift + tab would focus selection on the toolbar. I would have expected this to navigate to the previous block based on past keyboard navigation instincts.

[jasmussen]

@jasmussen do you have an example of a block that might not want to navigate each element in a block?

I honestly can't think of any, no.

But keep in mind there would be two types of blocks here:

1. A block that contains nested child blocks. Like a list, or a blockquote, or perhaps a future layout block.
2. A block that does not contain nested child blocks, but contains elements (like buttons or input fields) inside. Like the placeholder blocks.

In the case of option 1, the suggestion in this thread is that arrow keys, at least, work for those (except for child blocks in option 2).

In the case of option 2, the tab button should at least enter those elements.

Have you considered Option 3: If you press ↓ again, you navigate into the first nested list item, which gets focus. Subsequent ↓ presses then cycles through all nested blocks in the columns block, starting with the column from the left (or first element in a block). Pressing Tab goes to the first element in the next block.

This is actually what I imagine option 1 is, as mocked up above. I just didn't mockup the column option, but I imagine it would work as you describe. I think this is the most ideal, personally, as it also leverages the fact that the markup underneath is also vertically orientated.

FWIW I found this thread today when I discovered shift + tab does not navigate to the previous block like pressing tab does, navigating you to the next block. I did not expect that hitting shift + tab would focus selection on the toolbar. I would have expected this to navigate to the previous block based on past keyboard navigation instincts.

Agree, this is not ideal, and is a result of us having to have a way to let users enter the formatting bar with just the keyboard. We explored a command key for doing this, but there were side effects that were hard to address.

[karmatosed]

I think pulling out and highlighting focuses like this is beneficial and makes a lot of sense.

Option 1, arrow-key enters nested blocks

This feels more desirable for me also.

[jasmussen]

Noting that this is being worked on in #5709.

[afercia]

Note: it as also proposer to try a "global" switch using a keyboard shortcuts e.g. F7 (needs to be tested carefully to see if it conflicts with other shortcuts)

[mtias]

Consolidating with #5694