Closed Bug 1894271 Opened 5 months ago Closed 4 months ago

Errors on the Select Translations panel are not announced when they appear

Categories

(Firefox :: Translations, defect, P3)

Desktop
All
defect

Tracking

()

VERIFIED FIXED
128 Branch
Accessibility Severity s3
Tracking Status
firefox128 --- verified

People

(Reporter: ayeddi, Assigned: nordzilla)

References

(Depends on 1 open bug)

Details

(Keywords: access)

Attachments

(2 files)

STR:

  1. Ensure browser.translations.select.enable is set to true in the about:config
    • to trigger errors intermittently, activate the Chaos mode via: browser.translations.chaos.errors=true and then setting browser.translations.chaos.timeoutMS to 1000 (1 sec) or similar
  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. When a Translation panel opens with an error, observe the screen reader announcement
    • If the error state is not shown after 1 sec (or other timeout that was set in the custom pref), re-open the panel by pressing Esc and repeating steps 4-6.

Expected:

  1. The text of error is announced by a screen reader.

Actual:

  1. The text of error is added to the panel but it is not announced by the assistive technology. The focus is set to the Try again button by default but it is not clear why it should be tried again. Users of screen readers would not be aware of the error, unless they'll navigate backwards in browse mode of a screen reader.

Remediation:

  1. Either add tabindex="-1" to the error container and place the focus on it by default, or
  2. Add aria-describedby attribute to the Try again button and reference the id of the error container, i.e. aria-describedby="select-translations-panel-translation-failure-message-bar". More than one id could be referenced when separated with a space
Severity: -- → S3
Priority: -- → P3
Depends on: 1894535
See Also: → 1894780

While the bug 1894535 may have resolved the issue in general, there are cases of errors, i.e. the one captured on the screenshots, where the error is rendered at the same time when the new view of the dialog is created (vs. being un-hidden from the existent DOM), thus the text of the error would not be announced even when it's an alert.

Anna, given the fix of bug 1894535, should we reduce the severity here?

Oh sorry, I thought this was s2, but I see it is already s3.

Assignee: nobody → enordin

This patch ensures that error states in the SelectTranslationsPanel
announce their messages to screen readers when the error occurs.

Attachment #9403342 - Attachment description: WIP: Bug 1894271 - Ensure SelectTranslationsPanel errors are announced r=ayeddi → Bug 1894271 - Ensure SelectTranslationsPanel errors are announced r=ayeddi

The behavior may have changed so I made an update on how the screen readers read the error panels in the latest Nightly:

The behavior observed in Nightly v128.0a1 on Win10/11+NVDA:

  1. "There was a problem translating" error panel: "There was a problem translating. Please try again." message is being read, then it reads something about the text selected behind the panel, then it verbalizes "dialog" and "Try again button".
  2. "Unsupported language" panel: The Screen Reader does not read the Warning message because the focus falls on the language drop-down.
  3. “There was a problem loading languages” panel: could not be triggered using the provided method.

The behavior seen in Nightly v128.0a1 on MacOS+VoiceOver:

  1. "There was a problem translating" error panel: the error message is not being read. Vocalization is interrupted.
  2. "Unsupported language" panel: The Screen Reader does not read the Warning message, but starts by reading the initial selection incorrectly, then it reads the language drop-down.
  3. “There was a problem loading languages” panel: could not be triggered using the provided method.

The behavior seen in Nightly v128.0a1 on Ubuntu22+ORCA:

  1. "There was a problem translating" error panel: the error message is not being read, only the "Try again" button.
  2. "Unsupported language" panel: The Screen Reader does not read the Warning message, but starts by reading the initial text selection incorrectly, then it reads the language drop-down.
  3. “There was a problem loading languages” panel: could not be triggered using the provided method.
Pushed by enordin@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0b974c4956aa Ensure SelectTranslationsPanel errors are announced r=translations-reviewers,nlapre
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 128 Branch
Depends on: 1900006

I can confirm that NVDA and ORCA do read the 3 errors automatically when they are displayed.
VoiceOver reads the "Problem translating" and "Language unsupported" errors automatically, but it does not read the "Problem loading languages" error automatically, however, the user can navigate and read the whole panel using VO+Left/Right.

Bug 1900006 was logged for the remaining use case for MacOS+VoiceOver and the "Problem loading languages" error panel and the current report will be closed.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: