1902662 - VoiceOver does not announce accessible name of panels when they are opened and focused

Status: NEW

(Firefox :: Disability Access, defect)

Description

[Daniel Bodea [:danibodea]]

Note

• This is a follow-up from bug 1894094; The Panel has an accessible name, but VoiceOver does not read it when the panel is opened.
• VoiceOver does, however, read the "Translation Beta" name when using the VoiceOver specific commands (VO+SHIFT+UP/DOWN) to navigate out of the panel and back in.

Found in

• Nightly v129.0a1

Affected versions

• Nightly v129.0a1
• Beta v128.0b3

Tested platforms

• Affected platforms: MacOS, Ubuntu (logged in a separate bug)
• Unaffected platforms: Windows

Steps to reproduce

1. Enable VoiceOver.
2. Launch the browser.
3. Ensure the feature is enabled:
   browser.translations.select.enable = TRUE
4. Load a webpage that is displayed in a different language than the browser.
5. Open the context menu on a selection of text, a link or an image.
6. Select the Translate option from the menu.
7. Observe the announcement of the panel by the VoiceOver.

Expected result

• The purpose of the dialog (its accessible name) is announced by a screen reader.

Actual result

• The accessible name is not announced by the screen reader.
• It may be interrupted by the announcement of the translation process completion. (This is as assumption)

Regression range

• Not a regression.

Additional notes

• The accessible name is announced when the user navigates outwards using VoiceOver specific commands (VO+SHIFT+UP) or back inwards (VO+SHIFT+DOWN).
• The panel does have an accessible name implemented in bug 1894094.

Comment 1

[Anna Yeddi [:ayeddi]]

This seems to be a Fx-wide issue with VoiceOver not announcing an accessible name of other panels that are programmatically labeled, i.e. Edit Bookmark, thus moving the bug into the A11y component.

Comment 2

[Anna Yeddi [:ayeddi]]

Attachment: Edit bookmark panel with accessible name that is not announced by VoiceOver

Comment 3

[Anna Yeddi [:ayeddi]]

STR for Edit Bookmarks case:

1. Ensure VO is running and navigate to a page that is bookmarked (or bookmark one with cmd+D shortcut)
2. Navigate to Edit this bookmark control in the URL bar or use cmd+D shortcut to open the panel
3. Confirm the panel is opened and observe the VoiceOver announcement

Expected:

1. "Edit bookmark" programmatic label of the panel would be mentioned by VO

Actual:

1. VO reads the label and role of the auto-focused element and mentions that there is a new window, not announcing the label of the panel

Comment 4

[Anna Yeddi [:ayeddi]]

Also, the announcement is missing the description of the panel/document provided with the aria-describedby, i.e. for the Select Translations panel, it includes the Manage Settings button (since bug 1901314 fix) which is, for instance, announced by NVDA as expected.

Comment 5

[Anna Yeddi [:ayeddi]]

Not sure if this is related, but it seems that the group labels are not announced by VoiceOver, i.e. on about:addons > Extensions > any extension details > Allow automatic updates is the label for the group, but when focusing a radio button within the group with Tab in group is announced but the label is missing from the VO output. VO+Up announces the label. (same results when those radio buttons are in the radiogroup). A11y Inspector shows the programmatic label as expected.

Comment 6

[James Teh [:Jamie]]

Does VO read the group labels when tabbing to the "inside" button in this test case?

data:text/html,<button>outside</button><fieldset><legend>Container</legend><button>inside

How about in other browsers?

What about this test case?

data:text/html,<button>outside</button><div role="group" aria-label="Container"><button>inside

Comment 7

[James Teh [:Jamie]]

Note that the "Edit Bookmark" panel has a (probably implicit) role of group. It probably should be (explicitly) dialog.

The select translations panel has a role of dialog, but it actually is missing a label, even on Windows.

Comment 8

[Anna Yeddi [:ayeddi]]

(In reply to James Teh [:Jamie] from comment #6)

Does VO read the group labels when tabbing to the "inside" button in this test case?

data:text/html,<button>outside</button><fieldset><legend>Container</legend><button>inside

How about in other browsers?

What about this test case?

data:text/html,<button>outside</button><div role="group" aria-label="Container"><button>inside

Thank you for the test cases, Jamie!

VO does announce them in the content in 3 browsers. The results are the following:

1. Fieldset test case:
   1. Nightly, Chrome: announce label > role > group_label > group_role (Inside, button, Container, group)
   2. Safari (release): announces label > role > group_label > group_label > group_role (Inside, button, Container, Container, group)
2. ARIA group test case:
   1. all announce label > role > group_label > group_role (Inside, button, Container, group)

(In reply to James Teh [:Jamie] from comment #6)

Note that the "Edit Bookmark" panel has a (probably implicit) role of group. It probably should be (explicitly) dialog.

The select translations panel has a role of dialog, but it actually is missing a label, even on Windows.
Let me play around with these on mac and Win, I'll keep the NI

Comment 9

[James Teh [:Jamie]]

Curious. If those groups are being announced, the bookmark panel group should be announced as well... since it's also exposed as a group by the a11y engine, but that clearly isn't the case. I'm not quite sure why though.

Comment 10

[Anna Yeddi [:ayeddi]]

I still need to play around the grouping announcements, as discussed with Jamie additionally, so I'm keeping the NI, but removing the access keyword since the bug is now in the component under the Accessibility team's care.

Comment 11

[James Teh [:Jamie]]

Eitan/Morgan, one thing I'm not sure about that might be worth looking into is the relationship between the pop-up NSView and our LocalAccessible for that pop-up.

As I understand it, pop-ups get their own widget, which I think maps to nsChildView on Mac. But I don't see anything in nsChildView about the possibility of the Accessible being anything other than a document. nsChildView::GetDocumentAccessible only calls nsBaseWidget::GetRootAccessible, which can only return a RootAccessible... but a pop-up isn't a RootAccessible. So what happens with the nsChildView for the pop-up widget in this case? Does that just not matter somehow or am I missing something? I'm wondering whether we're not associating things correctly, so VoiceOver doesn't get information it needs about the role, etc. of the pop-up.

Comment 12

[Anna Yeddi [:ayeddi]]

Redirecting the NI to my colleagues who are experts in the platform code that may be related (per Jamie's comment #11)

Comment 13

[Eitan Isaacson [:eeejay]]

The native popup dialog does not contain the accessible tree, instead it remains in the main window's hierarchy. That is a known pattern and it works mostly fine in other UI. I don't think that is bad in itself or causing this issue.

I see two issues:

1. Why is the panel[role=alertdialog] not directly labeled? I tried labeling it but it doesn't work. But before digging further, is there a reason? That would be one thing i would change. Also why is it's div child marked as a document?
2. As mentioned in the bug report any helpful VO speech is interrupted when the text gets replaced in the translation box, so the above is a moot point. It also just says the first word in the translation, which is a little concerning. I wonder if we can make that text replacement less chatty somehow.