Block Comments: Accessibility improvements

[t-hamano]

This is a sub-issue of #66377

The block comment sidebar has many areas that need improvement from an accessibility perspective. The main areas for improvement are:

• It cannot be operated using only the keyboard.
• It sometimes loses focus, so screen reader users may not understand what is happening.

I believe we need to work with the accessibility team to resolve these issues.

Below are the issues I found.

• Click the Comment button in the block toolbar:
  • The block comment sidebar is expanded, but the screen reader doesn't announce it.
  • The Options button is focused. Some element in the sidebar should be focused.
• Add a comment:
  • The screen reader reads `Comment added successfully.' but the focus is lost.
• Click the delete button in the action dropdown:
  • The screen reader reads Select an action menu button collapsed subMenu / Add Post ‹ gutenberg — WordPress document / dialog. This is redundant. The screen reader should just read dialog.
• Click the "Yes" button in the delete modal:
  • The screen reader reads `Comment deleted successfully. ' but the focus is lost.
• The comment sidebar shows {count} more replies.. text when there are a lot of replies. The hidden comments can be expanded by clicking with a mouse, but can not be expanded because there is no focusable button to expand them.

[joedolson]

Thanks, @t-hamano! I was planning on looking at this block this morning anyhow, so I'm going through and reproducing to add comments. I'm starting with your comments, in order, and responding.

Click the Comment button in the block toolbar:

1. Clicking the comment button doesn't move focus or announce anything.

Choosing the block option to add a comment should be considered as initiating an action, and focus should move to the comment box. I would suggest it should move directly to the comment input, as the clear intended action is to write a comment.

Moving focus would also trigger an announcement, as the new focus location would be announced.

2. There's no mechanism to navigate back to the block you commented on.

There should be a link in the comment area where you can return to the selected block. Otherwise, it's going to be very labor intensive for a keyboard user to review comments.

Add a comment:

1. As observed, focus is lost. Focus is not lost when adding a comment reply, however. The loss of focus is fairly significant, since the next tab after loss of focus is the 'Resolve' button on the first comment. If you think you're still on the same comment, this might lead you to take the wrong action.

Click the delete button in the action dropdown

1. I don't get the same announcement; I'm only getting "Select an action menu button collapsed subMenu" as the selection. But I'm slightly unclear at what point you got this announcement. What I notice is that there's a focus loss after deleting a comment, and for me that dropped me in the adminbar; but you may have been dropped somewhere else. Focus loss ends up being delegated to the browser to identify the new location, so that can be highly variable.

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.

The comment sidebar shows {count} more replies.. text when there are a lot of replies

You can expand the list by picking the options menu; clicking on anything within the comment box triggers the expansion. However, there's absolutely nothing intuitive for a user about needing to click "Select an action" in order to read the rest of the comments. Making the "n more replies" text clickable would make this much more intuitive.

Additional issues discovered on the way:

While exploring all of this interactivity issues, I also identified a significant accessibility problem with labeling.

All comment inputs have the same label: "Comment". This provides no context for what your comment is connected to. For a screen reader user, this makes the feature largely useless: even working through the interactivity challenges above, the user ends up having no way to know what any comment is about within their document.

If there was a solid navigational tie between the block and the comment, that would greatly help; but the labels need to be differentiated, as well. They don't need to reference the block content; they just need to be different, so that the user can clearly identify if they have navigated to a different comment. E.g., "Comment (Paragraph 1)" allows the user to know if they have accidentally tabbed forward into "Comment (Paragraph 2)", so that they can tell they are now in a different context.

There is also only a minimal connection between a selected comment block and the block it's associated with, which makes it difficult to visually relate these. I know that the association is between the selected block and the selected comment, but I think a stronger association would be more intuitive.

[joemcgill]

Thanks for creating this sub-issue, @t-hamano! I agree that we want to make sure that an initial version of this feature targeted to be included in WP 6.9 should address a11y concerns that we're aware of.

@joedolson I appreciate your insight to help prioritize a11y improvements based on severity and to recommend approaches to resolve them. To be clear, I do NOT expect that folks from the a11y team should be responsible for implementing these improvements, but contribution from folks with specific experience are always welcome!

[t-hamano]

@joedolson Thank you for the great feedback! If anyone is interested in this issue, I think we can work on improving it by following the guidelines you suggested.

[adamsilverstein]

Excellent feedback @joedolson - thank you for taking the time to review.

There should be a link in the comment area where you can return to the selected block. Otherwise, it's going to be very labor intensive for a keyboard user to review comments.

Note - this issue is already being worked on in #71308.

I'm going to try to list all the points to be addressed here as a checklist, if this looks right we can iterate thru them here or break them out into separate sub-issues.

I know that the association is between the selected block and the selected comment, but I think a stronger association would be more intuitive.

Google Docs helps here - when not in the pinned comment sidebar mode - by vertically aligning the comments with the paragraph they are associated with.

Accessibility issues to address

• 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).
• There's no mechanism to navigate back to the block you commented on (see Block Comments: Highlight the related block #71308)
• Ensure focus is not lost when adding a comment. (question: does focus move the the comment? the input element disappears so my assumption is focus would move to the comment)
• 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
• Make the "n more replies" text clickable, showing the remaining comments Block Comments: Make "n more replies" text clickable for accessibility #71387
• Improve comment input labels. They need to be unique, so that the user can clearly identify if they have navigated to a different comment. E.g., "Comment (Paragraph 1)" allows the user to know if they have accidentally tabbed forward into "Comment (Paragraph 2)", so that they can tell they are now in a different context.

@joedolson & @t-hamano - please let me know if I missed anything in the list so far!

[karthick-murugan]

@adamsilverstein - This PR #71444 covers few of the Accessibilty issues that is mentioned above.

• 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