List view: focus management conflicts between focus on mount, TreeGrid roving tabindex, and keyboard shortcut focus

[afercia]

Description

The List View focus management expected behavior is made of three parts:

• When the List View panel opens, focusOnMount is responsible to set initial focus on the first tabbable element.
• When using the keyboard to navigate the list virew items, the TreeGrid roving tabindex implementation is responsible to make only one of hte items focusable at a time, which is necessary to implement only one tab stop anr arrow keys navigation.
• When a block is selected and the List View panel is opened via the keyboard shortcut:
  • The first usage of the keyboard shortcut is responsible to open the panel.
  • If the panel is already open, a new usage of the keyboard shortcut is repsonsible to move focus to the selected item in the list view (if there is one selected). This was implemented in List view: Modify the shortcut to focus while open #45135

Overall, the list view should have only one focusable item at a time. For example. the logic of the keyboard shortcut focus management expects only one focusable item, that is an item with tabindex=0. All the other ones should have tabindex=-1

However, there are cases where the list view contains two focusable items. This is not expected and makes the expectations described above fail.

There's several user flows where this may occur, I'm going to detail only some of them.

1
No blocks selected.
Open the list view. Initial focus is on the first item. So far so good.

2
Top level block selected.
Open the list view. Initial focus is on the selected item in the list view. So far so good.
The selected item is highlighted and focused.

3
Nested block selected.
Open the list view. Initial focus is on the first item.
The item of the selected block is highlighted but not focused.
Expected: to be highlighted and focused.

4
Using the keyboard shortcut from a selected block with the list view already open.
Start with no block selected.
Open the list view. Initial focus is on the first item.
Click on a paragraph to select it.
Use the keyboard shortcut (alt+shift+o on Windows, and control+option+o on Mac)
Focus is on the first item.
The item of the selected block is highlighted but not focused.
Expected: to be highlighted and focused.

Animated GIF to illustrate:

There are other flows to test in depth, I'll reserve to details them later if necessary. To mention a few of them:

When a post is empty and there are no blocks yet

• Clicking the toggle button: focus stays on the button. Expected: focus to move somewhere into the panel.
• Using the keyboard shortcut: focus goes to the 'List View' tab in the list view because of the fallback in handleSidebarFocus.

With 'Always open List View' preference enabled

• On page load, initial focus is on the List view first item. This is unexpected because the tab sequence should start from the root of the document.
• The first block in the editor canvas is highlighted but not selected.
• Press the Tab key: focus moves backwards to the post title, not sure why.
• Use the keyboard shortcut repeatedly: focus moves through the list view first item and the toggle button in a loop.

When the panel is open but the selected tab is the Outline one.

To be tested.

With multiple blocks selected

To be tested.

Step-by-step reproduction instructions

See above

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]

I think the first thing to try here is to not attempt to set initial focus in the first item.
The List view actually contains two tabs: List view and Outline.
Assuming that initial focus should go to the list view first item makes focus skip relevant content placed before it and it's inconsistent. For example. when opening the main inserter focus goes to the first tab inside the panel.
Other panels don't set initial focus at all for example: the Settings panel and the Global Styles panel don't. This is inconsistent and I'd suggest to explore a consistent pattern for initial focus of all panels in the editor. Such exploration worths a separate issue but it's good to keep it into consideration for the List View.

One more dcision to make is about the expected behavior.
When a block is selected, should focs always go to the related item in the list view, regardless of the method (toggle button or keyboard shortcut) the panel was open with? Is the double behavior of the keyboard shortcut as implemented in #45135 still valid? I wouldn't have big objections with keeping it as is but I'd like to note that this behavior is not documented anywhere in the UI. The keyboard shortcuts modal dialog onl mentions that it 'shows or hides' the panel:

Moreover, I would love to see all the keyboard shortcuts that open panels use the same consistent pattern, that is: the same modifier. At the moment:

• Show or hide the List View: access + o
• Show or hide the Settings panel: primaryShift + ,
• Mor shortcuts should be added to open Settings, Global Styles and any other panel.

Also, it's worth reminding that all the shortcuts that use the access modifier don't work at all when VoiceOver on mac is in use.

[afercia]

My findings so far:

• When the panel opens, useFocusOnMount sets initial focus on the first tabbable element: the first item (if any)
• If there are no blocks yet (the post is empty), focus stays on the toggle button and the keyboard shortcut doesn't move focus.
• At this moment, all the items are focusable. None of them has any tabindex attribute.
• As soon as navigating into the list view with the Tab key, the roving tabindex implementation adds tabindex="-1" to all the items except the selected one.

[afercia]

One more problem with the current implementation is that:

• The ListViewSidebar uses useFocusOnMount to set the initial focus.
• useFocusOnMount uses a setTimeout internally, which makes it run after any other effect.
• ListView has some internal logic to set initial focus on the selected item on mount. This runs first, and useFocusOnMount runs after. As such, useFocusOnMount may steal focus from the selected item.