-
Notifications
You must be signed in to change notification settings - Fork 4.5k
Description
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