Tested on
Firefox nightly 82.0a1 and affects:
Windows10 64bit using nvda
MacOS 10.15 using voiceover
Ubuntu 18.04

Description
One-offs and new search shortcut feature is not compatible with screen readers.

Steps to reproduce

Install screen reader
Launch firefox
type for any word in url bar
Hover mose over search results
Hover mouse over one-offs
Click a one-off example (duckduckgo)
Hover mose over search mode box on the URL bar (duckduckgo box)

Expected result
screen reader should tell you where you are and what you are hovering and clicking.

Actual result
On windows 10: I am able to hear the one-offs, and the search mode box, but not the search suggestions.
On mac0s: i am not able to hear anything when i hover on thr search suggestions, nor one.offs, nor search mode box.
On ubuntu: i am not able to hear anything when i hover on thr search suggestions, nor one.offs, nor search mode box.

What are the results if you disable browser.urlbar.update2? That will disable the search mode box, but are one-offs and search suggestions read out?

Hi harry , i have the same issue with browser.urlbar.update2 as false.

Windows10 : screenreader works when using keyboard up down keys and works with mouse hovering
Ubuntu 18 : screenreader works when using keyboard up down keys and does not work with mouse hovering
MacOS : screenreader works when using keyboard up down keys and does not work with mouse hovering

Thanks. I'm removing bug 1644572's dependency on this bug since the reported issue isn't something new to that work. It sounds like this is a matter of us not announcing some mouse-hovered Urlbar elements to screen readers. The problem appears to be worse on Mac and Linux, where nothing is announced. Marco, do you know of any bugs already tracking similar issues?

First of all, announcing what is under the mouse or not is usually a screen reader feature. And it can be enabled or disabled by the user. NVDA does announce items under the mouse by default, VoiceOver on MacOS does not. JAWS on Windows does not, either. So if the screen reader is running, and you move the mouse pointer with a physical mouse or the touch pad, whether the screen reader speaks something or not is totally dependent on the screen reader itself, and the preference whether to speak items under the mouse or not is set. So, using NVDA, by default, you can be sure to hear what is under the mouse, if using VoiceOver on the Mac, definitely not by default. So before we even talk about bugs, we must establish whether the screen reader is even set to speak what's under the mouse.

Having said that, blind users usually don't use the mouse pointer that much. This is most often done by sighted users who turn on the screen reader, but then fall into their habit of using the computer, not doing what a blind person would normally do. I would, for example, not fiddle around with the mouse pointer to find those one-offs. I would type in my search term, then arrow down into the search results, then use Alt+DownArrow to jump through the one-offs and press Space to execute it.

While trying this, I found that the regular search results are found by the mouse pointer in chunks, so the URL, suggested search term for each item etc., are single pieces the mouse pointer and screen reader finds. When arrowing, the whole list item is spoken, not the individual columns.

So, I don't actually think we have a bug here.

Thanks for your input Marco. I'll close this bug as WONTFIX since it depends on the settings in external software.