Allow Modal to place focus on first element within contents via new API#54590
Merged
Allow Modal to place focus on first element within contents via new API#54590
Conversation
getdave
added
[Focus] Accessibility (a11y)
getdave
changed the title
getdave
requested review from
Mamaduka,
ajitbohra and
ellatrix
as code owners
getdave
commented
Sep 19, 2023
getdave
commented
Sep 19, 2023
getdave
commented
Sep 19, 2023
getdave
commented
Sep 19, 2023
|
Size Change: +2.74 kB (0%) Total Size: 1.62 MB
ℹ️ View Unchanged
|
Contributor
Author
|
Given that 16.7 is the final release before WP 6.4 I'd really like to land this API so we can fix the Modal focus for the Block Rename feature 🙏 |
Contributor
Author
|
It's going to be pretty challenging with the current implementation though as it relies on moving the focus ref between elements. Another option could be to |
|
Flaky tests detected in 1fd06ed. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6259582718
|
ciampo
added
Backport to WP Beta/RC
and removed
Needs Dev Note
Contributor
A |
Contributor
Author
This was referenced Sep 21, 2023
Contributor
|
Late to the party, sorry. I'm not sure this is going in the right direction.
This is a common misconception and, in a way, now considered an 'old' recommendation. I've been closely following the discussion about initial focus for the native It is very important to note that after long discussion the initial focus mechanism will be changed. If no specified otherwise, the Although the above relates to the native HTML Cc @joedolson @alexsanford @andrewhayward Aside: |
Contributor
@afercia , The
Thank you for the advice. The |
mikachan
pushed a commit
that referenced
this pull request
Sep 22, 2023
…PI (#54590) * Add new firstContentElement variation to Modal * Update Story * Update e2e test * Add focus tests * Conditionally add ref * Provide comment to explain unusual code * Remove extra div element * Update docs * Tweak code comment documentation * Add test for firstElement * Refactor tests * Prefer getByRole * Improve README with additional context
Member
|
I just cherry-picked this PR to the release/16.7 branch to get it included in the next release: 76e5214 |
mikachan
removed
the
Backport to Gutenberg RC
Contributor
Lack of knowledge and uncritically adoption of (long established) wrong naming, i guess. |
ciampo
added
the
Needs Dev Note
|
Warning: Type of PR label error To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.
Read more about Type labels in Gutenberg. |
ciampo
added
has dev note
Contributor
|
Added a dev note in the PR description |
lipemat
added a commit
to lipemat/types-js-boilerplate
that referenced
this pull request
Oct 16, 2023
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What?
Adds new API to
Modalto allow focus to be placed on first element in the content on mount.Alternative to #54296
Closes #54106
Why?
As discussed in #54106 dialogs (including Modal) should ideally place focus on the first focusable element on mount. Currently all Modals find that the Close button is the first element in the DOM inside the Modal that is focusable and thus it receives focus. A11y feedback has been that this is unhelpful.
For further explanation as to how we arrived at this approach see
#54296 (comment)
How?
Conditionally places the
focusOnMountRefon the Modal contents<div>whenfirstContentElementis passed asfocusOnMountprop. This ensures the focus is attempted within the Modal's contents.Testing Instructions
Rename.inputand not onClosebuttonClosebutton and constrained tabbing is still active.Testing Instructions for Keyboard
✍️ Dev Note
The
Modal' component'sfocusOnMountprop has received an update, and it now accepts a new"firstContentElement"option. When settingfocusOnMount="firstContentElement", theModalcomponent will try to focus on the first tabbable element within theModal's content (ie. the markup passed via thechildren` prop).This is different from the pre-existing
"firstElement"option, which causes focus to go to the first element anywhere within theModal, including its header (usually the close button).Note that it is the responsibility of the consumer to ensure that, when
focusOnMount="firstContentElement", there is at least one tabbable element within theModal's children.