Site Editor: Standardize initial focus of the Actions modal dialogs (no autofocus)

[afercia]

Description

In the Site Editor, various editable objects have an associated `Actions' button. Some of the availeble Actions open a modal dialog.

Initial focus on these dialogs is inconsistent: sometimes it is set to the modal dialog container itself, sometimes on an input field within the modal dialog. Examples:

Creating a new pattern: initial focus is on the modal dialog:

Renaming a menu: initial focus is on the modal dialog:

Creating a new page: initial focus is on the page title input field:

This is inconsistent. There should be no surprises for users, initial focus should behave consistently.

I can partly understand why initial focus is set to the Page title when creating a new page: That's the main required action. But then, it should work the same way when creating a Pattern: entering the patter nname is the main required action.

From an accessibility perspective, there are pros and cons in the two different behaviors:

• Auto-focusing the control related to the main action makes things faster.
• On the other hand, it skips any other content placed before the focused control. Sighted keyboard users might be forced to Tab backwards to get to that content.
• Screen reader users may even have no clue there's some more content before the focused control: they find themselves dumped in the middle of a form, potentially without context..
• There are legitimate cases where there's no 'main' action. In these cases, focus should be set on the modal dialog itself.

I'm not sure managing initial focus on a case by case basis would be the best option. In my opinio, the best option would be to set initial focus on the modal dialog itself. Advantages:

• Standardized behavior, no surprises: all modal dialogs work the same way.
• Content is not skipped: all content can be navigated with keyboard and screen readers in a natural order.
• Mobile: auto-focusing an input field will trigger the on-screen keyboard to appear automatically, which is always a pretty confusing experience.

More importantly, auto-focusing controls should be avoided. There are good reasons why the jsx-a11y/no-autofocus rule checks for that. In very limited cases auto-focusing may be useful but this is not one of them. In this case, disabling the eslint rule seems less than ideal: Cc @jeryj @ramonjd

gutenberg/packages/edit-site/src/components/add-new-page/index.js

Line 76 in 032b261

autoFocus

See the conversation on the PR that introduced autoFocus in the create new page modal dialog.

There's a total of 8 occurrences of jsx-a11y/no-autofocus in the codebase:

• 5 of them are in *native.js files: I'd leave these cases to others who are interested in contributing to the React Native editor for mobile.
• There are a few more occurrences of the autoFocus attribute in other *native.js files.
• The only 3 occurrences found in the non-mobile editor should be audited (will create a follow-up).

Step-by-step reproduction instructions

• Go to the Site Editor and open the following modal dialogs:
• Design > Navigation > Any menu > Actions > Rename
• Design > Pages > Draft a new page (the + icon button)
• Design > Patterns > Create pattern (the + icon button) > Create pattern
• Design > Patterns > Create pattern (the + icon button) > Create template part
• Design > Patterns > My patterns > Action button of one of the listed patterns > Rename
• Observe that only the 'Draft a new page' modal dialog uses autofocus for the page title input field.

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