Splitting this out from #2960 (comment)

See also the new fixed toolbar at the top: #2998

#2960 is going to add shortcuts to:

• navigate from a block editing area to its toolbar: Alt-F10 and Cmd/Ctrl
• navigate back from the toolbar to the block being edited: Escape

However, when pressing Escape, focus is moved back to the block container .editor-visual-editor__block.is-selected. For editable blocks, this is not the editable area. Instead, focus should be moved back:

• if the block has an editing area: inside the editing area, putting the cursor in the same position where it was before or on the selection if there was a selection. This is what TinyMCE currently does in the classic editor
• in a proper place if the block doesn't have a real editing area but has other fields

I'd say moving focus back to the container doesn't help so much the editing experience for all users, not just assistive technologies users.

See also:
https://www.w3.org/TR/wai-aria-practices/#h-note-17

Escape or Enter may return focus to the invoking context. For example, a rich text editor may have a menubar that receives focus when a shortcut key, e.g., alt + F10, is pressed while editing. In this case, pressing Escape or activating a command from the menu may return focus to the editor.

The important thing to note here is the "invoking context": if the initial context is the editing area, then I jump to the toolbar and then I jump back to the block, I'd expect to be in the same context I was in initially.

One more thing:
Probably unrelated, so maybe should be addressed separately:
Not sure why, but when clicking/pressing Enter on some buttons, for example the alignment buttons, focus stays on that button. Instead, when activating other buttons, for example bold/italic/strikethrough, focus is moved back to the editing area. This is inconsistent: all buttons should behave the same. It's also different from what TinyMCE does in the classic editor, where focus is always moved back to the editing area.