We plan to add a feature that adds a "tab-to-search" result in the Urlbar as the second result when the user types a search engine alias. For example, if the user has the alias "ama" registered to the Amazon search engine, we would show a "tab-to-search" result when they type "a", "am", or "ama", telling them they can press Tab or down arrow to start a search with Amazon.

The issue here is that these results are invisible to screenreaders since they are not selected when they appear. We should work with the a11y team to evaluate how we want to announce these results when they appear, if at all.

Tab-to-search results are now live in Nightly behind the pref browser.urlbar.update2.tabToComplete. In the initial implementation, we show a tab-to-search result whenever a search engine's domain is being autofilled. For example, if the user types g, we might autofill google.com and show the Google tab-to-search result as the second result. The behaviour described in comment 0 of also showing a tab-to-search result for partially-typed token aliases is forthcoming in bug 1647901.

Selecting a tab-to-search result enters search mode: they're so-called because pressing Tab puts the user in search mode. We don't actually surface the name "tab-to-search" to the user because down arrow also works. Search mode accessibility was discussed in bug 1647917.

Tab-to-search results read

Search with <engine name> — Search with <engine name> directly from the address bar

Tab-to-search results are meant as a visual indicator to the user that instead of navigating to google.com, for example, they could do their Google search from within the address bar in Google search mode.

We need to implement similar behaviour for users with a screen reader. My first thought is announcing "Select the next result to search <engine name> directly from the address bar" when we autofill a search engine domain like google.com or amazon.com. Jamie, what are your thoughts?

(In reply to Harry Twyford [:harry] from comment #1)

My first thought is announcing "Select the next result to search <engine name> directly from the address bar" when we autofill a search engine domain like google.com or amazon.com. Jamie, what are your thoughts?

Seeing as we're also going to show tab-to-search results when the user types the beginning of an engine alias (bug 1647901), we're going to be showing these results pretty often. This string might be a bit verbose. Maybe "Select the next result to search <engine name>" is more suitable? Then when the user selects the next result, we'd read out "Enter search terms" or "Search the Web", like we normally do for search mode.

we may want to distinguish the autofill case, supposing we currently announce the autofilled origin, for example "amazon.com", we could maybe change the announce to a shorter "amazon.com, select the next result to search" in that case, without repeating the engine name.

While I do want to make sure we make features equivalently accessible to screen reader users, the potential for intrusive extra verbosity worries me here, but it's hard to get a feel for that without seeing it in the wild and ideally getting some feedback from other users. I'm guessing the tab-to-search result is quite prominently visible (perhaps more prominent than other results somehow?) and would "get the user's attention". However, I'm guessing it also isn't "intrusive". The challenge for some screen reader users is that any additional message here while they're typing might be "intrusive" rather than "prominent". That said, I think we should probably try this and see how it goes, with the caveat that we may need to back it out if user sentiment isn't good.

Regarding the message, I'm not sure if users will understand what is meant by "Select the next result". Even though they're focused in an autocomplete and they may eventually select a result, I don't think that connection is going to be obvious while they're typing, especially because screen reader users don't "see the results appear" as they type. While I'd normally advise against keyboard specific messages, I'm thinking in this case that the most intuitive message is probably "Press tab to search with <engine>", which has the added advantage of being briefer. That's bad for touch screen users, but I think that's probably a rare use case.

One other problem is that when a screen reader user presses tab, the tab-to-search result will get "focused". Users may think they then have to press enter to activate it. We could solve this by not setting aria-activedescendant if the user tabs to a tab-to-search result. However, we'd still want to set aria-activedescendant if the user used the arrow keys, since they might move up and down the list. I'm not sure if it's feasible to make this distinction in the code.

Thanks for your feedback Jamie; I address a few points below. I haven't yet made significant progress on this bug and will be out of office on Monday for Canadian Thanksgiving. Seeing as tab-to-search targets 83 and the soft freeze is next Thursday, I'm going to unassign myself from this bug to increase the chance that it is done on time. If anyone has some free time before Tuesday midday EST and wants to pick it up, please feel free. Otherwise, I'll reassign myself on Tuesday.

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

I'm guessing the tab-to-search result is quite prominently visible (perhaps more prominent than other results somehow?) and would "get the user's attention". However, I'm guessing it also isn't "intrusive".

The tab-to-search result almost always looks the same as normal results, although it does have a small animation to draw attention to it when it is shown. I say "almost always" because the first few times we show it, it is twice the size of a normal result and displays some extra text. That's our onboarding for the feature.

One other problem is that when a screen reader user presses tab, the tab-to-search result will get "focused". Users may think they then have to press enter to activate it.

After pressing tab, the user can start typing immediately to search with the tab-to-search engine. That said, they can also press enter first. The difference is that pressing enter will replace their results with results pertaining to that engine (their search history from that engine and any of their history results from that engine's hostname). In either scenario, they will have a clean input to start typing. We can still set aria-activedescendant differently however, as you suggest.

This is a pretty simple implementation of the approach discussed in the bug. When a tab-to-search result is shown, we announce it to screen readers. We keep track of which engines are announced to be sure we don't keep announcing the same engine as the user types.

This approach is maybe slightly crude, but I didn't find a working elegant approach. One approach I considered is checking for tab-to-search results in the loop in UrlbarView._updateResults. After the loop is finished, if we found a tab-to-search result, we go back and change the aria-label on the action text of the prior result to something like "Visit, or press Tab to search with { $engine }. This didn't work because we don't read action text for the heuristic result as the user types. This is presumbably to avoid disrupting the user as they type. This is what my patch does regardless, however... Since Jamie was skeptical about whether we should announce this at all, I put this behaviour behind a default-true pref, browser.urlbar.tabToSearch.accessibility.announceResults.

NI Marco for awareness and further input. I'd prefer to get Marco's input on this before r+ing, but he's on PTO and I don't want to delay this.

For future reference, the pref to control whether tab-to-search results are announced to screen readers while typing is browser.urlbar.accessibility.tabToSearch.announceResults.

https://hg.mozilla.org/mozilla-central/rev/1a7978303f22

This pref is set to true in my profile. However, in current Nightly, I don't hear anything when I start typing g o o for "google.com", or such. If I tab, however, the URL bar changes to "Search with Google". So the hints probably don't appear. How do I reset something so that I do get these announced/shown?

You probably have browser.urlbar.autoFill disabled, like I did. That has to be enabled for this to work.

No, that is set to true.

Harry, any idea why this doesn't trigger for Marco? For me, as soon as I type "go" ("g" isn't enough for me), it triggers the announcement.

I just tried it myself with a screen reader running. It works on Windows with NVDA but nothing is announced with VoiceOver on macOS. Marco, are you on macOS? Jamie, are there known incompatibilities between A11yUtils.announce and VoiceOver?

I'm on Windows as well and am trying with NVDA, and don't get an announcement ever. Since I am blind, I don't know if this tab to search thing even fires, although it is clearly turned on in my profile, at least TabToSearch properties all seem to indicate that in about:config. The fact that this doesn't work on Mac yet is known, Morgan is just now implementing support for live regions and alerts for VoiceOver.

I finally got it to fire, without changing anything. I'm OK with this.