Distraction free mode breaks the ARIA toolbar keyboard interaction

[afercia]

Description

Hat tip @carolinan for catching this issue.

When Distraction free mode (introduced in #41740) is enabled, the 'Document tools' ARIA toolbar (NavigableToolbar component) in the Post editor top bar can't be used with a keyboard.

For clarity: the 'Document tools' ARIA toolbar is the portion of the editor top bar that contains the 'Tools', 'Undo', 'Redo', etc. buttons.

Screenshot with Distraction free mode disabled:

Screenshot with Distraction free mode enabled:

With Distraction free mode enabled:

• It's not possible to navigate to the toolbar buttons by using the keyboard.
• Even when forcing one of the toolbar buttons to gain focus by clicking on it:
  • Arrow keys navigation doesn't work.
  • Home / End keys navigation doesn't work.

Turns out Distraction free mode hides some of the toolbar buttons with display: none. This approach breaks the keyboard interaction of the ARIA toolbar pattern provided by NavigableToolbar.

A quick recap of how the ARIA toolbar pattern is supposed to work is available at the related ARIA Authoring Practices Guide page. See also the roving tabindex mechanism.

Distraction free mode should not use display: none to hide the toolbar buttons. Instead, it should make the toolbar render only the desired buttons and make sure the expected keyboard operability and interaction work as expected.

On a related note: once again, I'd like to kindly stress the importance of manually testing with the keyboard any new UI. This kind of bugs are so evident that can be easily prevented with just a couple minutes of keyboard testing.

Step-by-step reproduction instructions

• Edit a post.
• Enable Distraction free mode.
• Use the Tab key (or Shift+Tab) to navigate through the UI.
• The entire Top bar is initially hidden.
• Once focus is within the top bar, it becomes visible.
• Tab to the site logo 'View Posts` link at the top left (assuming Fullscreen mode is enabled).
• Press the Tab key.
• Observe the 'Tools', 'Undo', 'Redo' buttons are skipped and focus goes to the buttons at the right side of the top bar.
• Expected: focus to go to the first button within the ARIA toolbar: the 'Tools' button.
• Same happens when tabbing backwards by pressing Shift+Tab: the entire ARIA toolbar is skipped.
• Force the ARIA toolbar to gain focus by clicking the 'Tools' button.
• Press the Escape key to close the dropdown menu.
• Observe focus is now on the 'Tools' button.
• Press the Right arrow key. Focus goes to the 'Undo' button.
• Press the Right arrow key. Focus goes to the 'Redo' button.
• Press the Right arrow key. Nothing happens. Expected: focus to cycle and go to the 'Tools' button.
• Press the Right arrow key again. Nothing happens.
• Press the Right arrow key again. Focus goes to the 'Tools' button.
• Press the Left arrow key. Nothing happens. Expected: focus to cycle and go to the 'Redo' button.
• Press the Left arrow key again. Nothing happens.
• Press the Left arrow key again. Focus goes to the 'Redo' button.
• Press the Home key. Note: depending on your keyboard layout you may need to press a keys combination. For me it's Fn+Left arrow.
• Nothing happens. Expected: focus to go to the first button within the ARIA toolbar: the 'Tools' button.
• Press the Left key a few times until focus goes to the 'Undo' button.
• Press the End key. Again: depending on your keyboard layout you may need to press a keys combination. For me it's Fn+Right arrow.
• Nothing happens. Expected: focus to go to the last button within the ARIA toolbar: the 'Redo' button.

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

[afercia]

Couple more things to note:

If #44932 lands and actually adds back the 'Toggle block inserter' button, that would solve the first part of this issue ie. the initial focus.

I see Distraction free mode is being considered for the Site Editor as well, see #49175. It would be great to make sure the Site Editor implementation get things right since the beginning preserving the expected keyboard interaction.

[draganescu]

Hi @afercia we seem to hit an conundrum in #47277 too and it's somewhat related, i'd love some hints or opinions around my problem in here. Thank you!