1866257 - NVDA/JAWS/ORCA do not read the webcompat reporter's confirmation message

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Daniel Bodea [:danibodea]]

Found in

• Beta v121.0b2

Affected versions

• Nightly v122.0a1
• Beta v121.0b2

Tested platforms

• Affected platforms: Windows 10/11 + JAWS/NVDA; Ubuntu 22 + ORCA.
• Unaffected platforms: MacOS + VoiceOver (the messages can be read using CTRL+ALT+UP/DOWN)

Steps to reproduce

1. Launch JAWS, then Firefox
2. Make sure new webcopmpat feature is enabled:
   ui.new-webcompat-reporter.enabled = true
3. Load any webpage
4. Go to Hamburger Menu / Report broken site
5. Fill in some information and activate "Send" button.
6. Observe how the JAWS/NVDA reads the webcompat reporter's confirmation dialog.

Expected result

• The confirmation message is instantly being read.

Actual result

• The confirmation message is not read.

Regression range

• not a regression, but an implementation flaw.

Additional information

• This issue also occurs with NVDA and ORCA.

Comment 1

[BugBot [:suhaib / :marco]]

:danibodea, if you think that's a regression, could you try to find a regression range using for example mozregression?

Comment 2

[❌ Anna Yeddi [:ayeddi] ❌ On leave until 2027-01-04]

Attachment: The gratitude text is not announced by NVDA with Up and Down arrows too.png

The gratitude text is not announced by NVDA with Up and Down arrows too, so it remains inaccessible for a screen reader user.

Setting up accessibility severity to s3, because the text does not include additional information about the status of the report, that is not already announced when browsing with NVDA, but it would be pleasant to allow users with low vision and blind users to hear the words of gratitude for their report.

Comment 3

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Disability Access APIs' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 4

[❌ Anna Yeddi [:ayeddi] ❌ On leave until 2027-01-04]

Returning the bug back to the Firefox component since it is likely not caused by the Accessibility API issue

Comment 5

[Daniel Bodea [:danibodea]]

It appears that this issue also occurs in the case of Ubuntu22 + ORCA. The screen reader would not read the confirmation message neither by TAB nor by UP/DOWN Arrow keys.

Comment 6

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1866257 - focus on the Report Broken Site URL or Okay button as their panelviews are shown; r?gijs

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/12d6e99ad2c4
focus on the Report Broken Site URL or Okay button as their panelviews are shown; r=Gijs

Comment 8

[Iulian Moraru]

Backed out for causing bc failures on browser_error_messages.js.

• Push with failures

• Failure log

• Backout link

Comment 9

[Thomas Wisniewski [:twisniewski]]

Ah, that's a quick test-update. I'll re-land soon.

Comment 10

[Iulian Moraru]

Found this failure TEST-UNEXPECTED-FAIL | browser/base/content/test/tabs/browser_new_tab_in_privilegedabout_process_pref.js | Test timed out - that is also caused by the above land. Because I don't know if your fix will resolve this failure, I needinfo you just to make sure you see it before you re-land.
Thank you!

Comment 11

[Thomas Wisniewski [:twisniewski]]

Are you 100% sure? That makes no sense to me at all, based on the log or the changes my patch make.

Comment 12

[Thomas Wisniewski [:twisniewski]]

Ah, I suspect it was https://hg.mozilla.org/integration/autoland/rev/8f8d0a90e80be424e59a7a9d848a2e9ad9fc28ad, not my patch, because that was backed out as well, and I see mentions of about:welcome in that patch and the failure log.

Comment 13

[Iulian Moraru]

This backfill points at your patch.
I also suspected that revision that you mentioned but the failure seems to stop at your revision.
I guess we are going to find out when you re-land :)

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9783889e5f8e
focus on the Report Broken Site URL or Okay button as their panelviews are shown; r=Gijs

Comment 15

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/9783889e5f8e

Comment 16

[Daniel Bodea [:danibodea]]

The behavior seen in the latest Nightly v122.0a1 will be detailed as follows:

• NVDA (on Win10): It reads the confirmation message automatically after sending a report.
• JAWS (on Win11): It does NOT read the confirmation message after sending a report. Can't be read by tapping UP/DOWN arrows either.
• ORCA (on Ubuntu 22): It does read the confirmation message if the reporter was opened from the HamburgerMenu or from the Protections Panel, but not if it was opened from the MainMenu.
• VoiceOver (on MacOS 11): Id does NOT read the confirmation message after sending a report, but it can read the message by using VoiceOver specific controls (CTRL+ALT+UP/DOWN).

In conclusion, it is partially fixed: NVDA does read the description automatically in all situations, JAWS does not read it in either situation, ORCA only reads the confirmation message if the reporter was opened from 2 out of 3 entry points and VoiceOver does not read it automatically, but it can read it by navigation inside the dialog.

Anna, can you have an opinion on the prioritization of these behaviors?
Tom, how do you suggest we address this situation further?

Comment 17

[❌ Anna Yeddi [:ayeddi] ❌ On leave until 2027-01-04]

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

The behavior seen in the latest Nightly v122.0a1 will be detailed as follows:

• NVDA (on Win10): It reads the confirmation message automatically after sending a report.
• JAWS (on Win11): It does NOT read the confirmation message after sending a report. Can't be read by tapping UP/DOWN arrows either.
• ORCA (on Ubuntu 22): It does read the confirmation message if the reporter was opened from the HamburgerMenu or from the Protections Panel, but not if it was opened from the MainMenu.
• VoiceOver (on MacOS 11): Id does NOT read the confirmation message after sending a report, but it can read the message by using VoiceOver specific controls (CTRL+ALT+UP/DOWN).

In conclusion, it is partially fixed: NVDA does read the description automatically in all situations, JAWS does not read it in either situation, ORCA only reads the confirmation message if the reporter was opened from 2 out of 3 entry points and VoiceOver does not read it automatically, but it can read it by navigation inside the dialog.

Anna, can you have an opinion on the prioritization of these behaviors?
Tom, how do you suggest we address this situation further?

Daniel, thank you for confirming the fixes!

As described in the comment for bug 1866251, the JAWS and ORCA are likely behave this way since doorhangers in Firefox are by default trigger the Forms mode of a screen reader. The VoiceOver behavior is filed in the bug 1872771, but we may file an access-s4 follow up for the ORCA behavior for the success message opened from the main menu - or, if the ORCA from MainMenu would announce Okay button, then we could just add it to the bug 1872771 without filing a separate bug.

LMK if you'd like me to update that bug (unfortunately, I do not have access to Ubuntu build yet to check the behavior myself)

Note: Tested on Win 11 and macOS 14.1.2 on the recent Nightly builds 123.0a1 (2024-01-01)

Comment 18

[Daniel Bodea [:danibodea]]

I've also logged bug 1873197 for the remaining issues with Ubuntu + Orca. This being said, the current report is resolved.