1866251 - JAWS/ORCA does not read the webcompat reporter's description

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Daniel Bodea [:danibodea]]

Found in

• Beta v121.0b2

Affected versions

• Nightly v121.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. Observe how JAWS reads the new webcompat reporter dialog.

Expected result

• The description is being read.

Actual result

• The description is not being read.

Regression range

• not a regression, but an implementation flaw.

Additional information

• The description is being read by NVDA.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

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 3

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

Returning the bug in the appropriate category, since it is likely related to the specific component instead of the Accessibility API.

:danibodea, could you confirm if it is still possible to hear the description of the reporting tool while using browse navigation mode (down arrows) with JAWS? I do not have access to this screen reader, unfortunately. (thank you for testing it with JAWS too!)

I'll set up the accessibility severity to access-S3 for now, but if the JAWS is not able to read the description at all, this should be increased to access-s2

Comment 4

[Daniel Bodea [:danibodea]]

It would appear that there is no way (even by pressing the down arrow to navigate inside the reporter window) for JAWS to read the description or the confirmation message (bug 1866257).

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 description neither by TAB nor by UP/DOWN Arrow keys.

Comment 6

[Thomas Wisniewski [:twisniewski]]

I think this is a simple enough fix, we just have to ensure that something on the panel is focused, and that it has an aria-label and aria-description (the label is needed, as it won't just read the title of the dialog). I'm working on some last details to make a patch.

Comment 7

[Thomas Wisniewski [:twisniewski]]

We are still deliberating how to deal with the focus issues in bug 1866519, but I will upload a patch which should resolve this issue for the app menu for now, and will also resolve the other views once bug 1866519 is addressed.

Comment 8

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1866251 - fix ARIA annotations for the <panelviews> of Report Broken Site and its confirmation page, so screen readers read its title and description appropriately (also partially fixes bugs 1866144 and 1866257); r?ayeddi,gijs

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/31a1108bee27
fix ARIA annotations for the <panelviews> of Report Broken Site and its confirmation page, so screen readers read its title and description appropriately (also partially fixes bugs 1866144 and 1866257); r=ayeddi,Gijs

Comment 10

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/31a1108bee27

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:twisniewski, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox121 to wontfix.

For more information, please visit BugBot documentation.

Comment 12

[Daniel Bodea [:danibodea]]

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

• NVDA (on WIn10): It does read the reporter description when opening the reporter from any of the entry points, but it cannot read it by navigating inside the dialog using UP/DOWN arrows.
  (Detailed behavior: when opening the reporter, NVDA reads the URL text box element, then reads the description and it stops. If focused on a button, tapping the DOWN Arrow will switch focus between Back button, "Send more info" link, Send button and Cancel button)
• JAWS (on Win10): It does NOT read the description neither when opening the reporter, nor when attempting to navigate inside the dialog.
  (Detailed behavior: when opening the reporter, NVDA reads the URL text box element and it stops. If focused on a button, tapping the DOWN Arrow will switch focus between Back button, "Send more info" link, Send button and Cancel button)
• VoiceOver (on MacOS 11): It does NOT read the description when opening the reporter, but it DOES read the description by navigating the dialog with VoiceOver specific commands (CTRL+ALT+UP/DOWN).
• ORCA (on Ubuntu 22): It does read the description when opening the reporter dialog from the Hamburger Menu or Protections Panel, but not from MainMenu and it does not read it again by pressing the UP/DOWN arrows to navigate inside the dialog.
  (Detailed behavior: when opening the reporter from the MainMenu, ORCA reads only the URL element; when opening the reporter from the HamburgerMenu or the ProtectionsPanel, it automatically reads the description and then the URL element and then it stops).

It would seem that the originally reported behavior on ORCA was (partially, 2/3 entry points) fixed and JAWS was not fixed. NVDA reads the description automatically while VoiceOver only reads it when navigating inside the dialog.

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

Comment 13

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

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

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

It would seem that the originally reported behavior on ORCA was (partially, 2/3 entry points) fixed and JAWS was not fixed. NVDA reads the description automatically while VoiceOver only reads it when navigating inside the dialog.

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

Hi Daniel, apologies for the delay in replying to you. I re-tested the most recent implementation on Win 11 and macOS 14.1.2 on the recent Nightly builds 123.0a1 (2024-01-01) - unfortunately, I am still working on getting my access to a Linux build.

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

• NVDA (on WIn10): It does read the reporter description when opening the reporter from any of the entry points, but it cannot read it by navigating inside the dialog using UP/DOWN arrows.
  (Detailed behavior: when opening the reporter, NVDA reads the URL text box element, then reads the description and it stops. If focused on a button, tapping the DOWN Arrow will switch focus between Back button, "Send more info" link, Send button and Cancel button)

This is an expected behavior for the NVDA's Forms Mode which is a default behavior for Firefox doorhanger panels and also for the initial focus position on the input field. On my Win11 machine, today NVDA+Space (usually, Ins+Space) did change to the NVDA to its Browse Mode and allowed for Up/Down arrow navigation and read all modes. This one is resolved then.

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

• JAWS (on Win10): It does NOT read the description neither when opening the reporter, nor when attempting to navigate inside the dialog.
  (Detailed behavior: when opening the reporter, NVDA reads the URL text box element and it stops. If focused on a button, tapping the DOWN Arrow will switch focus between Back button, "Send more info" link, Send button and Cancel button)

This is likely caused by the default doorhanger panel behavior and JAWS Forms Mode with it. Since the input is announced, it would imply to a user that the Forms Mode is active (besides the beep that JAWS should make when moving the focus into the form). It seems that this behavior is resolved to the extent that we could do.

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

• VoiceOver (on MacOS 11): It does NOT read the description when opening the reporter, but it DOES read the description by navigating the dialog with VoiceOver specific commands (CTRL+ALT+UP/DOWN).

This one may be related to the bug 1872771 - but in this case, since the field and the label are announced by VoiceOver when the dialog is opened, it would be not higher than an access-s4, it is not a blocker because the top of the form is being focused and announced by the VO, and since the other bugs were fixed and the VO commands are allowing a screen reader to navigate to the description and announce it.

If this is still present, do you mind filing up a follow up bug for it, Daniel?

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

• ORCA (on Ubuntu 22): It does read the description when opening the reporter dialog from the Hamburger Menu or Protections Panel, but not from MainMenu and it does not read it again by pressing the UP/DOWN arrows to navigate inside the dialog.
  (Detailed behavior: when opening the reporter from the MainMenu, ORCA reads only the URL element; when opening the reporter from the HamburgerMenu or the ProtectionsPanel, it automatically reads the description and then the URL element and then it stops).

It is probably related to the Forms mode, similarly to the NVDA and JAWS behaviors described above. Since the input field is announced, it seem to behave as expected.

Comment 14

[Daniel Bodea [:danibodea]]

I've logged bug 1873188 for the remaining situation with MacOS and VoiceOver. This concludes the verification of this bug. Thank you.