Add keyboard controls for SiteSelector

[marekhrabe]

This PR adds keyboard support to every place where you can select sites. That means Up & Down arrows to move through sites in list, Enter to select and also Esc to close without changing a site.

These new keyboard features go well together with searching functionality to narrow results and that's why keystrokes are being listened directly on the search input.

Here is a quick preview of the implementation:

Testing Instructions

Places to test

• My Sites -> Switch Site (this is called SitePicker)
• New Post (SitesPopover)
• Help -> Contact us (SitesDropdown)
• Go to /sites (this is pure SiteSelector)

Each place should follow these rules

1. Mouse interactions have not changed - you can hover a site (it turns blue) and clicking a site still does the expected action
2. Search field is visible for users with >6 sites and is auto-focused. For users with <6 sites, the search should appear once they start typing some text
3. No site is initially highlighted when you open the selector.
4. Selected site has grey background
5. Pressing Up or Down changes highlighted site (and scrolls if needed)
6. With the last site in the list highlighted, pressing Down will select the first site and vice versa.
7. Pressing Enter triggers exactly the same action as clicking the highlighted site
8. Pressing Esc just closes the selector without any side-effects like changing a site or redirecting user
9. When you highlight some site using mouse and then press Up or Down, the highlight should move from last mouse-highlighted site (eg. not from the start of the list)
10. When you use mouse to highlight sites and then leave site selector with your cursor, the highlight should disappear and when you use arrow keys now, they should move from the beginning of list

Naming conventions

This is what "highlighted" site looks like. Site can be highlighted by navigating with arrow keys or by hovering on site with the mouse cursor.

This is what "selected" site looks like:

#### Altering between keyboard and mouse

I modeled those interactions after native system menus.

Test live!

Test live: https://calypso.live/posts?branch=add/site-selector-keyboard-accessibility

Closes #8
Closes #6024

[mtias]

Nice work @marekhrabe! It seems to be working rather well. One thing I noticed is that if I press the down arrow in the sidebar picker to move the highlighted site, and then wait, it eventually resets to the All Sites item being highlighted.

[mtias]

The behaviour of the sites dropdown is a bit awkward now, it should highlight the currently selected site when you open the dropdown, not the first in the list.

[mtias]

it eventually resets to the All Sites item being highlighted

Ok, this seems to be related to the change "the first item is highlighted (previously currently opened site was highlghted)". What was the reason for that change?

[mtias]

the search field is now always visible (previously it showed up only for user that has more than 6 sites)

I don't think this is a good change. What was the reasoning for it? The picker works much better without search when you have only a few sites. Search should be an enhancement to navigation only when it makes sense.

[marekhrabe]

One thing I noticed is that if I press the down arrow in the sidebar picker to move the highlighted site, and then wait, it eventually resets to the All Sites item being highlighted.

I suspect one of my latest changes to cause that (bc95cda1f8cd87c2414a359ebde40de805044e3f). I was able to reproduce and I'll push a fix for that soon.

The picker works much better without search when you have only a few sites. Search should be an enhancement to navigation only when it makes sense.

I think this might be truer for the previous version than this one. Previously, the search was something additional and optional that you could use and then you had to come back to your mouse to confirm your selection. This time, I tried to make the search a core feature of new selectors. Even if you have 4 sites, I feel like having the ability to type, for example, just the first letter and hitting Enter is faster than arrow navigation through the list. At least that's how I use this kind of components. My interactions with Sublime's/Atom's Go to anything were my inspiration.

The behaviour of the sites dropdown is a bit awkward now, it should highlight the currently selected site when you open the dropdown, not the first in the list.

(Btw: that CSS has nothing to do with that. It was some legacy code that was not used, as selected sites were completely hidden in Dropdowns.)

The reasoning was that if you start with the selected site, you might run easily into edge cases:

• selected site is always hidden in SitesDropdown (what to select now?)
• when you visit /sites route, there is no selected site at the moment (what to select now?)

I thought that the most reasonable way (and working in all cases), is to select the first one. When there are more solutions, I aim for predictability and consistency in all scenarios and this was the case.

As a little technical bonus, it allows us from having a double render of SiteSelector (see 329b83fa41dbf5dcacfe8a8a57f987da8025b71b), where we first need to render sites to know their order and after they are rendered, determine which one to highlight, save that to the state and rerender. Anyway, there is probably a way around that, but this is the most simple solution and they usually tend to work the best.

The only component that is really affected by this change is probably the picker (left sidebar "Switch Site"). It behaves a little different than the previous implementation, but I don't think it is a bad thing. You still do? I think that users mainly use that component to change the current site, not to see what is selected.

Thanks a lot for finding time to review this, @mtias. I would love to continue the discussion on points that I explained here if they change your point of view in some way.

[alisterscott]

I've tested this and it seems to work well 👍
I personally don't mind the search field for < 4 sites as it's consistent and works well with the arrow keys.
Mobile regression test was fine also - I made sure that the menu page is still shown on selection.
Visiting /sites was broken for me, but I checked https://wordpress.com as it's broken there also so not this PR. I raised this as a separate bug: #5983

[alisterscott]

I did notice the arrow down behaves differently for non-webkit browsers (Firefox, IE11, Edge) in that the whole panel moves with the arrow, whereas Chrome moves individual sites one at a time.

For example in Firefox:

is different to Chrome:

[marekhrabe]

…whole panel moves with the arrow…

Which one do you prefer, @alisterscott? The Chrome one feels better to me. It works like that probably because Webkit implements (non-standard, but commonly used) scrollIntoViewIfNeeded and others have just pure scrollIntoView (which always scrolls). We already have some kind of shim in our codebase. I'll take a second look if I can use it in this case too.

Edit: I implemented cross-browser version that is now consistent across Chrome, Firefox & Safari that I tested.

[marekhrabe]

One thing I noticed is that if I press the down arrow in the sidebar picker to move the highlighted site, and then wait, it eventually resets to the All Sites item being highlighted.

The bug @mtias mentions should be fixed now. It now resets to the first available item only once you open the sidebar. Not in the middle of interactions. We can now discuss further if we want to change the behavior.

[folletto]

I think this might be truer for the previous version than this one. Previously, the search was something additional and optional that you could use and then you had to come back to your mouse to confirm your selection. This time, I tried to make the search a core feature of new selectors. Even if you have 4 sites, I feel like having the ability to type, for example, just the first letter and hitting Enter is faster than arrow navigation through the list. At least that's how I use this kind of components. My interactions with Sublime's/Atom's Go to anything were my inspiration.

Note that the fact that previously you had to use the mouse was an incomplete implementation of the design, so it was already meant to be disappearing when less than 6 sites AND still be triggered with enter.

"Faster" here is a relative thing. We're talking of very very few keystrokes, and it's again an edge optimization that is... very edge: less than 6 sites and power user. Even there, just arrow down a few times and you're done. We're talking of a switch time still likely around the second or two.

Given the marginal gain, I wouldn't add the extra UI for users with less than 6 sites. The search examples you make (Sublime / Atom) are geared for people with terminal experience, text-heavy and in an interface primarily textual. UIs are designed around users.

So, in absence of any heavier weighting that makes tip the decision for search, I'd keep the optimization we have for a less cluttered UI, even if it costs a few milliseconds to an expert user.

The reasoning was that if you start with the selected site, you might run easily into edge cases:

1. selected site is always hidden in SitesDropdown (what to select now?)
2. when you visit /sites route, there is no selected site at the moment (what to select now?)
   I thought that the most reasonable way (and working in all cases), is to select the first one. When there are more solutions, I aim for predictability and consistency in all scenarios and this was the case.

The two edge cases aren't really issues. If the active site isn't in the list, we don't highlight anything. It's meant to work that way (plus we have an iteration 2 of the SitesDropdown design that actually shows the selected item, centered).

The reason we highlight the current site is acting as a reference point: "this is where you are". It's a relevant marker, and has a specific function.

Also: there are two highlight statuses already to cover the cases:

1 — Highlight as selected — the dark background:

2 — Highlight as focus — the light background

Keyboard navigation is a focus kind of highlight, so shouldn't touch or change the selected state.

[marekhrabe]

Also: there are two highlight statuses already to cover the cases:

When you suggest I change the keyboard highlight color to the light colored version (the same as a mouse hover), don’t you think that might look confusing when combined with those mouse hovers? In one moment, you can have “selected site”, highlighted keyboard focus, and mouse hover in one component. I don’t say that it’s a common situation, but it might look funny and it might not be apparent what would be confirmed by pressing enter. What do you think?

[folletto]

When you suggest I change the keyboard highlight color to the light colored version (the same as a mouse hover), don’t you think that might look confusing when combined with those mouse hovers? In one moment, you can have “selected site”, highlighted keyboard focus, and mouse hover in one component. I don’t say that it’s a common situation, but it might look funny and it might not be apparent what would be confirmed by pressing enter. What do you think?

Someone moving with the keyboard and then using the mouse, and while hovering pressing enter seems super edge case. It could be addressed just by being stateful if the interaction is triggered by mouse (once you hover, the keyboard focus is lost) or keyboard (once you use the keyboard, the mouse hover gets overridden). Doable, but imho not worth the effort given the likelyhood of the issue. I'd just go for the double highlight for now (which I think it's going to be the outcome if we don't do anything special).

[folletto]

In terms of styling, I'd note that the sidebar currently has one bug: the focus/hover states doesn't override the selected state.

The popover instead works as expected:

So I'd:

1. Fix the hover/focus bug.
2. Use blue as hover/focus effect instead of the pale gray background (as the popover).

[marekhrabe]

1. Fix the hover/focus bug.
2. Use blue as hover/focus effect instead of the pale gray background (as the popover).

That sounds reasonable, on it :)

[ryanboren]

Testing this in Chrome and Firefox. In Chrome, Esc clears the search field when searching in the sidebar. In Firefox, Esc does not clear the search field.

[folletto]

@ryanboren As far as I know that's a difference in browser implementation for the input type="search" control. Firefox doesn't clear on ESC, Safari/Chrome do.

Can you double-check it from this demo?

[marekhrabe]

I can confirm that latest Firefox does not clear the search input on the demo page @folletto shared. I have same results with WordPress.com + Firefox = ESC does not clear the input.

There is an issue for that #5771 that I think we should reopen, as it still describes a present problem that was not fixed.