1894094 - Select Translations panel is missing accessible name

Status: VERIFIED FIXED

(Firefox :: Translations, defect, P3)

Description

[Anna Yeddi [:ayeddi]]

Attachment: Accessibility Inspector results for the Translations alertdialog panel

STR:

1. Ensure browser.translations.select.enable is set to true in the about:config
2. Ensure a screen reader is running
3. Navigate to a page in a language different from the OS, i.e. for English machine: data:text/html,<p lang="es_ES">Como estas?</p> or https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B8%D1%8F_%D0%BB%D0%BE%D0%B6%D0%B5%D0%BA
4. Select a text (using mouse or by following the NVDA 2024.1 guide for Native Selection Mode) and open a context menu/right click
5. Navigate to and activate Translate Selection to English
6. Confirm the dialog is opened and observe the screen reader announcements:

Expected:

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

Actual:

1. Only the dialog role itself is announced by screen readers, but the label for the dialog is missing. Users of assistive technology may be confused what is the purpose of the dialog and why did it open.

Remediation:

1. Add to the role=alertdialog container an aria-labelledby reference to the <h1> ID attribute that would provide an accessible name - Translations BETA or Translations
2. (bug 1894098) To the dialog container, also add aria-describedby reference to the ID attribute of the dialog itself - this would allow a screen reader to also read the content of the dialog to a user while the focus is placed not at the top of the dialog, without the need to reverse navigate it.

Comment 1

[Anna Yeddi [:ayeddi]]

Attachment: Select Translations panel was announced just as "dialog" by NVDA

Comment 2

[Anna Yeddi [:ayeddi]]

Attachment: Bug 1894094 - Ensure accessible names are provided for Translations panels. r=ayeddi,#translations-reviewers!

While the role='alertdialog' does not announce the label, we could use the inner role='dialog' elements to communicate the label for the currently opened panel.

Comment 3

[Erik Nordin [:nordzilla]]

I'm taking over this bug after talking with Anna.

I will respond to my own blocking review feedback, tag her as a co-author, and re-submit for review.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/39802fa00241
Ensure accessible names are provided for Translations panels. r=translations-reviewers,ayeddi

Comment 5

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/39802fa00241

Comment 6

[Daniel Bodea [:danibodea]]

Neither of the screen readers read the panel's title (Translations BETA or Translations) in the latest Nightly v128.0a1 (2024-05-30).
Reopening the report. Please mention if the current expected behavior is different than the one described in comment 0. Thanks!

Comment 7

[Erik Nordin [:nordzilla]]

I'm a little confused about this being reopened because Anna confirmed for me during the code review process that things were being announced correctly.

Anna, would you mind taking a look at this again in the latest Nightly?

Comment 8

[Anna Yeddi [:ayeddi]]

Attachment: Accessibility Inspector results for the Translation panel on macOS with the current Nightly

The programmatic label issue was resolved - the Accessibility tree in Devtools (screenshot from the macOS with the current Nightly is attached) does prove that the document (the wrapper of the panel's content) is programmatically labeled as Translations.

VoiceOver is announcing the label (document Translations), if navigating to the panel wrapper from the pre-focused <textarea> with VO+shift+Up arrow. This announcement got interrupted because the translating placeholder is being focused right after the panel is opened. With the bug 1901314 patch, the (added) description of the document is being announced more clearly by VoiceOver, but, as I mentioned in that bug's description, this may be a VO or a platform bug and I'll be investigating it further.

On Win with NVDA the label is also announced and, with the bug 1901314 patch now landed, it provides expected information when the panel opens too (the screenshot will be attached in the next comment).

@Daniel, when the new Nightly would be build (with the bug 1901314 patch in it), would you be able to confirm the title of the panel is announced by NVDA on Win? I hope Orca on Linux would follow the suite (and I'll mark the VO bug here as blocking if it's confirmed to be a Gecko issue)

Comment 9

[Anna Yeddi [:ayeddi]]

Attachment: Screenshot of the Select Translations panel announcement by NVDA with the Accessibility Inspector output with patch for bug 1901314 applied

The panel is announced by NVDA as:

dialog
Translations Beta, dialog, Manage translation settings

(panel's role > label > role > description)

Comment 10

[Daniel Bodea [:danibodea]]

Hi Anna and thank you for the testing and explanations. My test results in Nightly v129.0a1 from 2024-06-12:

• MacOS+VoiceOver:
  I can confirm that, while the Translations Beta panel is NOT announced automatically when the panel is opened (probably interrupted by the translation process completion), its name IS announced as "Translations Beta" when navigating from the prefocused <textarea> with VO+SHIFT+UP vocalizing "Out of Translations Beta" and is announced when navigating back inside with VO+SHIFT+DOWN vocalizing "In Translation Beta, 11 items, Translation". This does prove that the panel has an accessible name.

• Windows10+NVDA:
  I can confirm that the Translation Beta panel name is announced when opening it:
  "Doc..." <interruption> "Alert translation complete. Dialog. Translation Beta document, Manage Translation Settings. From <origin language> to <destination language> edit read-only multi-line translating."
  This does prove that the panel has an accessible name.

• Ubuntu22+ORCA:
  The Translation Beta panel name is not announced at any point.
  The behavior of ORCA when the panel is opened: "<reads part of origin selection>, from <origin language> to <destination language> read-only entry translating, focus mode, alert translation complete."

Based on my understanding of screen reader use, my conclusion is as follows:

1. MacOS+VoiceOver does not announce the panel's name automatically, but the panel's name can be observed when navigating out of the panel and/or back in with VoiceOver specific controls. This would count as a partial fix considering the expected result in comment 0.
2. Windows10+NVDA vocalized the panel's name as Translation Beta document. This would count as a complete fix.
3. Ubuntu22+ORCA does not announce the name of the panel in any situation. This would count as not fixed.

To answer your specific question from comment 8, Yes, the Translation beta name is vocalized by NVDA when opening the panel, but not by ORCA or VoiceOver. How should we address this situation forward? Thank you!

Comment 11

[Daniel Bodea [:danibodea]]

The previous testing results do prove that the panel has an accessible name, however, it is not announced by the VoiceOver and ORCA screen readers when the panel is opened, while it is properly announced by NVDA.
We have decided to log the remaining issues separately (bug 1902662 and bug 1902665). As a result, we can close the current report. Erik, would you please revert the bug's status to fixed so we can verify it? Thanks!

Comment 12

[Erik Nordin [:nordzilla]]

Thank you for subdividing these into specific bugs! I really appreciate all of the organization around this.

Comment 13

[Daniel Bodea [:danibodea]]

Closing this report based on the last comments. Thank you!

Comment 14

[Anna Yeddi [:ayeddi]]

(In reply to Daniel Bodea [:danibodea] from comment #11)

The previous testing results do prove that the panel has an accessible name, however, it is not announced by the VoiceOver and ORCA screen readers when the panel is opened, while it is properly announced by NVDA.
We have decided to log the remaining issues separately (bug 1902662 and bug 1902665). As a result, we can close the current report. Erik, would you please revert the bug's status to fixed so we can verify it? Thanks!

Thank you very much, Daniel, for filing the follow up bugs! I chatted with the team and we suspect they may be Gecko and/or the VO/ORCA bugs. I'll comment in these bugs

Comment 15

[James Teh [:Jamie]]

(In reply to Anna Yeddi [:ayeddi] from comment #8)

The programmatic label issue was resolved - the Accessibility tree in Devtools (screenshot from the macOS with the current Nightly is attached) does prove that the document (the wrapper of the panel's content) is programmatically labeled as Translations.

It is indeed. However, I suspect Orca and VoiceOver don't care about the document. They care about the dialog, since that is more semantically relevant for a container like this. And the dialog still has no label.