Site editor: rethink where initial focus lands

[afercia]

Description

Splitting this out from #57400 (comment)

Setting initial focus on a specific place in any UI should only be done when there's a very, unique, specific flow users haev to follos so that establishing a 'starting point' makes sense based on that flow.

In all other cases, where there's no unique, specific, flow users can take the best option is to not set initial focus and just let the Tab order start from the document root. This also helps discoverability and consistency as users start navigating the UI from the beginning and they're not forced to 'skip' important parts that live before any place where initial focus may be set.

Currently, in the Site Editor when switching from 'view' to 'edit' mode, initial focus appears to go to the editor canvas. Actually, focus is already on the editor canvas iframe. It just stays there but other parts of the UI are now rendered before the iframe.

That happens because in 'preview' mode, the preview only shows the iframe, which has an ARIArole="button" and a label Edit. When the iframe is focused and after pressing the Enter key, the editor switches to 'edit mode. Focus just stays on the iframe but now the entire top bar is rendered before it. From a keyboard accessibility perspective this is equivalent to setting initial focus to a place that doesn't make much sense and that skips important parts of the UI. This current behavior assumes users have to start their flow in the editor canvas, which isn't necessarily true.

Rather after the editor switches to edit mode, focus should normally start from the document root.

The current behavior is also inconsistent with the initial focus in the Post editor, where the Tab sequence normally starts from the document root. Sooner or later the two editors will be unified so that having a consistent, expected, focus behavior should be implemented anyways.

Video to illustrate. Observe that after the editor switches to edit mode:

• Focus is not visible. Actually, it's still on the iframe.
• The editor top bar is now rendered before the iframe.
• After pressing the Tab key, focus goes to the first focusable block inside the editor canvas iframe.

Screen.Recording.2025-03-07.at.14.19.15.mov

Ideally, focus should be naturally reset bt I'm not sure that can be done in any way other than using an explicit blur() so that it starts from teh document root and the first Tab key press will focus the 'Open navigation' button at the top left.

Step-by-step reproduction instructions

• Go to the Site editor.
• Use the Tab key to navigate the UI.
• Once focus lands on the preview iframe, you will see a blue outline around the preview.
• Press the Enter key.
• Observe that focus is not visible.
• Press the Tab key.
• Observe focus is now on the first block inside the editor canvas iframe.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[afercia]

Important finding:
Looks like starting from motion version 9.0 , all elements with tap listeners or whileTap will receive a tabindex="0" attribute thus becoming focusable and tabbable.

In fact the div element with class edit-site-editor__view-mode-toggle that wraps the Open Navigation button does have a tabindex="0" attribute.

In this case, a tabbable fic contains a tabbable button. As such, there is an empty tab stop on a non-interactive element that is bad for accessibility.

It's something to be aware of to avoid adding tap listeners inappropriately on non-interactive elements.
Cc @WordPress/gutenberg-core

[stokesman]

the best option is to not set initial focus and just let the Tab order start from the document root.

This would help with consistency. When entering edit mode without using the preview frame "button" the focus starts from the document root. That’s typically the case when viewing post types that don’t default to "list" view like templates and patterns. It can also be the case even in "list" view if one uses the "edit" button instead of the preview frame "button".

[afercia]

This would help with consistency.

Yes. I tested a little more what happens when navigating to the sub-views by using the keyboard to check where focus lands when a sub-view renders. There's large inconsistency in the behavior and sometimes initial focus on a sub-view is set to a very unexpected place. It appears the initial focus behavior is far from ideal and largely untested. Thinking it should be fixed in the scope of this issue. To summarize:

Navigating to the Site Editor sub-views:

Navigation

• initial focus goes to the Back button of the sub-panel. This is the intended behavior.

Styles

• initial focus goes to the Back button but it's the same panel, it's not a sub-view of the navigation panel. The additional Styles panel opens.

Pages

• initial focus goes to the Back button of the sub-panel. OK.
• navigating to sub-views e.g. Drafts, Trash: focus stays on the menu item. Makes sense.

Templates

• initial focus goes to the Back button of the sub-panel. OK.
• navigating to sub-views: focus unexpectedly jumps to the 'Filter' button in the content area.

Patterns

• initial focus goes to the Back button of the sub-panel. OK.
• navigating to sub-views: focus unexpectedly jumps to the 'Filter' button in the content area.

Video to illustrate, where I'm using a big red outline to make the focus style more visible:

Screen.Recording.2025-03-10.at.09.31.48.mov