1895857 - Redirect blocked autorefresh infobar not read (ORCA)

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[Adrian Florinescu [:aflorinescu]]

Found in

• 127.0a1

Affected versions

• 127.0a1 (2024-05-08)

Not Affected versions

• 123.0a1 (2024-01-02)

Tested platforms

• Affected platforms: Ubuntu 22.04 (ORCA)
• Not Affected platforms: Windows 10, Windows 11 (JAWS)

Preconditions

• accessibility.blockautorefresh = true

Steps to reproduce

1. Screenreader is open.
2. Load a new tab: "data:text/html,<meta http-equiv="refresh" content="0; url=https://example.com/">"
3. Wait for the screen reader to read warning dialog.

Expected result

• Redirect warning dialog is read.

Actual result

• Redirect warning dialog is not read.

Regression range

• Regressed by: 1845150 - from comment 3

Comment 1

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

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

Comment 2

[James Teh [:Jamie]]

Curious. I don't recall any changes in any related areas of code in the last few months.

Comment 3

[Bianca Hidecuti, Desktop Test Engineering [:bhidecuti]]

I have looked for the regressor using Mozregression and I have reached the following range:

• Last good: 123.0a1 - 2024-01-10
• First bad: 123.0a1 - 2024-01-11
• Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=350fac42df08982dcb6992f3ab5c733a119bce8f&tochange=fe54bf7adef07c981ea02056742b1b7997a27d55
• Potentially regressed by: Bug 1845150. Hope this helps!

Comment 4

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

:hjones, since you are the author of the regressor, bug 1845150, could you take a look?

For more information, please visit BugBot documentation.

Comment 5

[Hanna Jones [:hjones]]

This looks like a dupe/specific case of bug 1887170 to me, :ayeddi what do you think?

Comment 6

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

Set release status flags based on info from the regressing bug 1845150

Comment 7

[Donal Meehan [:dmeehan]]

:hjones I see there is a pending ni for :ayeddi, but wondering did you get any updates on Comment 5 outside of Bugzilla?

Comment 8

[Anna Yeddi [:ayeddi]]

(In reply to Hanna Jones [:hjones] from comment #5)

This looks like a dupe/specific case of bug 1887170 to me, :ayeddi what do you think?

I thought the bug 1894535 should've fixed the moz-message-bar instances across the UI, since it is now always an alert.

Adrian, would you be able to retest the behavior in current Beta (Fx 128) or Nightly (Fx 129)? My hope that it has been resolved, but I cannot get an access to Linux atm. When you could, please NI me for the results, I promise to get back sooner than this time

Comment 9

[Cristian Baica [:cbaica], Release Desktop QA]

Hey Anna,
Replying here for Adi because he's having trouble accessing his ubuntu machine as well. The bug is still reproducing (the redirect warning dialogue is still not read). Tested using Ubuntu 23.04 with both Nightly 130.0a1 and Beta 129.0b1 builds.

Comment 10

[Anna Yeddi [:ayeddi]]

Thank you for confirming it, Cristian!

Then, I would guess that this specific notification is not a moz-message-bar (but then why would it be regressed after the component's change?). I am not sure and I am not familiar with this notification code too, TBH.

I think it's not the platform-level issue because snackbars that are alerts have been announced by Orca, AFAIK. Do you know which product it could be redirected to, @Eitan?

Comment 11

[Henry Wilkes (they/them) [:henry-x]]

I think I may have stumbled across the same issue when working on Tor Browser, after the transition from ESR 115 to ESR 128.

I was testing one of our notifications where moz-message-bar is used. Orca will only read back "Alert", but not the actual content of the moz-message-bar.

I compared the difference between the notification structure in ESR 115 vs 128 and it seems that something between Firefox and Orca expects a label element to be able to read out the alert. I found that if I swap <div class="text-content"> for <label class="text-content"> in moz-message-bar render method, then Orca will read it again.

Comment 12

[Henry Wilkes (they/them) [:henry-x]]

Note that adding an explicit aria-label also works. The noticeable difference is that Orca will also announce the aria-label when tabbing into the element.

Having the aria-label read out when tabbing in can give some extra context to a button or "Learn more" link. Without this, it is still possible to explicitly re-read the notification using the "read line" command (Orca+I), although it doesn't work as well if the message wraps onto another line.

Personally I would default to using aria-label since there aren't many scenarios where I think the extra context wouldn't be necessary to understand the "Close" button, an action button, or a "Learn more" link. But I don't use a screen reader regularly, only for testing.

Comment 13

[Henry Wilkes (they/them) [:henry-x]]

In Tor Browser I have found that using aria-describedby and aria-labelledby works well. Tested with Orca.

@ayeddi I could push my patch to phabricator if you are interested.

diff --git a/toolkit/content/widgets/moz-message-bar/moz-message-bar.mjs b/toolkit/content/widgets/moz-message-bar/moz-message-bar.mjs
index 9a186b41c98c..1069fa392af3 100644
--- a/toolkit/content/widgets/moz-message-bar/moz-message-bar.mjs
+++ b/toolkit/content/widgets/moz-message-bar/moz-message-bar.mjs
@@ -62,6 +62,7 @@ export default class MozMessageBar extends MozLitElement {
     dismissable: { type: Boolean },
     messageL10nId: { type: String },
     messageL10nArgs: { type: String },
+    useAlertRole: { type: Boolean },
   };
 
   constructor() {
@@ -69,6 +70,7 @@ export default class MozMessageBar extends MozLitElement {
     window.MozXULElement?.insertFTLIfNeeded("toolkit/global/mozMessageBar.ftl");
     this.type = "info";
     this.dismissable = false;
+    this.useAlertRole = true;
   }
 
   onSlotchange() {
@@ -76,11 +78,6 @@ export default class MozMessageBar extends MozLitElement {
     this.actionsEl.classList.toggle("active", actions.length);
   }
 
-  connectedCallback() {
-    super.connectedCallback();
-    this.setAttribute("role", "alert");
-  }
-
   disconnectedCallback() {
     super.disconnectedCallback();
     this.dispatchEvent(new CustomEvent("message-bar:close"));
@@ -90,6 +87,17 @@ export default class MozMessageBar extends MozLitElement {
     return this.supportLinkSlot.assignedElements();
   }
 
+  setAlertRole() {
+    // Wait a little for this to render before setting the role for more
+    // consistent alerts to screen readers.
+    this.useAlertRole = false;
+    window.requestAnimationFrame(() => {
+      window.requestAnimationFrame(() => {
+        this.useAlertRole = true;
+      });
+    });
+  }
+
   iconTemplate() {
     let iconData = messageTypeToIconData[this.type];
     if (iconData) {
@@ -110,7 +118,9 @@ export default class MozMessageBar extends MozLitElement {
 
   headingTemplate() {
     if (this.heading) {
-      return html`<strong class="heading">${this.heading}</strong>`;
+      return html`
+        <strong id="heading" class="heading">${this.heading}</strong>
+      `;
     }
     return "";
   }
@@ -136,13 +146,18 @@ export default class MozMessageBar extends MozLitElement {
         rel="stylesheet"
         href="chrome://global/content/elements/moz-message-bar.css"
       />
-      <div class="container">
+      <div
+        class="container"
+        role=${ifDefined(this.useAlertRole ? "alert" : undefined)}
+        aria-labelledby=${this.heading ? "heading" : "content"}
+        aria-describedby=${ifDefined(this.heading ? "content" : undefined)}
+      >
         <div class="content">
           <div class="text-container">
             ${this.iconTemplate()}
             <div class="text-content">
               ${this.headingTemplate()}
-              <div>
+              <div id="content">
                 <span
                   class="message"
                   data-l10n-id=${ifDefined(this.messageL10nId)}
diff --git a/toolkit/content/widgets/notificationbox.js b/toolkit/content/widgets/notificationbox.js
index fc3e553ca424..8d37165da91d 100644
--- a/toolkit/content/widgets/notificationbox.js
+++ b/toolkit/content/widgets/notificationbox.js
@@ -703,17 +703,6 @@
         }
       }
 
-      setAlertRole() {
-        // Wait a little for this to render before setting the role for more
-        // consistent alerts to screen readers.
-        this.removeAttribute("role");
-        window.requestAnimationFrame(() => {
-          window.requestAnimationFrame(() => {
-            this.setAttribute("role", "alert");
-          });
-        });
-      }
-
       handleEvent(e) {
         if (e.type == "click" && e.target.localName != "label") {
           return;

Comment 14

[Anna Yeddi [:ayeddi]]

(In reply to Henry Wilkes (they/them) [:henry-x] from comment #13)

In Tor Browser I have found that using aria-describedby and aria-labelledby works well. Tested with Orca.

@ayeddi I could push my patch to phabricator if you are interested.

hi @henry-x, my apologies for the very delayed reply! Thanks so much for the investigation and the patch. I did not ignore your generous offer to push the patch. It does seem just great from the a11y perspective and I've followed up with the Reusable Components team to check if there are any concerns.

If you're still up for it, could you please send the patch to the Phab and add #frontend-accessibility-reviewers and #reusable-components-reviewers so we can make sure it's not waiting any longer?

Comment 15

[Henry Wilkes (they/them) [:henry-x]]

Sounds good. I'll push my patch next week.

Comment 16

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Bug 1895857 - Add aria-labelledby and aria-describedby to moz-message-bar. r=#accessibility-frontend-reviewers,#reusable-components-reviewers

Comment 17

[Hanna Jones [:hjones]]

Dropped the ball on this NI request, but since there's a patch up now I think we can continue the discussion there.

Comment 18

[Henry Wilkes (they/them) [:henry-x]]

@jdiggs

Do you have any insight regarding comment 11 above and a duplicate speech issue in phabricator.

Basically, it seems that in the chrome context role="alert" will only be read out by Orca if contains some <xul:label> or <html:label> element to read, or if it has an explicit accessible name, via aria-label or aria-labelledby. I'm guessing that this is because of the non-document context, and Orca will only read out certain elements within the alert, such as ATK_ROLE_LABEL, but will not read out plain content like <html:span>. Is this intentional for some particular reason?

In the patch, I decided to add aria-labelledby pointing to the text content within the role="alert", plus sometimes aria-describedby for longer messages. E.g. essentially

<div role="alert" aria-labelledby="header" aria-describedby="content">
  <img alt="Info" />
  <span id="header">Please be careful</span>
  <span id="content">This operation can cause problems. <a>Learn more</a></span>
</div>

This work well for the messages that appear in the chrome (non-document context). Orca will announce both the label and description once.

However, when this appears within a content page (document context) then Orca will triple announce it:

1. The alert name is announced. E.g. "Please be careful".
2. The alert content is announced as a flat string. E.g. "Please be careful This operation can cause problems. Learn more".
3. Then the alert content is announced with roles. E.g. "Info image. Please be careful This operation can cause problems. Learn more link".

Would you consider this a bug with Orca or should this be addressed on the Firefox end?

Comment 19

[Joanmarie Diggs]

Henry: I'm happy to take a look, but could you please create a jsfiddle (or your favorite alternative) and let me know the following:

1. Version of Orca
2. Steps needed to reproduce the problem

Thanks!

Comment 20

[Henry Wilkes (they/them) [:henry-x]]

@jdiggs

Orca version is 46.2.

Here is a demo of the above example: https://jsfiddle.net/y7mrdoqp/. Just focus the "Toggle alert" button and click to add the "alert" role and trigger the announcement. Press again to remove the role, and then again to re-add it.

NOTE: Removing aria-labelledby and aria-describedby causes Orca to just announce the content of the alert once, but if you move into the alert (e.g. by focusing the "Learn more" link) it will not announce it as an alert. See this at https://jsfiddle.net/x47oacv9/.

NOTE: This only demonstrates the behaviour within document pages. For alerts as part of the chrome, see the steps to reproduce for this bugzilla issue. In Firefox, where there is no <label> or aria-labelledby, Orca only announces "Alert" and nothing more. In Tor Browser 14.0, where I've added an aria-labelledby it will announce the full message.

Comment 21

[Joanmarie Diggs]

Thanks so much Henry. That chattiness was crazy. It is now fixed in Orca's main and gnome-47 branches.

Regarding the second jsfiddle, after the alert is announced, I would not expect Orca to say "alert" again in response to tabbing to the link. Can you please explain why this is needed?

Comment 22

[Joanmarie Diggs]

Regarding the native/infobar-style alert, I just tried your steps to reproduce the problem using Orca from its main branch and from its gnome-47 branch along with Firefox nightly. Orca is announcing the displayed text for me.

Comment 23

[Henry Wilkes (they/them) [:henry-x]]

Thanks so much Henry. That chattiness was crazy. It is now fixed in Orca's main and gnome-47 branches.

Great!

Regarding the second jsfiddle, after the alert is announced, I would not expect Orca to say "alert" again in response to tabbing to the link. Can you please explain why this is needed?

Similar to tabbing into a grouping (like a form, or aside), Orca will announce the accessible name along with the role if you enter, which can be useful to notify the change in context when using focus mode. In the alert case, Orca will not announce the "alert" role at all if it does not have an accessible name, even when in browse mode, so there is no indication of the "alert" semantics.

For example, if you get a notification in Firefox as in the steps to reproduce, if you tab into the notification you'll likely hit some action button, like "Close". I think that having the announcement "Alert. Please be careful This operation can cause problems. Close pushbutton." is generally useful to let the user know the context of the button.

Regarding the native/infobar-style alert, I just tried your steps to reproduce the problem using Orca from its main branch and from its gnome-47 branch along with Firefox nightly. Orca is announcing the displayed text for me.

Ok, that's good to know. Maybe I'll test with GNOME 47 at some point. Is this a change that is going to be backported to 46?

Comment 24

[Henry Wilkes (they/them) [:henry-x]]

FYI: I'm going to be away next week, so I won't be able to work on the patch in that time.

Comment 25

[Mark Striemer [:mstriemer]]

Attachment: Bug 1895857 - Use label for message in notification-message r?#recomp-reviewers,henry

Comment 26

[Daniel Bodea [:danibodea]]

The issue still occurs in Nightly v140.0a1 on Ubuntu 22 with ORCA for both the Block Autorefresh infobar and others, like the Default Borwesr infobar or the "Running out of disk space" infobar.

Comment 27

[Henry Wilkes (they/them) [:henry-x]]

The issue still occurs in Nightly v140.0a1 on Ubuntu 22 with ORCA for both the Block Autorefresh infobar and others, like the Default Borwesr infobar or the "Running out of disk space" infobar.

Which version of Orca is Ubuntu 22 running? My own system is running version 47.3, which does read out the announcement.

Comment 28

[Daniel Bodea [:danibodea]]

I have ORCA v42.0 on Ubuntu 22.04.5 LTS, Gnome version 42.9, Wayland.

Comment 29

[Henry Wilkes (they/them) [:henry-x]]

I'm going to try and pick this up again with an updated patch.

Comment 30

[Henry Wilkes (they/them) [:henry-x]]

Attachment: Patch to enable accessible name and description for moz-message-bar

Comment 31

[Henry Wilkes (they/them) [:henry-x]]

Joanmarie and Anna: I'm a bit unsure what to do here.

On the one hand, without setting an accessible name or description for the role="alert" element:

1. With Orca version 48, the notification is read aloud by Orca.
2. Earlier Orca versions are silent. I'm not sure which versions, but an earlier comment mentioned at least version 42.
3. When the user navigates into the alert by focusing a link, an action button or the close button, Orca does not announce much context. Only an empty "alert", followed by the usual read out describing just the focused element. As such, there isn't an easy way to read back the full alert. The reading commands (like "read line" or "say all") do not work that well since any line-wrapping in the alert body will cause the "close" button's text to be mixed into the body's text.

On the other hand, with the patch in comment 30, which sets an accessible name via aria-labelledby (and description) for the role="alert" element:

1. With Orca version 48, the notification's body is first read by Orca, followed by the name and description. So there is duplicate reading.
2. Earlier Orca versions (from memory) read out the alert once.
3. When the user navigates into the alert, Orca will announce "alert", followed by the name and description, then followed by the focused element. This gives immediate context to the focused element.
4. However, if the user is in browse mode, when navigating into the alert's body, there is duplicate reading from Orca (at least in version 48).

As such, it is not clear:

1. Should the double-speak be addressed in Orca?
2. Is it useful to users to get the immediate contextual feedback? @jamie could you perhaps give some insight from NVDA and JAWS. Is there a way to easily read back the alert context when you move focus to one of the alert's controls?

Example: alert shown in chrome at startup

With a fresh Firefox profile, on the second run you get an immediate notification for "Open previous tabs?". Can be spoofed by setting browser.startup.couldRestoreSession.count to 1 in about:config.

With the patch, this just has an accessible name that includes the whole notification. Strangely enough, "Open pevious tabs?", which is (incorrectly) wrapped in <strong>, is not read back by Orca the first time around.

Example: alert in about: page with no control elements

If you set your history settings to "Never remember history", then there is an alert beneath the "cookies" heading with no focusable elements. This should probably not be an alert anyway: bug 2016075.

Comment 32

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

Redirect a needinfo that is pending on an inactive user to the triage owner.
:ayeddi, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.