Choosing the block option to add a comment should move focus directly to the comment input field.

[karthick-murugan]

Fixes the 3 issues mentioned below from this githib issue #71249

• Choosing the block option to add a comment (or clicking the Comment button in the block toolbar) should move focus directly to the comment input field. (Moving focus would also trigger an announcement, as the new focus location would be announced).
• If a reply is deleted, focus should be placed in the parent comment.
• If a comment is deleted, focus should move to the next comment if there is one, the previous comment if there isn't a next comment, or the parent block if all comments are resolved

What?

This PR ensures that when users click the Comment button in the block toolbar or choose to add a comment/reply, the focus automatically moves to the comment input field. This improves the user experience by reducing the number of clicks needed to start typing.

Why?

Currently, when users initiate a comment or reply action, they need to manually click into the textarea to start typing. This creates an unnecessary extra step in the commenting workflow. Automatically focusing the input field streamlines the process and provides a more intuitive user experience.

How?

Added a shouldFocus prop to the CommentForm component

Implemented a useEffect hook that focuses the textarea when shouldFocus is true

Used proper cleanup with requestAnimationFrame and cancelAnimationFrame to prevent memory leaks

Updated both the main comment form and reply forms to use this functionality

Added proper JSDoc documentation for the new prop

Testing Instructions

Open a post or page in the editor

Select any block that doesn't have an existing comment

Click the Comment button in the block toolbar

Verify that the cursor is automatically focused in the comment input field

Video

REC-20250901184546.mp4

[github-actions]

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: karthick-murugan <karthickmurugan@git.wordpress.org>
Co-authored-by: adamsilverstein <adamsilverstein@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: joedolson <joedolson@git.wordpress.org>
Co-authored-by: jeffpaul <jeffpaul@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]

Thanks for the PR! However, I don't think the current behavior is what we intended.

In the block editor, you can move focus to adjacent blocks using the up and down keys. However, the comment form takes focus the moment a block is selected, so you can't use the up and down keys to select another block.

cbbd53c90bbf501f9b64820c222805a8.mp4

I think the comment form should only be rendered and receive focus if the user explicitly clicks the comment button from the block toolbar:

[t-hamano]

Why do we need to add this method?

[karthick-murugan]

This change was made to fix one of the e2e error. I have reverted to check if still thats the issue exists. There was some updates in that patterns.spec.js file so rebased it and then removed my changes.

[karthick-murugan]

Thanks for the PR! However, I don't think the current behavior is what we intended.

In the block editor, you can move focus to adjacent blocks using the up and down keys. However, the comment form takes focus the moment a block is selected, so you can't use the up and down keys to select another block.

cbbd53c90bbf501f9b64820c222805a8.mp4
I think the comment form should only be rendered and receive focus if the user explicitly clicks the comment button from the block toolbar:

@t-hamano Updated the issue. Here is the video

REC-20250916191756.mp4

[joedolson]

Yes, this is not the desired interaction. Selecting the 'Comment' button on a block should move directly to the comment input box; having it happen as soon as a block receives focus means that it's very difficult to reach a block to edit.

Also, in my opinion clicking the comment button should move focus to the comment container for that block, not directly to the input field. Although I think this is where the UI may need changes; there is a significant difference in intent between somebody wanting to read the comments on a block and somebody wanting to make a comment on the block.

If there are already a dozen comments on a block, and you want to read them, being landed in the input field at the end of the comments list is inconvenient; but if you want to make a comment, landing at the top of the same list is a problem.

I think what I'd want is to have focus land at the top of the container, then a visible-on-focus skip link that could be used to move focus to the input field with a label 'New Comment'. That would give both needs an effective way to reach their target.

[joedolson]

See my comment for detail on how I think this should work; but the synopsis is that this is not currently providing a desirable interaction, and needs further adjustment.

[karthick-murugan]

Yes, this is not the desired interaction. Selecting the 'Comment' button on a block should move directly to the comment input box; having it happen as soon as a block receives focus means that it's very difficult to reach a block to edit.

Also, in my opinion clicking the comment button should move focus to the comment container for that block, not directly to the input field. Although I think this is where the UI may need changes; there is a significant difference in intent between somebody wanting to read the comments on a block and somebody wanting to make a comment on the block.

If there are already a dozen comments on a block, and you want to read them, being landed in the input field at the end of the comments list is inconvenient; but if you want to make a comment, landing at the top of the same list is a problem.

I think what I'd want is to have focus land at the top of the container, then a visible-on-focus skip link that could be used to move focus to the input field with a label 'New Comment'. That would give both needs an effective way to reach their target.

Thank you @joedolson for the detailed feedback. I understand now that the current behavior is not providing the right interaction, and that the preferred approach would be:

On clicking the comment button, move focus to the comment container for the block (not directly into the input field).

Provide a visible-on-focus skip link within the container, labeled something like "New Comment," that allows users to move directly to the input field if that's their intent.

This makes it possible both to read existing comments easily and to add a new comment when needed.

Before proceeding with an implementation, I'd like to confirm whether other contributors agree with this direction, or if there are alternative suggestions to consider.

[t-hamano]

clicking the comment button should move focus to the comment container for that block, not directly to the input field.

I agree with this. Additionally, we may need to apply a listitem role to each thread, wrapping all of the threads in an element with the list role.

Google Docs example: Also note that when you click on the thread container, a comment form appears.

b76055538b97cd1ea7d4adcfb7c78c6f.mp4

Personally, I don't think we need to solve all the a11y issues in one PR. The first improvement might be to simply focus the thread container itself when you click the comment button in the toolbar. I think it would be good to improve it gradually, and it would also make it easier to review.

[adamsilverstein]

@karthick-murugan - the accessibility issue now has a bunch of sub issues - one for each of the issues identified that need addressing- #71249. Can you please break this PR apart into separate PRs to address the issues one at a time? that will make them easier to track and review.

Specifically:

• Choosing the block option to add a comment (or clicking the Comment button in the block toolbar) should move focus directly to the comment input field. (Moving focus would also trigger an announcement, as the new focus location would be announced). - Block Comments Accessibility: block comment sidebar is expanded, but the screen reader doesn't announce it #71675
• If a reply is deleted, focus should be placed in the parent comment. - Block Comments Accessibility: reply or comment deleted, focus needs adjusted to relevant comment #71678
  If a comment is deleted, focus should move to the next comment if there is one, the previous comment if there isn't a next comment, or the parent block if all comments are resolved - Block Comments Accessibility: deleting comment loses focus #71679

Thanks!

[adamsilverstein]

needs breaking apart, doing too much currently

[t-hamano]

I agree, I think a small PR is generally a good thing. At some point, we'll probably also need E2E tests to prevent regressions. cc @Mamaduka

[karthick-murugan]

Since the current approach does not align with the desired interaction and this branch has accumulated multiple conflicts, I am closing this PR. As advised by @adamsilverstein and @t-hamano, I have created a separate PR to address the issue with the correct approach.

[adamsilverstein]

Thank you @karthick-murugan!