Skip to content

Fix: Fix focus shift on opening of modal popup in templates #69711

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

Sourav61
Copy link
Contributor

What?

Closes #69708

This PR ensures that when a modal is opened, the focus shifts to the first interactive element inside the modal, such as the close button or an input field.

Why?

Currently, the focus behavior in some modals is inconsistent. In some cases, the parent container is not focusable due to tabindex=-1, preventing proper keyboard navigation. This fix ensures that focus lands on the first interactive element when the modal opens, improving accessibility and user experience.

How?

  1. Used querySelector to find the first interactive element (button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])).
  2. Wrapped the focus shift inside a setTimeout to ensure DOM readiness.
  3. Added cleanup to useEffect to prevent memory leaks.

Testing Instructions

  1. Open the WordPress site editor.
  2. Click on a button that triggers a modal (e.g., "Add Template -> Custom Template").
  3. Verify that focus automatically moves to the first interactive element in the modal.
  4. Navigate using the keyboard (Tab and Shift + Tab) to confirm expected behavior.

Screenshots or screencast

modal-focus-shift-issue.mp4

Fix focus shift on modal popup to first interactive element in modal
Copy link

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: Sourav61 <sourav08@git.wordpress.org>
Co-authored-by: Mayank-Tripathi32 <mayanktripathi32@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@t-hamano t-hamano added [Type] Bug An existing feature does not function as intended [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Feature] Site Editor Related to the overarching Site Editor (formerly "full site editing") labels Mar 27, 2025
@t-hamano t-hamano self-requested a review April 3, 2025 08:50
Copy link
Contributor

@t-hamano t-hamano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR!

The approach itself looks good, but I think using setTimeout and clearTimeout is a bit hacky approach. Additionally, the ref is applied to the Modal component itself, the first focusable element would always be the modal close button. Ideally, the first form element should have focus.

Taking a custom template as an example, we should be able to approach it like this:

function AddCustomGenericTemplateModalContent() {
	// ...
	const titleInputRef = useRef( null );
	useEffect( () => {
		if ( titleInputRef.current ) {
			titleInputRef.current.focus();
		}
	}, [] );

	return (
		<form>
			<VStack spacing={ 6 }>
				<TextControl
					ref={ titleInputRef }
					label={ __( 'Name' ) }
				/>
				{/* ... */}
			</VStack>
		</form>
	);
}

This approach arhicvies the following points:

  • No need to use setTImeout and clearTimeout
  • No need to try to find focusable element

@t-hamano
Copy link
Contributor

t-hamano commented Jun 4, 2025

Hi @Sourav61, to fully resolve #69708, we need to implement the back button as well as fix focus loss. It would be better to move forward with #70091.

I'd like to close this issue, but thank you for your efforts!

@t-hamano t-hamano closed this Jun 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Site Editor Related to the overarching Site Editor (formerly "full site editing") [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Template: focus loss when creating custom template
2 participants