Evaluate tab-to-search a11y
Categories
(Firefox :: Address Bar, task, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox83 | --- | fixed |
People
(Reporter: bugzilla, Assigned: bugzilla)
References
(Depends on 1 open bug)
Details
(Keywords: access)
Attachments
(1 file)
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.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
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?
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
(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.
Comment 3•4 years ago
|
||
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.
Comment 4•4 years ago
|
||
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.
Assignee | ||
Comment 5•4 years ago
|
||
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.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 6•4 years ago
|
||
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.
Comment 7•4 years ago
|
||
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.
Assignee | ||
Comment 8•4 years ago
|
||
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
.
Comment 10•4 years ago
|
||
bugherder |
Comment 11•4 years ago
|
||
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?
Comment 12•4 years ago
|
||
You probably have browser.urlbar.autoFill disabled, like I did. That has to be enabled for this to work.
Comment 14•4 years ago
|
||
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.
Assignee | ||
Comment 15•4 years ago
|
||
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?
Comment 16•4 years ago
|
||
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.
Comment 17•4 years ago
|
||
I finally got it to fire, without changing anything. I'm OK with this.
Description
•