Inline comments popup : Buttons don’t have an accessible label.

Issue Summary

In 'Add inline comments' popup, the following buttons doesn’t have an accessible label.

• Next comment (N)
• Previous comment (P)
• More options (...)
• Close sidebar (])

Issue id: 727101

Steps to Reproduce

1. Navigate to any page in confluence.
2. Navigate to any text content which has inline comments (Highlighted in yellow colour) inside main region & activate it.
3. Navigate inside inline comments popup box which appears on the right side of the page.
4. Navigate to the buttons such as  'Next comment', 'Previous comment'.
5. Start VoiceOver & press ctrl + opt + U to open the list of elements.
6. Navigate to form controls panel and observe the label of the buttons.

Actual Results

While navigating with screen reader turned on, In 'Add inline comments' popup when user navigate to the buttons such as 'Next comment', 'Previous comment", "More options (...)", & "Close sidebar", etc screen reader doesn’t announce any label for the button. Although the title are provided to the buttons but sometimes they are also not announced by screen reader software.

Also when screen reader users pulls up the buttons list in VoiceOver (ctrl + opt + U) on the page, the label of these buttons is not shown correctly inside the buttons panel.

This makes screen reader users difficult to understand the purpose of the button.

Expected Results

The buttons should have an accessible label in the code. Provide the buttons an accessible label via aria-label attribute. 

For example:

<button aria-label="Next comment (N)">
<button aria-label="Previous comment (N)">
<button aria-haspopup="true"  aria-controls="ic-menu-items" aria-expanded="false" aria-label="More options">
<button aria-label="Close sidebar (])">

Also the aria-describedby attribute should be removed from the button elements. It appears in the code on mouse hover or keyboard focus.

Screenshot

Screen recording

Screen Recording 2022-03-03 at 3.41.21 PM.mov

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available