1437528 - One-off search buttons no longer accessible via the keyboard

Status: RESOLVED WORKSFORME

(Firefox :: Address Bar, defect, P3)

Description

[Marco Zehe (:MarcoZ)]

STR:
1. Open Firefox.
2. Press Alt+D or Ctrl+L to move to the address bar.
3. Type in some search terms.
4. Press Tab to try and move to the one-off search buttons to search for the term with another supported engine.

Expected:
As with the old search box, these one-off buttons should be focused one by one if tabbed through.

Actual: Only the autocomplete results get focus, see bug 1437524, which is unintended behavior. But the one-off search buttons are never reached. Keyboard users cannot use them at all.

Marco, I'm NI'ing you since this bug is very closely related to bug 1437524, and they should be fixed in tandem if possible.

Comment 1

[Marco Bonardo [:mak]]

(In reply to Marco Zehe (:MarcoZ) from comment #0)
> Marco, I'm NI'ing you since this bug is very closely related to bug 1437524,
> and they should be fixed in tandem if possible.

They are more or less the same thing.
The address bar doesn't use tab like the search bar, for the reasons exposed in https://bugzilla.mozilla.org/show_bug.cgi?id=1437524#c1

This is not a recent change as far as I can tell, it always worked like that. One-offs in the Location Bar are accessible through ALT+DOWN or ALT+UP.

Comment 2

[Dave Zeber [:dzeber]]

However, you can reach the one-off buttons using the arrow keys. For me, pressing the down arrow will run down the list of results, and from the last result it will then progress across the row of one-off buttons, then over to the settings cog, then back to the top of the list.

This is the opposite of the behaviour I personally would expect. I would expect <Tab> to access the one-off buttons, and the arrow keys to stay within the main list. I occasionally press the up arrow from the first result, expecting it to jump to the bottom of the list, but it lands on the settings cog instead.

Comment 3

[Marco Zehe (:MarcoZ)]

(In reply to Dave Zeber [:dzeber] from comment #2)
> However, you can reach the one-off buttons using the arrow keys. For me,
> pressing the down arrow will run down the list of results, and from the last
> result it will then progress across the row of one-off buttons, then over to
> the settings cog, then back to the top of the list.
> 
> This is the opposite of the behaviour I personally would expect. I would
> expect <Tab> to access the one-off buttons, and the arrow keys to stay
> within the main list. I occasionally press the up arrow from the first
> result, expecting it to jump to the bottom of the list, but it lands on the
> settings cog instead.

Yes, this is what bug 1437524 is all about and I am getting some pushback on. :(

Comment 4

[Drew Willcoxon :adw]

As Marco B. says, this isn't 100% a regression since the urlbar and search buttons in the urlbar have always worked like this.  So I'm tempted to remove the regression keyword.  But if you compare it to the search bar and consider it in light of the fact that all new profiles only get the urlbar by default, maybe it's fair to call it a regression.

Comment 5

[Marcia Knous [:marcia]]

Adding Jeff here per discussion in triage as it seems some of this might be a product related decision based on comments in the bug in Comment 3.

Comment 6

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Marcia Knous [:marcia - needinfo? me] from comment #5)
> Adding Jeff here per discussion in triage as it seems some of this might be
> a product related decision based on comments in the bug in Comment 3.

Marco, I'm inclined to close this bug as "Works for me" explicitly because the TAB behaviour we see, non-standard as it may be according to Microsoft, is actually how Firefox and Chrome both work. 

The one thing we're missing here is some data that tells us that no-one except for Tim Taubert uses this feature ( I certainly don't ) so absent data we have to ( for now ) retain this behaviour because somethign like 90% of desktop browsers currently behave this way and have for 10 years at least.

Comment 7

[Marco Zehe (:MarcoZ)]

Fine with me, as long as we don't lose sight of this issue and collect some data soon'ish. Microsoft obviously did it, or Edge would still behave like IE did. But Microsoft changed it in Edge, and IMO, with good reason.

Comment 8

[Marco Bonardo [:mak]]

(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #6)
> Marco, I'm inclined to close this bug as "Works for me" explicitly because
> the TAB behaviour we see, non-standard as it may be according to Microsoft,
> is actually how Firefox and Chrome both work. 

I'm not going to make a WFM call without full data. The fact Chrome behaves the same is an interesting fact, considered the market share, but it's also possible they just cargo culted it from Firefox and IE.
Regardless, we have a bug here that is undiscoverability of one-offs keyboard access. A problem that didn't exist in the Search Bar. If we'd have an alternative solution, it may be easier to find a compromise.

I could also compromise towards an exposed pref to define the tab behavior.

Comment 9

[Jeff Griffiths (:canuckistani) (:⚡︎)]

[Adding Javaun who owns search access points]

(In reply to Marco Zehe (:MarcoZ) from comment #7)
> Fine with me, as long as we don't lose sight of this issue and collect some
> data soon'ish. Microsoft obviously did it, or Edge would still behave like
> IE did. But Microsoft changed it in Edge, and IMO, with good reason.

We can't make the assumption that MS's decision is data-driven vs some sort of correctness pogrom of non-standard behaviors.

(In reply to Marco Bonardo [::mak] from comment #8)
> (In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #6)
> > Marco, I'm inclined to close this bug as "Works for me" explicitly because
> > the TAB behaviour we see, non-standard as it may be according to Microsoft,
> > is actually how Firefox and Chrome both work. 
> 
> I'm not going to make a WFM call without full data. The fact Chrome behaves
> the same is an interesting fact, considered the market share, but it's also
> possible they just cargo culted it from Firefox and IE.
> Regardless, we have a bug here that is undiscoverability of one-offs
> keyboard access. A problem that didn't exist in the Search Bar. If we'd have
> an alternative solution, it may be easier to find a compromise.

Do we not also have a problem here of the undiscoverability of the one-offs period? One-ff searches in totality represent something like 1% of all searches ( source: Javaun ) so if you combine that with the number of people accessing these fields via the keyboard, we're likely looking at tiny tiny numbers.

> I could also compromise towards an exposed pref to define the tab behavior.

Do you mean a UI pref? I think we should have a fairly high bar for spending the UX and dev time for a pref. I'm not seeing it here.

The one thing I would be sensitive to here is feedback that we're being terrible to people from an accessibility perspective by binding to TAB in a non-standard or surprising way. The workaround of course is to use the dedicated search field.

I do want to stress again though, nearly all browsers for the entire history of browsers have bound TAB to hit the first item.

( aside: Vivalid uses TAB to tab between their search and address fields, heh )

Comment 10

[Marco Bonardo [:mak]]

(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #9)
> Do we not also have a problem here of the undiscoverability of the one-offs
> period?

How is undiscoverable something very prominent in primary UI? It may be horrible or useless, but it's not undiscoverable. Could also be the keyboard inaccessibility hurts them, we don't know.
Their scope is not just to be used, but also to fairly present to the user our openness towards search.
We care *a lot* about search, and this feature got lots of attention from UX and management.
We are also trying to move towards a unified urlbar like any other browser, proposing 2 separate bars for a11y doesn't go towards our goal.

> > I could also compromise towards an exposed pref to define the tab behavior.
> 
> Do you mean a UI pref? I think we should have a fairly high bar for spending
> the UX and dev time for a pref. I'm not seeing it here.

I disagree, we have 2 vocal (and probably not tiny, but we don't know) group of users used to two different behaviors, each of which is implemented by other major browsers:
1. Chrome, Firefox, IE (pretty much obsolete) use tab
2. Safari, Edge and Vivaldi don't use tab
It's not matter of establishing who is right. A pretty clear case for an a11y pref.

> I do want to stress again though, nearly all browsers for the entire history
> of browsers have bound TAB to hit the first item.

If we'd decide to change the behavior, all the browser in today's market, BUT Chrome, would have the same behavior.

Comment 11

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Marco Bonardo [::mak] from comment #10)
> (In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #9)
> > Do we not also have a problem here of the undiscoverability of the one-offs
> > period?
> 
> How is undiscoverable something very prominent in primary UI? It may be
> horrible or useless, but it's not undiscoverable. Could also be the keyboard
> inaccessibility hurts them, we don't know.

We've done eye-tracking studies in the past around search ui, and Javaun correct me if I'm wrong but users just did not find the one-off buttons.

> Their scope is not just to be used, but also to fairly present to the user
> our openness towards search.

If users don't see the one-offs while the UI is up ( because they're looking at what they are typing or the keyboard ) then this representation of openness is probably not working for us.

> We care *a lot* about search, and this feature got lots of attention from UX
> and management.

No-one is attempting to care less about search here, and yes this has our attention.

> We are also trying to move towards a unified urlbar like any other browser,
> proposing 2 separate bars for a11y doesn't go towards our goal.

The grim reality we got to was that we cannot afford to remove the dedicated search box for existing users, so I do not see any effort on the horizon or even any reasonable argument for converting existing users to the single bar UI. This is a long game.

> > > I could also compromise towards an exposed pref to define the tab behavior.
> > 
> > Do you mean a UI pref? I think we should have a fairly high bar for spending
> > the UX and dev time for a pref. I'm not seeing it here.
> 
> I disagree, we have 2 vocal (and probably not tiny, but we don't know) group
> of users used to two different behaviors, each of which is implemented by
> other major browsers:
> 1. Chrome, Firefox, IE (pretty much obsolete) use tab
> 2. Safari, Edge and Vivaldi don't use tab

I think where we're loudly agreeing with each other is the need to measure this. I'll ask around. I am a lot less comfortable with suggesting a path forward by looking at which different browsers follow which pattern.

...

> If we'd decide to change the behavior, all the browser in today's market,
> BUT Chrome, would have the same behavior.

My goal is to convince chrome users to use Firefox though, because Chrome represents the majority of our opportunity for growth in the desktop market. What I don't know is how many users use tab to switch through search results in the omnibar. Defaults matter when onboarding, and where you expose UI prefs should represent where you want to be going, not necessarily covering all possible cases for where you've been.

Comment 12

[Andrew Overholt [:overholt]]

Javaun, it was suggested you may be able to help move this discussion forward :)

Comment 13

[Marco Bonardo [:mak]]

Even if apparently nothing is happening, in the meanwhile we started collecting telemetry about users TAB/ARROWS usage. There's still a small problem with the data we must figure out (accounting for 0,6% of the users).

Based on current data (modulo the above problem filed as bug 1449488), 0,25% of the selections are made through TAB, 8,75% through arrows. This will have to be put into perspective with other facts:
1. the Chrome users pool is the largest
2. Chrome and IE are the only other browsers supporting TAB
3. accessibility team suggests cycling through tab is wrong
4. users have an hard time reaching one-off buttons
5. Windows (the most commonly used OS among our users) supports TAB in the Explorer Path Bar, and Internet Explorer, but not in Edge

It's also possible the one-off buttons design is wrong, if users have so much trouble reaching those buttons and the TAB issue could just be a red herring, but we don't have alternative suggestions atm.

Comment 14

[Milan Sreckovic [:milan] (needinfo for best results)]

This seems to be in design, not tracking for 60 anymore.

Comment 15

[Mike de Boer [:mikedeboer]]

For posterity, I added the Telemetry vizualization of the distribution of urlbar selection interaction methods to the URL field.

Comment 16

[Mark Banner (:standard8)]

Javaun is no longer working on this.

Marco, have we recently changed this / fixed it, or is there more work to do here?

Comment 17

[Marco Bonardo [:mak]]

it's pretty much still the same as it was, tab still moves through results and it's unlikely to change, due to parity with other browsers causing users habits. The workaround is still ALT+DOWN, but it's still undiscoverable. There's no short term plan.

Comment 18

[Mark Banner (:standard8)]

This affects the address bar and not the search bar, so moving across.

Comment 19

[Anna Yeddi [:ayeddi]]

Current behavior in Fx 120.0a1 and in the 118 release is the Up/Down arrow keys move the focus vertically from the address bar through list of autosuggestions and then to the first one-off search button, from where the same Up/Down arrows would move the focus horizontally between one-off search buttons. So the issue reported in this bug has been resolved: the user could navigate to/from/between these controls with keyboard alone without using any shortcuts.

This behavior could of course be further improved or included in the future awesome bar updates. I think this specific bug could be closed as it is resolved.

@Marco, do you think we need to have a separate bug to improve the keyboard navigation or is it included implicitly in the general awesome bar improvements?

Comment 20

[Marco Bonardo [:mak]]

(In reply to Anna Yeddi [:ayeddi] from comment #19)

@Marco, do you think we need to have a separate bug to improve the keyboard navigation or is it included implicitly in the general awesome bar improvements?

Our plan is actually to completely remove these shortcut buttons and instead introduce a search button in the address bar input field, similar to the mobile one. We're still at the design phase, will involve you once we have a final specification.
Because of that, I think we can close this for now (as you said it's possible to navigate, even if it may be further improved) and rather work on the future shape of it.