1606923 - [meta] Figure out accessibility behaviour for Tips

Status: RESOLVED FIXED

(Firefox :: Address Bar, task, P2)

Description

[Harry Twyford]

We should check what is read out when a tip is shown on a search engine homepage. We should also check the state of keyboard a11y for this feature.

Comment 1

[Drew Willcoxon :adw]

This should Just Work since we fixed bug 1578445... We didn't test search tips/nudges specifically in that bug, but I don't see why they wouldn't be OK. But, good to verify.

Comment 2

[Harry Twyford]

iirc the concern around this feature wasn't whether the Tip result is accessible (we already checked that when we did the experiment) but was whether screen readers should announce Search Tips. They works fine in a sight-based context, but may be annoying if a screen reader is announcing, say, the google.com homepage, and then the text from the Search Tip jumps in. The problem is exacerbated by the fact that there's a 200ms delay on Search Tips appearing, so the screen reader might already be a few words into announcing the page.

I would imagine our solution to this could take a page from our a11y approach to UI notifications, or add-on recommendations in the Urlbar.

Jamie, can you please let us know how screen readers handle Firefox notifications that appear over page content and perhaps offer some guidance on how to handle this? For context, Search Tips appear inside the Urlbar and over the page when the user is browsing to a new tab or to their default search engine's homepage. They're meant to draw attention away from the page and towards the Urlbar.

Comment 3

[James Teh [:Jamie]]

Can you provide a real world scenario of how search tips might be used? It's difficult to provide a11y UX guidance without an understanding of the kinds of things this helps users achieve, and I don't feel like I have that understanding yet.

Also, how do tip results and search tips relate to each other? When I looked at tip results, my understanding was that these might appear in response to a particular kind of search, but I didn't know there was another component: the tip itself.

As far as screen reader behaviour for notifications, they generally interrupt whatever is being read. The latest beta of NVDA does resume content interrupted by a notification, but JAWS (and earlier versions of NVDA) don't do this. Whether this is actually a problem depends somewhat on the UX we're going for.

Given that you're saying search tips appear over the page somewhat, that suggests they do interrupt sighted users to some extent as well (more than CFR, for example). They aren't modal (you don't have to explicitly dismiss them to continue), but they're still an intentional, noticeable interruption. That suggests it's probably reasonable for them to interrupt screen reader users as well. However, as above, I need some idea of real world usage to make a solid assessment here.

Comment 4

[Harry Twyford]

Sure! First, I want to clear up three related terms that have been confused for each other in a number of bugs: tip results, Search Tips, and Interventions.

Tip results are a new result type in the Urlbar. Tip results are three times the height of a normal result and contain an icon, some text offering a "tip" based on the context the user is in, a button with which the user can act upon the tip, and an optional help/"what is this?" button. We checked the a11y of the tip result in bug 1578445.

Interventions are one of two new applications of tip results. They are tip results that appear in response to specific searches. For example, if a user searches "clear history firefox", we will show a tip result ("an Intervention") that offers a button to clear history. We have another that appears in response to a search for "firefox is slow" that offers a button to refresh the user's profile. There is an open bug to check Intervention's a11y at bug 1606921.

Search Tips are the other application of tip results. They appear when the user browses to a new tab or to the homepage of their default search engine (e.g. google.com). The text of the tip encourages the user to use the Urlbar to search instead of google.com. The actionable button reads "Okay, Got It" and focuses the Urlbar. We only show Search Tips a few times over the lifetime of a profile and only under certain conditions. In the new tab case, we open the view and it contains a single tip result ("the Search Tip"). The Urlbar is focused, as it usually is when a new tab is opened. In the search engine homepage case, we don't want to steal page focus from Google, so we introduced a new state: the Urlbar view opens without the Urlbar being focused. The view still only contains the one tip result, encouraging the user to search with the Urlbar instead of with the search engine homepage. Mouse users can either ignore the tip and continue searching with google.com, or they can click the "Okay, Got It" button at which point the focus changes from the Google search box to the Urlbar.

As it stands currently, upon seeing a Search Tip on a search engine homepage, to accept it a keyboard user would have to focus the Urlbar (Accel+L), down arrow to the tip result, and press Enter on the "Okay, Got It" button. The only result of this action would be that the Urlbar is focused (again).

Search Tips are indeed meant to interrupt sighted users to some extent. Certainly more than CFR. And yes, they aren't modal.

Comment 5

[James Teh [:Jamie]]

Thanks for the thorough detail. It's immensely helpful.

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

Search Tips are the other application of tip results. They appear when the user browses to a new tab or to the homepage of their default search engine (e.g. google.com). The text of the tip encourages the user to use the Urlbar to search instead of google.com.

It does feel like it might be reasonable to use role="alert" for this, or the a11y announcement API if we need finer control over the message.

The actionable button reads "Okay, Got It" and focuses the Urlbar.

It's probably not useful for a screen reader to read this bit, though.

As it stands currently, upon seeing a Search Tip on a search engine homepage, to accept it a keyboard user would have to focus the Urlbar (Accel+L), down arrow to the tip result, and press Enter on the "Okay, Got It" button. The only result of this action would be that the Urlbar is focused (again).

I wonder whether it makes sense to dismiss the tip automatically if the user focuses the URL bar with the keyboard (or perhaps just focuses the URL bar via any method)? If the user focuses the URL bar, it's reasonable to assume they (probably) got the message and decided to act on it, rather than continuing to search from the Google home page. Certainly, a screen reader user isn't going to intuitively understand that the tip is a search bar result and they can hit down arrow to get to it. For that matter, a sighted keyboard user might not realise this either. That said, there's probably no harm in not dismissing it, at least for a screen reader user, assuming it goes away at some point by itself.

Copying Marco and Asa for awareness and thoughts.

Comment 6

[James Teh [:Jamie]]

One other thing worth noting is that users with cognitive or attention disabilities might find search tips to be problematically distracting or intrusive. Based on discussions with impacted users about notifications, etc., some of these users may be overwhelmed by these distractions and simply stop using Firefox.

Comment 7

[Drew Willcoxon :adw]

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

As it stands currently, upon seeing a Search Tip on a search engine homepage, to accept it a keyboard user would have to focus the Urlbar (Accel+L), down arrow to the tip result, and press Enter on the "Okay, Got It" button. The only result of this action would be that the Urlbar is focused (again).

I wonder whether it makes sense to dismiss the tip automatically if the user focuses the URL bar with the keyboard (or perhaps just focuses the URL bar via any method)?

Verdi's spec actually called for that, but I didn't implement it in the experiment. I can file a bug for that.

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

One other thing worth noting is that users with cognitive or attention disabilities might find search tips to be problematically distracting or intrusive. Based on discussions with impacted users about notifications, etc., some of these users may be overwhelmed by these distractions and simply stop using Firefox.

There's a "Recommend features as you browse" option in preferences. I don't know whether it's OK for us to include tips in that, but if we did, do you think it would benefit those users?

Comment 8

[Drew Willcoxon :adw]

I filed bug 1611873 for dismissing tips when the user focuses the urlbar.

Comment 9

[James Teh [:Jamie]]

(In reply to Drew Willcoxon :adw from comment #7)

There's a "Recommend features as you browse" option in preferences. I don't know whether it's OK for us to include tips in that, but if we did, do you think it would benefit those users?

I see this is now covered by bug 1613048. There's a question of how users with cognitive disabilities would discover this, but I think this is certainly a good place to start. I don't have any better answers at this point. Thanks for considering this.

Comment 10

[Marco Bonardo [:mak]]

Jamie, we are looking for final sign-offs of features, now that tips are enabled in Nightly, is there any a11y blockers for shipping the feature, or have all of your concerns been addressed? If things look good, feel free to resolve this bug.

Comment 11

[Harry Twyford]

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

(In reply to Harry Twyford [:harry] from comment #4)
It does feel like it might be reasonable to use role="alert" for this, or the a11y announcement API if we need finer control over the message.

FIled bug 1615301 for this.

Comment 12

[James Teh [:Jamie]]

I think we're good here once bug 1615301 is done, but I'd prefer to leave this open until then.

Comment 13

[James Teh [:Jamie]]

:adw noted:

We do actually "focus" the tip's button in the case of the onboarding tip, though -- at least the input is focused and the button is highlighted so that when you press enter, you activate the button. For the redirect tip, we don't change the current focus.

I wasn't aware of the onboarding tip. How do I test that? That may have different implications for a11y.

Comment 14

[Harry Twyford]

There's a hidden pref, browser.urlbar.searchTips.test.disableChecks, up for review in bug 1614651. If/Once that lands, you can set that pref to true and an onboarding tip will be shown every time you open about:newtab. Fwiw, with that pref on the redirect tip will also be shown every time you open your default search engine's homepage, provided it's one of Google, Bing, or DuckDuckGo.

Comment 15

[Harry Twyford]

It's also worth pointing out that although the input is focused and the confirm button is highlighted, the onboarding tip is meant to be easily dismissed. Any of the following will dismiss the onboarding tip:

• Clicking the confirm button
• Pressing enter (thus pressing the confirm button)
• Clicking in the Urlbar
• Pressing Accel+L or another Urlbar-focus keyboard shortcut
• Typing in the Urlbar
• Pressing Escape, or closing the Urlbar results in any other way

To be clear, the onboarding tip appears on about:newtab.

Comment 16

[Harry Twyford]

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

There's a hidden pref, browser.urlbar.searchTips.test.disableChecks, up for review in bug 1614651. If/Once that lands, you can set that pref to true and an onboarding tip will be shown every time you open about:newtab. Fwiw, with that pref on the redirect tip will also be shown every time you open your default search engine's homepage, provided it's one of Google, Bing, or DuckDuckGo.

I landed this patch and it should be in Nightly soon. The final hidden pref name is browser.urlbar.searchTips.test.ignoreShowLimits.

Comment 17

[James Teh [:Jamie]]

Thanks. I tried this pref.

For the onboarding tip, even though the address bar is focused and the onboarding tip is active, it doesn't get a11y focus. My guess is that this is because of the code which suppresses a11y focus unless the user actively interacted with the suggestions (e.g. up/down arrow). We probably don't want to change this; focusing the button will probably annoy the user more than helping them, since a screen reader user at least won't necessarily understand that they can type into the address bar at this point. The role="alert" will at least report the message.

On the flip side, role="alert" is going to be weird in the case of the redirect tip. Right now, the text of that tip reads:

Start your search here to see suggestions from Google and your browsing history.

The problem is that a screen reader is going to just read that message, and "here" will have no context. (The user will ask themselves: start your search where?) In contrast, the onboarding tip is clearer:

Type less, find more: Search Google right from your address bar.

This is going to be tricky to fix. Two solutions come to mind:

1. Try to come up with a message which mentions the address bar without hurting the UX for sighted users.
2. I'm generally not a fan of alternative messaging for screen readers, but this may be one example where it's necessary. That said, I don't know how we'd implement that. We do have A11yUtils.announce, but I'm not sure if it's feasible for that to be called when the tip is displayed. If we went down that path, we'd abandon bug 1615301, since using role="alert" for the onboarding tip and announce for the redirect tip sounds like a world of pain and confusion.

Comment 18

[Marco Bonardo [:mak]]

Both are valid possibilities, but they require uplifting new strings, so the fix may be delayed to 75... That means in 74 we'd announce the non-accessible "here" string.

@verdi, what do you think, can we change the phrase to be more accessible?

Comment 19

[James Teh [:Jamie]]

(In reply to Marco Bonardo [:mak] from comment #18)

Both are valid possibilities, but they require uplifting new strings, so the fix may be delayed to 75... That means in 74 we'd announce the non-accessible "here" string.

I understand. In that case, I'd prefer to delay the role="alert" or A11yUtils.announce change until we can get the proper strings. While it's important that things are accessible when we ship, I think screen reader users aren't going to "miss" this feature in 74, and I think a confusing experience is worse than no experience in this case.

Comment 20

[Meridel [:meridel]]

Please change the string to: Start your search in the address bar to see suggestions from Google and your browsing history.

Comment 21

[James Teh [:Jamie]]

We're good to go here now that bug 1615301 is done. Just to recap, while not ideal, we're okay with bug 1615301 not being in 74; see comment 19.

Comment 22

[Marco Bonardo [:mak]]

The feature won't ship in Firefox 74 anyway, we plan to ship it in Firefox 75, so it's all good.
We'll just run a pref-flip experiment in Firefox 74 with the new design enabled.