2016758 - (smartbar-dropdown-a11y) voice a11y likely broken in Smartbar Dropdown

Status: VERIFIED FIXED

(Core :: Machine Learning: Frontend, defect)

Description

[OOO until Jun 29 - Dan Mosedale (:dmosedale, :dmose)]

Bug 2008977 got the smart bar drop-down working in Smart Window. I've marked it as "regressing" that bug, but it's only a regression in the sense of displaying the warning to the console, since before that landing, it wasn't even possible to get the smartbar to drop down at all.

Now that it's working, after each typed keystroke that matches something, this shows up multiple times in the Browser Console:

console.error: (new TypeError("can't access property \"announce\", this.window.A11yUtils is undefined", "moz-src:///browser/components/urlbar/UrlbarView.sys.mjs", 854))

which suggests that voice accessibility isn't yet working (though I haven't verified that). Fallout includes additional code that probably isn't executing because of the exception.

Doing this in the UrlbarView constructor:

    if (!this.window.A11yUtils) {
      this.window.A11yUtils =
        this.window.browsingContext.topChromeWindow.A11yUtils;
    }

causes the error message to go away, and if there's code not executing that should be, that change likely fixes it. But reaching across from content to chrome like this (in the SmartBar case) seems icky and likely fragile. I wonder if we want something Actor-based here...

Comment 1

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

:flozia, since you are the author of the regressor, bug 2008977, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

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

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

Comment 3

[:Gijs (he/him)]

We should rewrite https://searchfox.org/firefox-main/source/browser/base/content/browser-a11yUtils.js to be a module and just load/import it into smart window and/or from the URL bar code module. We don't need IPC/actors here as it's all in the parent process.

Comment 4

[James Teh [:Jamie]]

Access s2 because this suggests some part of the smart bar is inaccessible.

1. Depending on when this is being shipped, it should probably be transitioned to use ariaNotify rather than A11yUtils.announce instead of moving the A11yUtils code. This will result in cleaner announcements for screen reader users. A caveat is that ariaNotify is only currently available in Nightly, though I plan to let it ride the trains with 149 if I can get the patch landed in time.
2. That said, if this is happening "after each typed keystroke that matches something" as described in comment 0, this is almost certainly a very problematic usage of A11yUtils.announce which will likely be very disruptive/intrusive for users. I haven't looked at what this is being used for, but please note that any usage of A11yutils.announce or ariaNotify should be discussed explicitly with the accessibility team, ideally as part of an accessibility engineering review, as it is very often the wrong solution and a signal that we should be doing something else instead.

Comment 5

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

The severity field for this bug is set to S4. However, the accessibility severity is higher, .
:Mardak, could you consider increasing the severity?

For more information, please visit BugBot documentation.

Comment 6

[:Gijs (he/him)]

(In reply to James Teh [:Jamie] from comment #4)

Access s2 because this suggests some part of the smart bar is inaccessible.

1. Depending on when this is being shipped, it should probably be transitioned to use ariaNotify rather than A11yUtils.announce instead of moving the A11yUtils code. This will result in cleaner announcements for screen reader users. A caveat is that ariaNotify is only currently available in Nightly, though I plan to let it ride the trains with 149 if I can get the patch landed in time.

Did this happen?

2. That said, if this is happening "after each typed keystroke that matches something" as described in comment 0, this is almost certainly a very problematic usage of A11yUtils.announce which will likely be very disruptive/intrusive for users. I haven't looked at what this is being used for, but please note that any usage of A11yutils.announce or ariaNotify should be discussed explicitly with the accessibility team, ideally as part of an accessibility engineering review, as it is very often the wrong solution and a signal that we should be doing something else instead.

I'm fairly sure this is all existing stuff in the URL bar view code, where we (apparently?) announce something for certain autocomplete list items appearing/disappearing, e.g. here. And this isn't specific/new for smart bar, it just doesn't work in smartbar right now because the URL bar view code (it turns out) implicitly depends on being loaded in a window that has a11yutils.announce loaded. We're not proposing materially changing something and I don't think it's reasonable to require reimplementing the core address bar bits as part of shipping this particular change, though doing that may well be a good improvement for the address bar code in general.

Comment 7

[James Teh [:Jamie]]

(In reply to :Gijs (away/busy until Mar 10) from comment #6)

A caveat is that ariaNotify is only currently available in Nightly, though I plan to let it ride the trains with 149 if I can get the patch landed in time.

Did this happen?

Unfortunately not. I didn't realise how close we were to merge day, so I opted not to push an entirely new web platform feature right at the end of the Nightly cycle. I've landed the pref flip for 150 though.

I'm fairly sure this is all existing stuff in the URL bar view code, where we (apparently?) announce something for certain autocomplete list items appearing/disappearing

That's fair. I was making this statement purely based on the observation in comment 0 that this happens for every character typed that matches something. That's certainly not the case for the normal address bar. In fact, I actually don't remember how to trigger that code at all; I haven't heard any of those announcements in a very long time.

Is it possible the smart bar is triggering those cases more often for some reason? If so, that would definitely be something to look into.

And this isn't specific/new for smart bar
...
We're not proposing materially changing something and I don't think it's reasonable to require reimplementing the core address bar bits as part of shipping this particular change

That's all fair. However, comment 0 suggests that this is happening a great deal more than it does for the normal address bar, so something is different in a problematic way. If it turns out that comment 0 was mistaken, of course we can reassess the severity of this.

Comment 8

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

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

Comment 9

[Pascal Chevrel (relman team) -> :pascalc]

Is that really an S4 if the accessibility severity is S2?

Comment 10

[:Gijs (he/him)]

(In reply to Pascal Chevrel:pascalc from comment #9)

Is that really an S4 if the accessibility severity is S2?

Someone needs to investigate and re-assess both. I expect it was marked as S4 in terms of a browser console message, and S2 for "voice accessibility is completely broken" (which I would argue could even qualify as access-S1).

I actually can't reproduce the error message on current Nightly so I can't help (I'm also swamped, and in workweeks, and traveling, and have PTO coming up 🫠) . Dan, can you improve the STR both in terms of how to see this and (presumably) what cases are actually broken? Based on the code location of the A11yUtils.announce I don't think this happens for each keystroke irrespective of the selected match.

Comment 11

[OOO until Jun 29 - Dan Mosedale (:dmosedale, :dmose)]

Will re-triage today.

Comment 12

[OOO until Jun 29 - Dan Mosedale (:dmosedale, :dmose)]

A family emergency came up today, so I did not yet have chance to dig into this further. I can't yet tell whether I'll get back to this later this week or not.

Comment 13

[Jonathan Almeida [:jonalmeida]]

REO for 150: Hi Dan, any updates to fix this for 150?

Comment 14

[:Gijs (he/him)]

(In reply to Jonathan Almeida [:jonalmeida] from comment #13)

REO for 150: Hi Dan, any updates to fix this for 150?

Not yet; we were looking for STR. I think Rares posted some in slack but they do not appear to have made their way here.
Rares? (FWIW, IIRC on slack the STR was "just type g in an empty smart bar" and I cannot reproduce with those STR still, testing on Windows)

Comment 15

[Rares Doghi, Desktop QA]

Hi, In our latest builds if we simply type "g" on the homepage smart bar, it will show this error in browser console:
TypeError: can't access property "selectedTab", this.window.gBrowser is undefined

However if we change our search engine to bing for instance and then in a new tab we type "bi" as soon as the search with Bing option shows up it will show this error :

TypeError: can't access property "announce", this.window.A11yUtils is undefined

Comment 16

[:Gijs (he/him)]

Attachment: Bug 2016758 - use A11yUtils.announce from the top chrome window from UrlbarView, r?#urlbar-reviewers

It would be better if this didn't rely on the window structure, but as it is
A11yUtils relies on DOM bits in the browser window so that is harder to fix.

Comment 17

[:Gijs (he/him)]

So this is existing url bar announcements which happen in very specific situations (like when changing the search engine in use from the default based on what you type, if there aren't autocomplete / other results that make it not the first result), which is why I had so much trouble reproducing it.

I think longer-term this part of UrlbarView should be rewritten to use aria-notify (see comment #4) but an initial/basic fix here is to just make this not produce errors/problems and go back to calling the top window's A11yUtils.announce as Dan suggested in the first place in comment 0.

Comment 18

[James Teh [:Jamie]]

(In reply to :Gijs (he/him) from comment #17)

So this is existing url bar announcements which happen in very specific situations (like when changing the search engine in use from the default based on what you type, if there aren't autocomplete / other results that make it not the first result)

So that means comment 0 is incorrect that "after each typed keystroke that matches something, this shows up multiple times in the Browser Console"? That is, it's only after a keystroke that triggers this very specific announce case.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/fdbb9febc9b4
https://hg.mozilla.org/integration/autoland/rev/acedc954c940
use A11yUtils.announce from the top chrome window from UrlbarView, r=urlbar-reviewers,dao

Comment 20

[amarc]

https://hg.mozilla.org/mozilla-central/rev/acedc954c940

Comment 21

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

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

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox150 to wontfix.

For more information, please visit BugBot documentation.

Comment 22

[:Gijs (he/him)]

Requested uplift.

Comment 23

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: Broken url bar a11y feature in smart window 150 release
• Code covered by automated testing?: yes
• Fix verified in Nightly?: no
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: See earlier comments from QA
• Risk associated with taking this patch: low
• Explanation of risk level: Very straightforward localized change
• String changes made/needed?: No
• Is Android affected?: no

Comment 24

[:Gijs (he/him)]

Attachment: Bug 2016758 - use A11yUtils.announce from the top chrome window from UrlbarView,

It would be better if this didn't rely on the window structure, but as it is
A11yUtils relies on DOM bits in the browser window so that is harder to fix.

Original Revision: https://phabricator.services.mozilla.com/D290232

Comment 25

[Rares Doghi, Desktop QA]

Verified as fixed in our latest Nightly 151.0a1 (2026-03-27)

Comment 26

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/7c492888fcdd
https://hg.mozilla.org/releases/mozilla-beta/rev/36286158e0f1

Comment 27

[Rares Doghi, Desktop QA]

Verified as fixed in our latest Beta 150.0b3