Image editor: initial focus incorrectly set to the crop area

[afercia]

When a modal dialog opens, initial focus should be set to the most logical place:

• When there's only one, unique, task users can perform: set initial focus on the control related to that task. For example: the 'Rename block' modal dialog contains only one input field and only one action.
• Otherwise, when there are multiple flows and actions users may take, do not make any assumption and set initial focus on the modal dialog container.

In the new Image editor, initial focus does not follow the above best practice. Instead, it is set on the image 'crop area'.

To reproduce:

• Edit a post that contains an Image block.
• Select the image block and acitvate the 'Crop' button in the block toolbar.
• The 'Edit media' modal dialog opens.
• Initial focus is not visible. To test it: press the Tab key once. Observe focus goes to the first 'resize handle' within the crop area that shows the image.

I'm attaching a video recording while using VoiceOver, to illustrate that when pressing the Tab key focus goes to the resize handles.
I'm also attaching a screenshot where I made the focus style of the 'crop area' visible by using a red outline.

Note that the 'Crop area' is a focusable div elements with the following attributes:

• tabindex="0"
• role="group"
• aria-label="Crop area"

which is OK, but it should not receive initial focus.

[abcd95]

I traced this, and it seems like the source might be in Gutenberg (packages/media-editor)

The crop area's tabIndex={0} and role="group" markup is correct; it should be keyboard-reachable, just not the initial focus target when the dialog opens.

The simplest fix should be to remove focusOnMount: true from MediaEditorCanvas, and add focusOnMount="firstContentElement" to the <Modal> in MediaEditorModal. This is consistent with how CreateTemplatePartModal handles focus, and with the classic image editor's focusManager() which explicitly targets the first toolbar control rather than the image canvas.

[joedolson]

This needs to be reported upstream for Gutenberg; @abcd95 would you be willing to open an issue in Gutenberg for it?

[abcd95]

Yes, absolutely. I’ve opened an ​issue in Gutenberg to report this upstream. Thank you for pointing this out.

[ramonopoly]

Fix up here: ​https://github.com/WordPress/gutenberg/pull/81541

[ramonopoly]

​Fix is merged in Gutenberg.

Unless there's a minor release, it will hit 7.2.

[joedolson]

This got a backport merge to 7.1, so I'm going to mark it as fixed in 7.1.