Block Comments: Add focus on Comment deletion

[karthick-murugan]

What?

Closes #71679

Closes Part of #71678

This is a split PR of #71444 (comment) as mentioned by @adamsilverstein , @t-hamano

( 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 )

• focus should move to the next comment if there is one
• focus should move to the previous comment if there isn't a next comment
• focus should move to the parent block if all comments are resolved

Why?

Currently, when users delete a comment in the collaborative sidebar, focus is lost and users need to manually navigate to find the next relevant element. This creates accessibility issues and poor user experience, especially for keyboard users and screen reader users who rely on focus management for navigation.

This addresses the accessibility requirement from issue #71249 where deleting a comment should move focus 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.

How?

• Modified onCommentDelete function: Added an optional onFocusNext parameter to handle focus management after deletion
• Added handleCommentDeletionFocus function: Implements the focus priority logic:
  1. Focus next comment if available
  2. Focus previous comment if no next comment exists
  3. Focus parent block if no other comments remain
• Updated component prop passing: Thread and CommentBoard components now pass the focus management function to deletion handlers

Testing Instructions

1. Open a post or page in the editor
2. Add multiple comments to different blocks using the collaborative sidebar
3. Delete a comment that has other comments after it - verify focus moves to the next comment
4. Delete the last comment in a thread - verify focus moves to the previous comment
5. Delete the only comment in a thread - verify focus moves to the parent block
6. Test with both main comments and replies to ensure consistent behavior

Video

REC-20250922131811.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: 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.

[adamsilverstein]

does this actually move focus to the block? I thought it was designed to only flash the block and not shift focus?

[karthick-murugan]

@adamsilverstein – Thanks for pointing that out. When we say focus the parent block, should this mean actually moving editor focus to the block (so it becomes the selected block in the editor), or is a visual highlight/flash sufficient? In the earlier PR we went with flashing the block for visibility, so I continued in that direction.

Just to clarify my understanding: without an explicit highlight, the selected block can still be identified by the presence of its toolbar above the block. Would that be considered acceptable, or should we explicitly move focus so the block is selected programmatically?

[adamsilverstein]

On this ticket we are trying to make the feature more accessible for keyboard users. You should be able to tab around to quickly get to the fields you need. So on this case we actually want to change the focus rather than only highlighting the block as in the other ticket.

[karthick-murugan]

@adamsilverstein - I’ve rebased and updated the branch based on your feedback, and also recorded a video to demonstrate the changes. Please take a look when you get a chance.

REC-20250924190526.mp4

[adamsilverstein]

Hit @karthick-murugan - I tested this out using the keyboard and overall this looks good! I noticed one issue:

• When deleting the last comment, focus moves to the previous comment, but at the end rather than the top of the comment. If I hit tab next, I wind up on the publish panel hidden link. It is only a problem when deleting the last comment: deleting a non last comment properly puts me at the top of the next comment so i could tab forward to the input field.

The other parts seem to work well. I updated the description to reflect your progress.

One other bug I noticed that I think is unrelated:

• Once I delete a block comment, I can no longer add a comment to that block. Even after saving and reloading the editor I still cannot add a new comment. The old comment is also completely gone in the UI, but comments can no longer be added.

I can open a separate issue for this.

[adamsilverstein]

One other bug I noticed that I think is unrelated:

• Once I delete a block comment, I can no longer add a comment to that block. Even after saving and reloading the editor I still cannot add a new comment. The old comment is also completely gone in the UI, but comments can no longer be added.

I can open a separate issue for this.

Opened: #71882

[t-hamano]

Thanks for the PR!

What's needed here is to address the focus loss issue itself. Visually focusing on the comment alone doesn't tell screen reader users where focus has been moved. When solving accessibility issues, it's always a good idea to check that a screen reader reads it correctly.

I hope #71883 helps move this PR forward.

[karthick-murugan]

@adamsilverstein - Updated all the issues and also taken a latest video of it. Please have a look.

REC-20250925130405.mp4

[adamsilverstein]

@karthick-murugan the screencast looks better, thanks! I am reviewing this and #71883 lands to see how that might impact this PR. We may want to land it first.

[karthick-murugan]

Closing this PR due to multiple conflicts that were challenging to resolve. I’ve opened a new PR here: #71974