Top toolbar improvements follow up

[draganescu]

WordPress 6.3 includes improvements to the position and functionality of the block toolbar when it's set to be fixed to the top of the editor.

However while the improvements are valuable (freeing plenty of screen space, being more familiar compared to other application UIs) the implementation is, to put it bluntly, terrible.

The block toolbar in fixed mode is absolutely positioned on top of the editor's UI header. This is terrible because it is impossible to prevent it overlapping UI elements in the editor chrome - such as plugin icons on the plugin area or even native elements when certain blocks have a lot of tools available.

The proper implementation - rendering the toolbar in a slot in the interface header, thus allowing the browser to handle overflow, could not be achieved because of a seemingly unrelated issue: editor keyboard navigation.

Tab key behavior

Due to historical context the block editor uses the tab key to navigate focus to the editor UI, from a text editing context. By convention this resulted in shift tab moving focus to the block toolbar.

This makes it impossible to render the block toolbar too far in the form from the currently selected block.

• We should figure out how restore the normal behavior of tab and shift tab to intent/outdent text

Toolbar focus via keyboard

Because the block editor user floating toolbars with multiple floating toolbars visible at the same time (e.g. the image caption toolbar is visible along with the image block's block toolbar) we are using shortcut Alt+F10 to "focus the nearest toolbar". This has the effect that in practice most of the time alt+f10 selects the block toolbar - so it became a shortcut for this.

This makes it impossible to render the block toolbar too far in the form from the currently selected block.

• We should change the behavior of Alt+F10 shortcut to cycle focus through visible toolbars.

These two changes would allow them the top toolbar to be rendered properly in the editor UI.

What are the blockers in implementing them?

[joedolson]

If you haven't seen the conversation between @jeryj and @alexstine on #52196, it contains a lot of relevant discussion points on handling. I strongly suggest reading that thoroughly.

Changing Alt + F10 is tricky, because it is a primary method for screen readers to navigate this pattern.

[jeryj]

It sounds like the best direction to try is to get all the toolbars into one place in the DOM, and have Alt+F10 move you to the toolbar area. Then, the current shift + tab behavior to focus the toolbar can be removed. It's unclear what the specific markup and behavior should be from there, but any accessible solution will likely include all the toolbars being together in the DOM.

[alexstine]

Agree with @jeryj assessment. Need to get all toolbars together in the DOM, make Alt+F10 work perfectly, remove Shift+Tab from navigating to toolbars, and then think through how we communicate to users that there are multiple toolbars. Tab and Shift+Tab might be good to navigate between toolbars but since this pattern is not used in Microsoft products for Windows, cannot say how easily known or adoptable it would be. Alt+F10 is an easier argument due to F10 (alone) currently being the ribbon navigation command on Windows.

[draganescu]

@alexstine what does "alt f10 working perfectly" mean?

I hope to make tab and shift tab not navigate the UI unless the focus is on the UI. When the focus is in text editing contexts tab and shift tab should only indent and outdent. We should figure out how to not rely on them to focus the editor UI from text editing contexts. This is where alt f10 comes into play, pluys the region navigation shortcuts.

Speaking of bringing all the toolbars into the same place in the DOM: what other situations with multiple visible toolbars are there except for the image caption example? Because if its just the image caption maybe this one should be merged in the image block's toolbar and be done with it.

[alexstine]

@draganescu I do not know. There could be other blocks with these toolbars and if there are, I do not have a list of them. I am okay with combining the toolbars though, that is the simplest solution here.

[annezazu]

Moving this to 6.5 as we still need time to both get feedback and explore different design with clearly broken down issues. This is too high level at this point to be actionable.

[Mamaduka]

Should we combine the #47723 here or vice versa?

[jeryj]

I'm exploring most of these changes in #53779.

[draganescu]

I think we should close #47723

[Mamaduka]

@draganescu, @jeryj, are there any todo items in #47723, that are still relevant after refactoring? In that case, it would be nice to move those here.

[jeryj]

Closing this issue now that #55787 is merged and the top toolbar is in the header DOM. The mentioned Tab indent/outdent and alt+f10 focus order could still be discussed, but are no longer blocking the top toolbar DOM issue. Feel free to reopen and reclarify if needed!