Press Esc to hide block outlines and block toolbar, press Esc again to enter select mode

[jasmussen]

It's hard to deselect blocks in the site editor. See also, #59770. An initial version of this issue suggested simply allowing Esc to deselect all blocks, like it currently deselects blocks if you have more than one selected. The problem with that is it would set focus on the canvas, and you'd lose your place, which could be jarring when authoring long documents.

One aspect of deselecting blocks is to preview your content without any selection styles or block toolbars obscuring content. We already have a mode called "is-typing" for that, where as soon as you start typing, outlines and toolbars fade away.

Could we do something similar when you press Esc?

• Have two or more blocks selected and press Esc, you deselect so you only have the first block selected.
• Press Esc again to hide selection styles (border and block toolbar).
  • Tabbing, or clicking a block would show them again.

Pressing Esc to invoke select mode could still be worked into this heuristic — it's something that shouldn't happen quite as often as it does today, so having it require that no blocks were selected and otherwise require being pressed twice, for example, might be one path forward.

Previous version of this issue

This is a followup to #47172, and outlines a new idea that expands on the current behavior in trunk.

Deselecting blocks remains an important aspect of previewing your content. Right now if you have two or more blocks selected, and press Esc, you deselect. But if you have a single block selected, which is often the case in the site editor since many themes use big containers, pressing Esc enters select mode. The issue of deselecting is compounded by the site editor often not having any non-block whitespace you can click to deselect. I.e. "click outside" also deselects, but when there's no outside, that won't work. The last way to deselect is to click the top breadcrumb in the footer.

Here's a GIF showing how pressing Esc opens select mode.

The proposal:

• Esc always deselects blocks. Whether you have one block or 10 blocks selected, press Esc to deselect.
• When you have no blocks selected, pressing Esc can still invoke Select mode.

[jeryj]

Deselecting blocks remains an important aspect of previewing your content.

So the main issue is wanting to be able to see the content in the editor without the blue focus ring?

My main concern here is what happens to focus when you press Escape? It would still need to be visible, predictable, and be easy to move you back to where you were. We'd also need to account for situations where a keyboard-only user:

• Navigates far down their editor content
• Presses Escape
• Focus is moved to...?
• If it's at the top of the editor content, they now need to navigate all the way back to their previous selection

I think we can explore this, but I'm hesitant because I think it will make keyboard navigation worse.

Where do people tend to click when they are trying to deselect? I assume most mouse users would try deselecting via clicking before moving to Escape anyways, so if the main idea is to make it easier to deselect via mouse, I think a better solution would be to make some commonly clicked areas deselect blocks.

[jasmussen]

Thank you for looking into this. Your comment to me suggests that there are some improvements we should make to the existing ways you use to deselect all blocks. Namely click outside and click the top breadcrumb.

Here's a GIF showing clicking outside or clicking the top breadcrumb in the post editor:

• When you click outside, focus is in the canvas, so you press tab and focus is back in the Title input field.
• When you click on the top breadcrumb, focus appears to land on the editor body element, so tab sets focus on the Site Icon back button.

This is the same in the page and CPT editors.

Here's a GIF showing the same flow in the site editor, editing a document, selecting a paragraph, then clicking outside to deselect, then doing the same but clicking the top breadcrumb to deselect:

• When you click outside, focus behaves the same as in the post editor, setting focus on the canvas. Pressing tab sets focus back in the Title field, or the first block if there's no title field.
• Clicking the top breadcrumb, focus is set again on the body element, so pressing tab focuses the site icon back button.

I would expect Esc to deselect to do the same as clicking outside to deselect: set focus on the canvas, so that the next tab-press focuses the first block in the block list.

Where we could improve, it would seem, is where focus is placed when you choose the top breadcrumb. I would argue that's separate from this issue, but perhaps something to follow up on. If reasonable, I'd expect the top breadcrumb to do the same, set focus on the canvas.

[jeryj]

I would expect Esc to deselect to do the same as clicking outside to deselect: set focus on the canvas, so that the next tab-press focuses the first block in the block list.

Escape isn't used to deselect in other contexts though. Clicking a new element should move focus to the clicked element. If you have a button focused and press Escape, it doesn't remove focus. If you have a button focused and you click off of it, it does move focus. I don't think we should be conflating Escape with "remove focus." It's more of "cancel action" in certain contexts. In the context of the editor, there isn't an explicit entry into editing flow, so there's no concept of cancelling an action in that same sense.

If I'm editing text, it is highly unlikely that I would want escape to move focus to the top of the document. It would be a focus loss to a keyboard user.

So the main issue is wanting to be able to see the content in the editor without the blue focus ring?

Is this correct? If so, and the issue is people trying to click to deselect things, then I think the appropriate fix would be to offer more click areas that deselect blocks. I think it will be a frustrating experience to have escape deselect blocks and move focus to the top of the editor canvas.

[jasmussen]

So the main issue is wanting to be able to see the content in the editor without the blue focus ring?

No. The main thing is to actually deselect all blocks. Is your main concern the use of the Esc shortcut?

[scruffian]

Sorry I don't think I understand the purpose of this issue. What is wrong with the current experience of clicking on the breadcrumb bar or off the canvas to deselect? Is it that we think users won't know that this is how to deselect, or is it that we are trying to find a way to achieve deselect using keyboard as well as mouse?

[jeryj]

Is your main concern the use of the Esc shortcut?

Yes. I'm fine with another shortcut. Escape to deselect all blocks makes sense in theory, but will be a very frustrating keyboard experience in practice because of how often you'll accidentally lose context.

[jasmussen]

The main issue is that in the site editor, there's rarely any "free spot" in the canvas to click on to deselect, and the breadcrumb bar can even be toggled off.

Escape to deselect all blocks makes sense in theory, but will be a very frustrating keyboard experience in practice because of how often you'll accidentally lose context.

I think I see where you're coming from — that is, if you're writing a post, if you deselect, then you'd go to the top of the page near the first paragraph, good point.

One of the reasons why Esc to deselect feels so natural in page builder contexts is that this is how it works in Figma, where it feels entirely natural. I wonder if there's a way to do this that accomplishes this same easy shortcut to deselect. 🤔

[scruffian]

In the context of the editor, there isn't an explicit entry into editing flow, so there's no concept of cancelling an action in that same sense.

Is that true? Don't you have to click/tab into the canvas to start editing?

[jeryj]

Don't you have to click/tab into the canvas to start editing?

Yes, you do have to reach it via a click or tabbing, but you don't have to press a button that says, "Edit." It feels the same as clicking/tabbing to a textarea (like this comment box I'm typing in). If I press Escape right now, nothing happens. I don't have focus moved to the top of the page, etc. There's no explicit action to exit from, such as in a modal or something that is activated via a button press (dropdown menus, modals, etc.

[jasmussen]

Thanks for all the conversation here, I've updated this issue!

[jeryj]

I think clicking empty spaces in the header and sidebar to hide the block toolbar and focus ring would be a better first attempt at solving for getting an unobscured preview of the editor state.

[afercia]

Escape isn't used to deselect in other contexts though. Clicking a new element should move focus to the clicked element. If you have a button focused and press Escape, it doesn't remove focus. If you have a button focused and you click off of it, it does move focus. I don't think we should be conflating Escape with "remove focus." It's more of "cancel action" in certain contexts.

I agree Escape should not be used for deselecting because that's not the expected behavior. Escape is reserved to 'cencel current operation' and should not be used for other purposes.

I'd also like to kindly ask you to mark any issue or PRs that touches important accessibility issues with the related GitHub label, thank you.