In the rich list of autocomplete results, tab should not move through all the items

NEW
Unassigned

Status

()

defect
P2
normal
Last year
5 months ago

People

(Reporter: MarcoZ, Unassigned)

Tracking

(Blocks 1 bug, {access, regression})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox60 fix-optional)

Details

(Whiteboard: [fxsearch])

STR:
1. Open Firefox.
2. Press CTRL+L or Alt+D to move to the address field.
3. Type some words so the Google Search becomes the first AutoComplete item.
4. Press DownArrow to focus that.
5. Press Tab.

Expected:
Tab should move to the one-off buttons that allows searching for the term with other supported search engines.

Actual: Tab moves through all the items in the autocomplete list, cycling around, effectively trapping keyboard focus.

On none of our supported platforms is it common to tab through list items, even when they are part of an autocomplete. The expected keyboard interaction is to use up and down arrows for that. Tab instead moves focus out of that list, and depending on where focus lands, closes the list or not. In our case, if focused on a Search item, moving focus to the one-off search buttons is the appropriate and expected behavior.

Marco, I am not certain if this is also a regression from bug 1427366 or if this was the case even with the old control. But it is a bug that should be fixed nevertheless. Along with the one-off search buttons bugt I am going to file shortly. NI'ing you so you can prioritize.
Flags: needinfo?(mak77)
Blocks: 1437528
(In reply to Marco Zehe (:MarcoZ) from comment #0)
> Tab should move to the one-off buttons that allows searching for the term
> with other supported search engines.

That's correct, in the address bar you can use ALT+DOWN or ALT+UP to move to the one-off buttons.

We clearly considered also TAB, to make it work like the search bar, but there are 2 problems with that:
1. our address bar always allowed both DOWN and TAB to move through results, thus we may have a lot of users with a muscle memory of TAB to cycle results.
2. there is a proposal to support the "Tab to search" behavior of Chrome (bug 782557) and that would further complicate things.

> Marco, I am not certain if this is also a regression from bug 1427366 or if
> this was the case even with the old control.

If it's about the Address Bar, it's not a regression, it was a deliberate choice to not break users muscle memory.
We can clearly re-evaluate, but we need data to tell how many users we'd break.
We'll need that data also for tab to search, so it's likely worth collecting it.

CC-ing dzeber to know if we have any data to answer the question (How many of our users use tab to cycle through results in the address bar), but I doubt we have it.
Component: Autocomplete → Address Bar
Flags: needinfo?(mak77) → needinfo?(dzeber)
Priority: -- → P2
Product: Toolkit → Firefox
Whiteboard: [fxsearch]
Also :phlsa for eventual UX insight. I'm not sure how to coalesce so much functionality like one-offs, tab-to-search and existing users muscle-memory into the only TAB key.
Flags: needinfo?(philipp)
(In reply to Marco Zehe (:MarcoZ) from comment #0)
> Expected:
> Tab should move to the one-off buttons that allows searching for the term
> with other supported search engines.

Bug 1292321 has the background on the decision that this should not happen that Marco B. mentioned.
(In reply to Marco Bonardo [::mak] from comment #1)
> (In reply to Marco Zehe (:MarcoZ) from comment #0)
> > Tab should move to the one-off buttons that allows searching for the term
> > with other supported search engines.
> 
> That's correct, in the address bar you can use ALT+DOWN or ALT+UP to move to
> the one-off buttons.

That is totally unintuitive. I am a versed keyboard user, and I would never ever have thought of using alt+up arrow or alt+down arrow to move to these buttons. In Windows and Linux, alt+down drops down lists of items, like on a html:select element, for example. Alt+up arrow closes that same dropdown. Making them behave so differently in the awesome bar breaks several conventions on these platforms. Mac handles dropdowns differently traditionally, so they are a separate story.

> We clearly considered also TAB, to make it work like the search bar, but
> there are 2 problems with that:
> 1. our address bar always allowed both DOWN and TAB to move through results,
> thus we may have a lot of users with a muscle memory of TAB to cycle results.

Like was mentioned in bug 1292321 comment #11, Microsoft removed the tab key focusing the search results in Edge, because what IE did went against their own conventions. Note that you cannot even tab through the search results in the Windows 10 start search box. But up and down arrows cursor through these items and allow you to select one.

In Firefox, you cannot tab through menu bar items, or through dropped down items in an opened html:select element either, so why should our address bar behave differently? It may indeed inconvenience users for a bit who are used to this, but in the end, consistency is better than inconsistency.

> 2. there is a proposal to support the "Tab to search" behavior of Chrome
> (bug 782557) and that would further complicate things.

Yeah I hate that feature in Chrome to be honest, since it, too, goes against all conventions the tab key stands for on all three platforms.

> We can clearly re-evaluate, but we need data to tell how many users we'd
> break.

I think we *must* reevaluate this decision. I was never involved in the decision for tab to move through search results in the first place, or I would have intervened very strongly. But this decision must have been made at a time where I was already at Mozilla, so whoever made this decision went past the accessibility team at that time.

Note that my statements are also being backed up by the WAI-ARIA Web Authoring guidelines for autocompletes: https://www.w3.org/TR/wai-aria-practices-1.1/#combobox
There, it is clearly stated that tab should move to the next page element, not move through the suggestions popup.

CC'ing Jamie from the accessibility team, who is also a heavy keyboard (and screen reader) user, if he has more input to offer.
Flags: needinfo?(jteh)
Oh and additionally: Neither I nor any other accessibility team member was involved by either engineering or UX when bug 1292321 was being discussed. I would have pointed out the above items then already as arguments against reverting that change.
(In reply to Marco Zehe (:MarcoZ) from comment #4)
> I think we *must* reevaluate this decision. I was never involved in the
> decision for tab to move through search results in the first place, or I
> would have intervened very strongly.

We totally agree that tab should not cycle, none of us was part fo that decision.
The problem is that the behavior comes from ancient Firefox versions (likely far before Firefox 3), and we surely have quite a few vocal consumers of it, since when it broke (accidentally) we got various bug reports.

The problem is to understand how many users we'll break and how to present that change properly (if we need to). That's why I think we should add some temporary telemetry, and if we figure out the problem only affects a minor population, changing it won't look that scary.
I'll file a bug to add telemetry and move the ni to Dave there.

For a "tab to search" feature we can surely find an alternative key combo, no doubt. Chrome users moving to Firefox may be used to that, but if we present some kind of "hint" explaining a different combo it should do.
Flags: needinfo?(dzeber)
And bug 1292321 didn't involve a11y because it was just fixing a regression, we just reverted to the status quo because we didn't have data to do differently.
Depends on: 1437803
(In reply to Marco Zehe (:MarcoZ) from comment #4)
> CC'ing Jamie from the accessibility team, who is also a heavy keyboard (and
> screen reader) user, if he has more input to offer.

I don't have anything to add. I agree with comment 4 and it seems we have some alignment and a path forward in comment 6.
Flags: needinfo?(jteh)
Depends on: 1449488
Fwiw, telemetry reports that on Beta cycling through results with Tab is 0.03% (0.25% in Nightly), so it looks like we'd not be disrupting too many use-cases.

But UX has a new design for one-off buttons in general, and we'll likely look into that.
Flags: needinfo?(philipp)
See Also: → 1527695

I'd argue that if you are typing in a text box and hit tab, focus should go to the next text box as it does roughly everywhere else. That would mean that if you have the search box enabled, hitting tab in the address bar - no matter its state - should move focus to the search box. The fact that it does not irritates me every day.

You need to log in before you can comment on or make changes to this bug.