Open Bug 1975859 Opened 6 months ago Updated 7 days ago

Accessibility on Android: can't access search bar together with Google voice access

Categories

(Firefox for Android :: Search, defect, P2)

Product:
Firefox for Android
Component:
Search
Version:
Firefox 140
Platform:
All
Android
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: michael.m.moser, Unassigned)

References

Details

(Whiteboard: [fxdroid][group3])

Attachments

(6 files, 1 obsolete file)

VoiceSearchUsingTheComposableToolbar.mp4
4.71 MB, video/mp4
Details
Screen_Recording_20251222_145456_Firefox Nightly.mp4
6.36 MB, video/mp4
Details
Screenshot_20251222_151150_Settings.jpg
701.85 KB, image/jpeg
Details
AwesomebarLabels.png
453.18 KB, image/png
Details
Screenshot_20260101_102344_Voice Access.jpg
370.56 KB, image/jpeg
Details
Screen_Recording_20260111_120027_Firefox.mp4
9.51 MB, video/mp4
Details

User Agent: Mozilla/5.0 (Android 15; Mobile; rv:140.0) Gecko/140.0 Firefox/140.0

Steps to reproduce:

Enable Google voice access accessibility app on Android
Open Firefox on Android
Use voice command in voice access to search for some text via the search bar, eg search for cats

Actual results:

Google voice access says that it cannot find the search bar

Expected results:

After having said what text Google voice access should search for, text should have been entered into the search bar and the search should have been executed.

The search feature of Google voice access works fine with Google Chrome. You tell the voice access to search for some text, and it enters the text into the top search bar and searches for it.

Using Firefox, voice access just tells you that it cannot find the search bar. So you need to enable numbers in order to click The search bar manually, and enter the text there manually.

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

Component: General → Search

The severity field is not set for this bug.
:skhan, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(skhan)

Could someone take a look at this? Since the last Voice Access update on December 12, the search bar is no longer recognized as a text field. On Android 16, with the latest Firefox for Android, Voice Access doesn’t detect it anymore. That means you can’t type with Google Voice Access at all — unless you use the on‑screen keyboard and dictate the individual letters by number. The issue is that the search field is not treated as a text field.

By the way, the same problem also occurs with Thunderbird on Android. The search field has not been recognized since the original creation of this post, and similar to Firefox, since the Google Voice Access update on December 12, the text field is no longer recognized either. As a result, it is no longer possible to write unless you dictate each individual letter using speech input on the on-screen keyboard. Perhaps Thunderbird and Firefox share the same technical implementation for the text field in the background, which no longer works with Google Voice Access.

Hi, I'm a Product Manager on Google's Android Voice Access team. We are sorry for the regression in your text input experience on Firefox with Voice Access. We can confirm this issue and want to provide some additional context from the assistive technology side.

The core problem appears to be that the search bar in Firefox for Android (and likely Thunderbird for Android as well) does not correctly signal to the Android Accessibility Framework that it has input focus. Even when the search bar is visually focused and the keyboard is up, the underlying AccessibilityNodeInfo for the element does not seem to have its focus property set in a way that accessibility services like Voice Access can reliably detect.

Android Voice Access relies on elements accurately reporting their state, including whether they have input focus, to function correctly. A change in Voice Access version 16.2.829506306 (released in early December 2025) made our service stricter about requiring a node to explicitly have accessibility input focus before allowing most text editing commands. This change was intended to prevent text input errors in apps where the focused element was ambiguous, improving overall robustness.

This enhancement in Voice Access has unfortunately highlighted a pre-existing issue in how Firefox for Android's search bar reports its state to the Android Accessibility Framework. The search bar does not seem to correctly signal that it has input focus from an accessibility perspective, even when visually focused. Because Voice Access now correctly enforces the focus requirement, it no longer attempts to type into fields that don't declare accessibility focus. The underlying issue is in the Firefox component not fully implementing the expected accessibility states.

When Voice Access queries the accessibility tree, the Firefox search bar isn't being recognized as the element with active input focus, hence the "cannot find the search bar" or "That's not a text field" responses.

The shared issue with Thunderbird suggests a common component or implementation for these input fields within Mozilla's Android applications. To resolve this, the text/search fields need to ensure they are properly acquiring and signaling accessibility focus to the Android Framework when they are active and ready for input.

This is a significant barrier for Voice Access users on Firefox, preventing them from using the search functionality in Firefox on Android. We're happy to provide any further information or help test any potential fixes from the Voice Access perspective. We'd love to work with Mozilla to get this fix prioritized for Firefox on Android.

New bug opened here with more information, for visibility: [a11y] Search Bar input field does not expose accessibility input focus, breaking Android Voice Access

Hi Ali,

Thank you very much for this detailed technical explanation. It makes the situation completely clear.

Coincidentally, I am the user who reported this regression internally via Google Disability Support (Ticket ID [9-7885000039868]). It is good to see the connection here.

Your explanation regarding the stricter enforcement of AccessibilityNodeInfo focus explains perfectly why other apps like Samsung Notes or Thunderbird (which likely share similar implementation issues regarding accessibility states) have also completely stopped accepting input since the update.

I also wanted to mention that I have observed intermittent failures in other apps (like Gemini or WhatsApp). In these cases, the behavior is unstable: I might dictate a sentence successfully, pause briefly to think, and when I try to continue speaking (without having interacted with the screen in any other way), Voice Access suddenly claims "No text field found". I have already described this in detail in the Google Support ticket, so I won't go into further detail here, but I wanted to mention it for completeness.

I am, of course, happy to help with further questions or testing.

@Mozilla Developers:
Since you are working on the fix for the focus signaling, I would like to refer back to the original request of this bug report (from before the December 12th update).

If possible, it would be great if the fix could also enable the standard "Search for [text]" Voice Access command. Ideally, it would work like in the Google Play Store (automatic selection & search trigger). Previously, I always had to manually select the search bar using numbers. Enabling this intent would save a few voice commands and improve the user experience nicely, if it can be implemented alongside the fix.

Thanks again for the transparency.

Severity: -- → S2
Flags: needinfo?(skhan)
Priority: -- → P2
Whiteboard: [fxdroid][group3]
Attached video VoiceSearchUsingTheComposableToolbar.mp4 (obsolete) —

Seems to me like things are greatly improved with the new toolbar enabled by default in Firefox Nightly.
Michael, Ali can you confirm?

Flags: needinfo?(michael.m.moser)
Flags: needinfo?(aforelli)

I just tried it out, and strangely it doesn’t work like that for me. The search bar still isn’t detected. Apart from that, the number indicators also don’t work properly, at least not the way you can see in the video. That’s probably a separate issue, though.

It’s actually worse than in regular Firefox, because for example in normal Firefox the numbers from the lower layer don’t shine through. Also, compared to the normal release, the number and the text field for clicking into the text field are missing, which is a bit annoying because you have to use the grid every time.

At least text input in the search field works now. But to summarize: for me the following things don’t work — first, the search function; second, the number for the search field is missing; and when you get to the search results, most of the numbers for the results are missing as well, and the numbers from the layer below shine through.

I’m on a Galaxy Tab S11 Ultra with the latest stable release of Android 16 and One UI 8.x.

Flags: needinfo?(michael.m.moser)

Have you made sure that you also have the latest version of Voice Access, the one from December 12? I’m registered for the beta there, so maybe I have a newer version. I just installed Firefox Nightly a moment ago, so that should also be the latest version.

Attached image AwesomebarLabels.png —

I am also using version 16.2.829506306 of Voice Assist.
In my tests starting a search with Voice works the same as in Chrome - saying "search for.. " works, but we are indeed missing a label for the search box.
At the same time the "show labels" command produces some labels for the search results but also for other elements, we need to clean these up.

I can’t really explain it to myself. But I’m also using the German version of Voice Access — you can’t change the language there, otherwise I would try it in English. Maybe Ali can help here; I’m just the user and I don’t have any insight into the technical implementation of Voice Access.

I also tried moving the search bar to the bottom, but that didn’t change anything either. And it doesn’t work on my Galaxy S25, either.

Thank you for all the details!
There might be issues depending on the locales used.
We'll try with some other locales as well!

And by the way Google Chrome works with the search

One more thing. I already mentioned that in the search results the first entries don’t have a number to tap on. By now I have the feeling that this is a general Voice Access issue since the update on December 12.

In the release version of Firefox this affects the first two search results, in Nightly it affects the first search result, and in Thunderbird the first two emails. But interestingly, the same thing happens in many completely different apps.

For example, in Telegram the first two chats don’t have numbers. In the app Line, the first two or three entries in the chat list are missing their numbers as well. And in the Play Store, when using the search field, the first two results also don’t have numbers.

Additionally, in the Samsung One UI system settings, when using the built‑in search, the first search result also has no number.

Is this an intentional change that all these apps would need to update for — which would be quite a lot — or is this a bug, Ali?

Thanks all for the additional info and troubleshooting here! Myself and the rest of the Voice Access engineering team are out of office this week for the US holidays, but we will test on our side with an updated Firefox version next week when we return to work.

Voice Access automatically uses your Android system UI language. To test for a different locale, go to Settings -> System -> language & region and change/ re-order existing language preferences.

We'll be sure to test the German experience that Michael is using, to see if there are any differences.

As for the missing number labels for the search results, Voice Access intends for all interactive screen elements to receive a label, so these should have numbers. However, we have been making changes to reduce "false" labels that have been added in the past (example: labeling a static string rather than a button) so we will investigate whether these updates have accidentally regressed other experiences.

Thank you for your patience and understanding here!

Flags: needinfo?(aforelli)

No problem, I already figured that everyone would be on vacation at the end of the year anyway. In the meantime, I discovered that the numbering issue also appears in the Voice Access command list, so it really seems to be a problem with the latest version. As you can see in the attached image, the first number is missing, for example.

Hello all! I'm back in the office this week, and I have been testing the various issues on my device. Here's a summary from my testing and investigation so far:

Firefox Standard

  • Issue: Voice Access cannot type in the search box.
    • Observation: The search box is labeled, but Voice Access fails to input text.
    • Impact: Users cannot type search queries using standard Voice Access dictation.
    • VA Status: A potential workaround is in progress on the Voice Access side to make our text editing stack less strict about focus.
    • Recommended Firefox Fix: The ideal solution is for Firefox to ensure the AccessibilityNodeInfo for the search bar element correctly receives and sets the accessibility focus property after a user activates it (e.g., via Voice Access "show numbers" -> "[number]").

Firefox Nightly

  • Issue: Search box is not labeled.

    • Observation: The main search box does not have an accessibility label.
    • Impact: Voice Access users cannot target the search box by label and must use less direct methods like "show grid".
    • Note: Once focus is manually moved to the search box, Voice Access text input does work correctly.

  • Issue: Numbers and labels "bleed through" when the search bar is expanded.

    • Observation: When the search bar expands (e.g., to show suggestions), Voice Access numbers/labels for the content behind the expanded UI are still visible.
    • Impact: This creates many extra, irrelevant labels on screen, confusing the user.

General Voice Access Issues (not Firefox issues)

  • Issue: First suggested search result not numbered.

    • Observation: This does not reproduce for me with the UI language set to English. Michael reported this on his device, with German language settings. This bug is occurring across many apps and surfaces for Michael.
    • Impact: The user cannot select the first list item using number commands, across many apps and scenarios.
    • Status: Needs further investigation. Our team notes that it seems the label for the item (e.g., what should be item "23") might not be rendering in the accessibility tree in Michael's case. This was not reproducible on an Android tablet with a recent Voice Access build. This could be specific to the device, Android build, or the app's accessibility tree generation in that environment. More investigation needed.

  • Issue: "Search for [query]" Voice Access command fails in Firefox for German.

    • Observation: The English command "Search for [query]" works correctly in Firefox. The German equivalent does not function as expected.
    • Impact: German-speaking users cannot use this multi-step action.
    • Status: Voice Access does support this command in German. The failure likely occurs because the Firefox search bar in the German UI doesn't meet Voice Access's heuristics for identifying a search field. These heuristics look for text like "search" (and German synonyms) in the element's text, content description, or hint text. The absence of such identifiers in the accessibility properties of the search bar element in the German UI could cause the command to fail. More investigation needed.

Michael, if you are able, could you submit feedback directly from your device, via Settings -> Accessibility -> Voice Access -> Settings -> Help and feedback -> Send Feedback.

If you could do this for the last 2 issues, which were:

  1. missing numbers for first list item
  2. "search for [query]" not working in German
    The in-app feedback path will give the voice access developers access to more debugging info to look into these details for you. Thank you!

Hello Ali, no problem — I’ve done that. I also explicitly included your name in the feedback. I’m not sure how much feedback you receive per day, but this way you can easily search for it. Thank you very much for your effort, and in general for developing Voice Access. It enables so much more in my life, and I’m truly grateful for that.

By the way, with the update from December 12, a serious issue was fixed for me. Until now, the app had been crashing every 20 to 25 minutes, and before each crash it would gradually become slower during use. At some point, the numbers were no longer recognized or they got stuck. Because of this, some apps were practically unusable — for example Outlook in the browser, because the numbers would freeze immediately or within 30 seconds of using it.

I reported this issue about half a year ago through Google Disability Support — the ticket number is 4-2129000039697. I don’t know whether you actively fixed the issue or whether it was resolved by coincidence, perhaps due to changes in text field recognition. I just wanted to mention it again, because if the fix happened by accident, there is a chance the issue might return in the future. For me, it was quite severe, since I had to restart the tablet every 20 to 25 minutes because it became too slow, the numbers got stuck, or I had to intentionally trigger a crash to continue working.

This was also with the German version of Voice Access. I assume the issue might have been noticed earlier in the English version, since I imagine most of your testing is done in English. So perhaps this bug was specific to the German version.

Hi Michael. I wanted to let you know that I found your recent feedback - mentioning my name made it easy to find, since the feedback is anonymized in my view. Thanks for submitting it!

Also, we recently released a fix for voice access for the typing in Firefox search issue. I just verified on my end, and it is working. If you get a chance, could you try again on your side? The fix should update automatically I believe.

And we did fix the performance issue that you reported a few months ago, and that was part of the 16.2 release in December. Thank you so much for the feedback! You're helping us make the product better for everyone.

Hi Ali, thanks a lot for the fix, that was really fast! It’s working for me now as well, so I can enter text into the Firefox search bar again. Since the fix wasn’t specific to Firefox, it also works in Samsung Notes, for example.

What I haven’t been able to test thoroughly yet are the intermittent issues in apps like Gemini or Copilot, when you dictate text and the problem suddenly appears, but then resolves itself again after a while. Since it only happens intermittently, sometimes more and sometimes less, I haven’t been able to test that in detail yet.

By the way, does it matter to you in which language feedback is submitted, and is it automatically translated on your side?

With the German version of Voice Access, I get the impression that the system is somewhat primed for German, which makes sense, but it also means that writing English text with Voice Access is quite difficult, because it often hears German words instead of English ones. That’s why I prefer writing my text in German and letting an LLM translate it, not because I have issues with English, but simply because it’s easier with Voice Access. So if your system automatically translates feedback anyway, I can just write it directly in German using Voice Access, without going through an LLM first.

One more thing I just remembered: In Wikipedia on Firefox, it’s not possible to long‑press numbers to open the context menu, which is really useful when you want to open Wikipedia links in a new tab. See the video.
Not being able to long‑press numbers also happens on other websites, even though I can’t think of specific examples right now, because ever since then I’ve always used the workaround of using the grid.
It might also happen in other apps outside of Firefox, but I’m not completely sure anymore.
Is this a Firefox issue, or is it more of a Voice Access thing?
When you try to long‑press elements directly by name, it’s the same — it only works with the grid.

Thanks Michael for the additional feedback! I'd love to continue to stay in touch with you for further feedback beyond this bug. Can you find me on LinkedIn https://www.linkedin.com/in/aliforelli
and we can connect to discuss further feedback?

I believe our feedback system translates to English automatically, so feel free to submit in German (continue mentioning my name if you want a fast track for me to find it!). Otherwise it is all anonymized from my view, so I can't identify your specific feedback.

And thanks for the tip on the long press issues. I'll get a bug filed on our internal database to track this.

See Also: → 2007226
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: