Accessing image block's crop tools with keyboard results in focus loss

[talldan]

Describe the bug
If a user tries to access the image block's crop tools using only a keyboard, focus is lost making it hard/impossible to get to the tools.

To reproduce
Steps to reproduce the behavior:

1. Add an image block and upload an image to it
2. Shift tab to the image block's toolbar
3. Use right-arrow key to focus the 'Crop' tool and hit enter
4. Focus is lost, try getting back to the image block toolbar using the keyboard
5. When focus is back on image block toolbar, crop mode is no longer active

Expected behavior
When selecting 'Crop' focus is moved to the nearest place (probably the 'Zoom' button, but open to feedback from the accessibility team on this).

Editor version (please complete the following information):

• Tested with Gutenberg 8.8
• Mac OS Firefox

[sunnyssr]

@talldan
I am able to reproduce this issue.
Reason for this is when crop menu becomes active, the button for crop menu gets removed from DOM. Since the element which was focused is removed from DOM, so focus goes back to start of the page which result in hiding the image block toolbar.

Possible ways to fix this:-

• Move the focus to first element inside crop menu
• Instead of removing the button for crop menu, visually hide it when it become active and use it for showing whether menu is expanded or not.

I would appreciate more feedbacks on this.

[talldan]

Thanks for testing @sunnyssr.

There's a similar UI (in-toolbar editing) in this pull request - #24021.

And some observations there that might be relevant.

[afercia]

Thanks for pointing out this issue! I think the focus loss isn't the only problem here.

As mentioned in #24021, replacing parts of the toolbar "on the fly" also breaks the toolbar expected behavior, specifically:

• arrows navigation
• the "roving tabindex"

I didn't look in depth at the code but I think both features rely on the which buttons (and their number) are initially rendered within the toolbar. Replacing part of those buttons with another UI breaks the toolbar implementation itself. To test: try to "manually" re-focus the toolbar and at that point various weird behavior happen:

• arrows navigation is broken
• some buttons within the toolbar can be focused by pressing the Tab key: this shouldn't happen, as only one button should be focusable via tabbing
• at some point, arrowing isn't constrained within the toolbar and focus is moved to the post title or somewhere else.

Will report the above in a separate issue.

Besides the general usability and accessibility concerns mentioned in #24021 I'd tend to think this design which replaces part of the buttons within the toolbar isn't ideal and should be reconsidered. I'll propose to discuss this issue, #24021, and the proposed design in the next weekly accessibility meeting.