Navigation page: create consistent experience to navigate to the toolbar

[afercia]

Describe the bug
Splitting this out from the Navigation page redesign issue #25178

it should be possible to Shift+Tab from the block to its toolbar (just like in the post editor)

I'd definitely second this. There should be better affordance across all the new UIs and wherever there's a toolbar, one single Shift+Tab should take from the edited object to its toolbar.

For example, right now when I select part of a menu item because I want to make it bold:

• the first Shift+Tab brings me to the focusable list item that wraps the contenteditable
• the second Shift+Tab brings me to the "Save" button
• the third Shift+Tab brings me to the "Block inspector" button, which technically isn't part of the toolbar
• finally, the fourth Shift+Tab brings me to the real toolbar, where arrows navigation and roving tabindex work as expected

This doesn't help keyboard users and assistive technology users in trusting the user interface, as they would expect the same mechanism that's in use in the block editor.

1
If the Block Inspector button doesn't logically belongs to the toolbar, it shouldn't be visually placed at the right of the toolbar as from a visual perspective this communicates it's part of the toolbar (while technically, it isn't). It should be moved to another place where it's not a tab stop between the menu being edited and the toolbar.

2
If it is considered as something that does logically belong to the toolbar, then it should be placed within the real ARIA toolbar, that is the element with role=toolbar (this would remove one tab stop)

3
More ore less, same applies to the "Save" button: right now it's a tab stop between the menu being edited and its toolbar. It shouldn't be placed there.

4
As per the <li> focusable element that wraps the menu items, I'm not sure why it is necessary in the first place. For example, paragraph blocks don't have a wrapping focusable element. Is there a technical reason for this focusable <li>? It is a tab stop between the menu being edited and its toolbar which introduces a difference in the expected behavior compared to the block editor.

Editor version (please complete the following information):

• WordPress version: 5.6 trunk
• Does the website has Gutenberg plugin installed, or is it using the block editor that comes by default? plugin
• If the Gutenberg plugin is installed, which version is it? 9.0.0-rc.1

[tellthemachines]

Tested and can reproduce. Also found a couple related issues:

• When Shift+Tabbing into the toolbar from a Link block, by default focus goes to the Select parent button, which is hidden (it shouldn't be focusable at all but hiding it with display:none causes the whole toolbar to be skipped in the focus order). And when the invisible Select parent button is focused, the whole Navigation block is outlined, which is quite confusing:

• After deleting a block, and with focus on another block, the Shift+Tab sequence sometimes skips the toolbar altogether. (I was able to reproduce this pretty consistently on top-level menu items, but not when deleting items inside submenus.)

[tellthemachines]

The behaviour of Shift+Tab moving focus to the rightmost element in the top area (in this case the Save button) is the same as in the post editor when "Top toolbar" is enabled. Should we change it there too? Ideally we would use the same approach in both places.

[afercia]

Not sure what to do with top toolbar. I'd tend to think Shift+Tab should reliably move focus to the toolbar of the object being edited only when they're rendered close each other in the DOM.

The other way to jump to the toolbar is by pressing Alt+F10 (legacy shortcut that worked on Classic Editor) and that works also with top toolbar. Thoughts?

[tellthemachines]

Not quite sure how to move forward with this one, so requesting some design feedback. Cc @shaunandrews

[shaunandrews]

I think this has been resolved with #28675

[tellthemachines]

Yeah this is good to close now.