Announce search mode to screen readers
Categories
(Firefox :: Address Bar, task, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox81 | --- | fixed |
People
(Reporter: bugzilla, Assigned: bugzilla)
References
Details
(Keywords: access)
Attachments
(1 file)
We plan to change the behaviour of the search engine one-offs in the Urlbar to act as filters on a search instead of them immediately performing a search. To use an Amazon search as an example, a user could select the Amazon one-off, type "coffee makers" and get search suggestions for that query from Amazon. They could also first type "coffee", and get suggestions from their default engine and history/bookmarks as they currently do, then select the Amazon one-off, in which case those results would be replaced with Amazon search suggestions. We will be adding a visual indicator to the Urlbar that says "Amazon" to show the user that they are in Amazon search mode, and only Amazon search suggestions will be shown in the Urlbar.
We need a similar indicator for screen readers. Just reading the word "Amazon" off the visual indicator probably does not adequately explain what is happening. We could have screen readers announce something along the lines of "Type to search Amazon" when Amazon search mode is entered. We should work with the a11y team to figure out behaviour here.
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
Hi Jamie, I think this is ready for your input. This feature, which we're calling "search mode", should launch later today in Nightly. It works as described in comment 0. If the user clicks a search engine one-off, we keep the Urlbar panel open, keep the user's typed string, and re-query for results from the specified search engine. There are a number of other ways to enter search mode. For example, if the user types a search engine alias, like @google
, then presses enter or space, we remove the alias from the Urlbar input and enter Google search mode with an empty search string.
Since one-offs now act as filters instead of searching immediately, we also introduced one-offs for Bookmarks, History, and Tabs. They filter your query to that kind of result. For example, if the user presses the Bookmarks one-off, the visual indicator to the left of the Urlbar will read "Bookmarks" and only bookmark results will appear in the Urlbar. This is equivalent to doing a search using the bookmark alias, like typing * coffee
to search through your coffee-related bookmarks.
The keyboard-accessible way of exiting search mode is to press backspace at the start of the Urlbar input. The visual indicator appears at the start of the input, so it feels like you're backspacing it as you would a character. If the user is typing a string in search mode, they could press Accel + right arrow
to return to the start of the string, press Backspace to exit search mode, then press Accel + left arrow
to return to the end of the string to continue searching.
How might we make search mode accessible to screen readers? In comment 0, I proposed announcing Type to search <engine name>
when search mode is being entered. This language would also work for the new local one offs: we could announce Type to search bookmarks
, for example. When exiting search mode, we could maybe announce No longer searching <engine name>
. What do you think? Please let me know if you'd like any clarification.
Comment 2•5 years ago
|
||
Thanks for reaching out!
I want to test this once it lands in Nightly so I can get a feel for it.
My initial thought was that the placeholder changing should be enough, since that gets exposed as the a11y name and screen readers report the a11y name when it changes. For example, by default, it would say "Search with Google or enter address", but if you selected Amazon, it would change to "Search with Amazon or enter address". However, I see that as per bug 1647889, the placeholder is a generic "Enter search terms" or "Search the web", rather than indicating the engine name. I guess that's to avoid doubling up on the engine name when the indicator is present?
We could potentially do this with aria-label, though, using a string similar to your suggestion in comment 0. I'd probably just go with "Search Amazon", rather than "Type to search Amazon". Exiting search mode should then announce the normal placeholder.
I'd prefer to avoid using A11yUtils.announce if we can because it's somewhat more intrusive. But we'll need to see if my aria-label idea works in practice.
Assignee | ||
Comment 3•5 years ago
•
|
||
(In reply to James Teh [:Jamie] from comment #2)
I want to test this once it lands in Nightly so I can get a feel for it.
It's live now in Nightly!
My initial thought was that the placeholder changing should be enough, since that gets exposed as the a11y name and screen readers report the a11y name when it changes.
Is this still the case when the Urlbar has text in it? Say the user has already typed a string in the Urlbar, like "coffee". If they select the Amazon one-off, the search mode indicator would read Amazon
and the Urlbar input would still contain the word "coffee". Similarly, the input would still read "coffee" if they exit Amazon search mode. Visually, the placeholder is never displayed the whole time, because the input reads "coffee". Does the changing placeholder still get announced?
However, I see that as per bug 1647889, the placeholder is a generic "Enter search terms" or "Search the web", rather than indicating the engine name. I guess that's to avoid doubling up on the engine name when the indicator is present?
Yes, that's right.
Assignee | ||
Updated•5 years ago
|
Comment 4•5 years ago
|
||
(In reply to Harry Twyford [:harry] from comment #3)
My initial thought was that the placeholder changing should be enough, since that gets exposed as the a11y name and screen readers report the a11y name when it changes.
Is this still the case when the Urlbar has text in it? Say the user has already typed a string in the Urlbar, like "coffee". If they select the Amazon one-off, the search mode indicator would read
Amazon
and the Urlbar input would still contain the word "coffee". Similarly, the input would still read "coffee" if they exit Amazon search mode. Visually, the placeholder is never displayed the whole time, because the input reads "coffee". Does the changing placeholder still get announced?
When there's no label (as is the case for the address bar), the a11y engine falls back to the placeholder instead to expose as the "accessible name". However, on reflection, relying on this does feel "wrong".
I played with this a little locally. Using aria-label works quite nicely. Obviously, the implementation needs to be entirely different, but here's a super hacky patch which produces the desired results:
diff --git a/browser/components/urlbar/UrlbarInput.jsm b/browser/components/urlbar/UrlbarInput.jsm
index c4fa8e443e685..2de202336c6e8 100644
--- a/browser/components/urlbar/UrlbarInput.jsm
+++ b/browser/components/urlbar/UrlbarInput.jsm
@@ -1207,6 +1207,9 @@ class UrlbarInput {
? "urlbar-placeholder-search-mode-web"
: "urlbar-placeholder-search-mode-other"
);
+ this.window.setTimeout(
+ () => this.inputField.setAttribute("aria-label", `Search with ${engineName}`),
+ 50);
} else if (source) {
let sourceName = UrlbarUtils.getResultSourceName(source);
if (!sourceName) {
@@ -1224,10 +1227,14 @@ class UrlbarInput {
this.inputField,
"urlbar-placeholder-search-mode-other"
);
+ this.window.setTimeout(
+ () => this.inputField.setAttribute("aria-label", `Search ${this._searchModeLabel.textContent}`),
+ 50);
}
} else {
// Exit search mode.
this.searchMode = null;
+ this.inputField.removeAttribute("aria-label");
this.window.BrowserSearch.initPlaceHolder(true);
}
Assignee | ||
Comment 5•5 years ago
|
||
Assignee | ||
Comment 6•5 years ago
•
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=fab1241fc2a3f284205183d18403e9ac9d0dc47a
https://treeherder.mozilla.org/#/jobs?repo=try&revision=ec99bab6d4cb917835f794ccb28c34ba4ca29f45
Comment 8•5 years ago
|
||
bugherder |
Comment 9•5 years ago
|
||
I just tested in nightly and this works very nicely. Thanks.
Comment 10•5 years ago
•
|
||
Can you please take a look at this issue: 1665094 ?
Description
•