Skip to content

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
@github-actions
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