Skip to content

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

@afercia

Description

@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:

Image

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

Metadata

Metadata

Assignees

Labels

[Focus] Accessibility (a11y)Changes that impact accessibility and need corresponding review (e.g. markup changes).[Package] Block editor/packages/block-editor[Package] Editor/packages/editor[Status] In ProgressTracking issues with work in progress[Type] BugAn existing feature does not function as intended

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions