Warehouse: Main page should auto-focus the "search" box

[pfmoore]

On pypi.python.org, the search box is automatically focused, allowing you to immediately type in a search when you load the page. On pypi.org, the search box isn't focused, so you need an extra click to do a search.

[ewdurbin]

Discussed previously in #854

[pfmoore]

Ah thanks. I did a search but didn't find that issue, sorry.

[ewdurbin]

no need to apologize, it may be worth discussing again. i'm gonna leave this open and tag it for UX.

[nlhkabu]

The challenge with this is twofold:

1. it's annoying on mobile (as per #854)
2. It disturbs the tab index of the page. This may make it painful for users who use a keyboard to access the top menu.

Note that we are doing this on the login page - so we probably need to check this page for both these factors.

If we can find a workaround for both mobile and keyboard-only users, then I will be very happy to implement this.

[pohmelie]

Vote for this both hands.
@nlhkabu

• Now it is painful for users who use a keyboard to access search box. 11 (eleven!) tabs required!
• Google have top menu, but focus still on search.
• Do you have research about how much users go from front page with search box and how much users go via top menu? (I think 99% go to search box)
• Is it too hard to detect mobile client? (I don't think so)

[nlhkabu]

Google have top menu, but focus still on search.

To get back to the top menu on Google, you only have to tab through a handful of options. On warehouse, you would have to tab through a lot of options. To address this we could look at changing the tab index of the page to jump from the search, to the top menu.

Do you have research about how much users go from front page with search box and how much users go via top menu? (I think 99% go to search box)

We currently do not have this data, but it's safe to assume that most people use the search. However, the login link is in the top menu, so a significant number of package maintainers may also want easy access to this link.

As I mentioned earlier, I am not opposed to this (quite the opposite). I just think we need to address these two issues. As @pohmelie mentioned, it's not hard to detect a mobile client (or a small resolution), so I don't think either issue is insurmountable. Any help with implementing this feature would be appreciated!

[pohmelie]

@nlhkabu

On warehouse, you would have to tab through a lot of options

Use shift-tab to go from search box to top menu. One hit and you are on "Register" menu entry. One more hit and you are on "Log in" entry. Do not see any pain here.

[jamadden]

👎 on this from me. On legacy PyPI, I had to use an ad blocker to hide the search box due to the auto-focus. If that gets added here I'll likely do the same.

The reason is that I use a trackball with extra buttons (to help with wrist pain). Normally in a webpage those buttons work as back/forward page navigation (just like the browser toolbar or keyboard shortcut, only much easier to access with less wrist movement). But when a text field is focused, they work like the Home/End keys, moving the insertion cursor to the start/end of the line. Effectively, then, anytime I landed on a PyPI page, it broke my webpage navigation buttons, which was very jarring.

Just one data point 😄

[pohmelie]

@jamadden
UI should target most common user and, believe me, most common user use search input in pypi front page. So, there is no reason to have behavior other than focus on search box.
@nlhkabu
I think good solution is to have logic as more popular feature = less key/mouse strokes. So search is most and default, login, lets say, second and is one tab from search, etc. This maybe will broke top/down-left/right patter though.

[jamadden]

I would tend to imagine most users use Google/Bing/DDGo/browser search bar/etc to find projects and click the link that takes them to the project page (certainly that's what I usually do---and if the project isn't what I'm looking for, I hit "back", or try to 😄 ). If I'm looking for projects on PyPI it's in browse mode. But I haven't seen any user studies, maybe most people prefer to directly search on PyPI.

I was just trying to point out that even if there are mobile optimizations in place, there is still going to be some (presumably small) subset of users that find auto-focusing text fields obnoxious. (Naturally don't optimize for me, I can usually find my own workarounds, but perhaps there are those that find that more difficult...Now I'm finding myself really curious how auto-focusing text fields affect screen readers, if at all.)

[pohmelie]

@jamadden
Well, I find obnoxious pypi without autofocus search :smirk:
Of course part of users do find pypi packages via other places, but pypi have searchbox and if user is on pypi front page, then it 99% that user want to search some packages.
But… anyway, it is just my opinion, maybe I'm wrong.

[keimlink]

Would it be possible to implement keyboard shortcuts like the ones used by GitHub or other platforms to focus the search bar? Does this solve your challenge @nlhkabu?

[nlhkabu]

@keimlink - yes, this could be a solution that satisfies everyone - thanks for the suggestion :)

We currently have an accessibility specialist doing an audit of the codebase - once that is complete, I will ask him to look into this issue from an acccessibility point of view.

I can also look into our Google analytics statistics to check what percentage of users are using search from the homepage.

[nlhkabu]

Noting this comment from @bittner on #3814:

Given I'm on the Warehouse start page
and I want to use just the keyboard to search for a package
when I press my keyboard's <Tab> key once (or max. twice)
then I should be able to type the package name
and press <Return>, or <Tab>+<Space>/<Return> alternatively
to get the search triggered.

Current Behavior

When I press <Tab>
then the browser walks through all elements of the website in their natural order
and I need to press <Tab> for 8 times before I arrive at the search input field.

Implementation Details

1. Add a tabindex="1" attribute to search input field
2. Add a tabindex="2" attribute to button tag

Related Issues

• #831
• #2824
• #3576

[SteinRobert]

I'd like to submit a PR on this.
Before doing so I'd like to discuss one thing:
By implementing this suggested change the search input is focused first by
pressing tab after the page has loaded.
Pressing tab again focuses the button.
Pressing tab one more time will focus the skip link at the top of the page ("Skip to main content"). Pressing enter here will result in focusing the search input field.
Do you think this would be a valid behavior? I think we should change the target of the skip link too, shouldn't we?

[pohmelie]

I'm fine with current behaviour, since I added pypi custom search to browser. But I'm still vote for search box is active on load.

[SteinRobert]

Mmh... Since it's the main purpose to search on that page I agree.
Just setting the focus to the search box on load seems like a legit behavior.

[nlhkabu]

@jazzbrotha could you please advise on the best approach to this from an accessibility perspective?

[JazzBrotha]

I would say no to auto focus from an accessibility perspective in this case. Auto focus on a search field should only be used if the webpage has one absolutely unambiguous point of attention, as in Google's homepage. I don't think that is the case with pypi.org. Perhaps you can say that searching packages is the most common use case, but you risk isolation users from all the content you have to offer. You also already offer a quick way to access the form by using the "skip to main content" link.

The same logic applies to register and login forms. As long at there is a truly unambiguous point of attention and no other ways of registering/logging in (i.e. social options), auto focus is fine.

[bittner]

I would say no to auto focus from an accessibility perspective in this case.

I second that. Please recall, though, that in my proposal I suggested to have the search box accessible by one (or max. two) keystrokes (<Tab> key). This would support the finding that:

searching packages is the most common use case

The site should be built for the most common use case. (_Creativity_ is asked for making the rest of the content not "isolated" by this choice.)

[JazzBrotha]

Personally, I think accessing the search box through three keystrokes is fine. This is the case if using the "skip to main content" link on pypi.org:

1. tab
2. enter
3. tab

It is not recommended using tabindex greater than 0 to change the keyboard navigation order of your elements, since you often end up confusing users that rely on assistive technology. Preferably, the DOM structure of your application should take care of the keyboard navigation order. MDN offers some good thoughts on the tabindex attribute.

[bittner]

So, what do you recommend? Educate everyone to type <Tab>+<Enter>+<Tab>?

Do you think that will help? TBH, I've never used the "Skip to main content" link before, ever. Even though (or maybe because of) I have a certification in Web accessibility. I've always avoided to press on it.

Just to help me understand: Is this a common pattern in disabled communities?

[JazzBrotha]

I agree with you that solely relying on a skip navigation link to ensure that a user will access the main features of a web application is a bit naive. A skip navigation link is a useful tool, but it is still a hack. All I meant in the context of pypi.org is that it does offer a shortcut for the user to access the search box, and that means that the user doesn't necessarily have to tab through the entire navigation panel. However, to decide if that is satisfactory is entirely up to you.

There are other ways for a screen reader users to access a search field. If the HTML is semantically marked in the correct way, using a role="search" attribute on the form element, a screen reader user can access it quickly, by using the landmark menu. Although, this is only the case for technically skilled screen reader users.

When it comes this type of accessibility matters, there are guidelines you can adhere to such as WCAG. However, they are no gurentee for how the actual user experience is. If you really want to investigate this issue further, I would suggest reaching out to people who use assistive technologies. I think you would get much clearer input on if the search box is considered accesible enough. Please let me know if you need any help reaching out.

[amcgregor]

Given I'm on the Warehouse start page
and I want to use just the keyboard to search for a package
when I press my keyboard's key once (or max. twice)
then I should be able to type the package name
and press , or +/ alternatively
to get the search triggered.

Simple solution that should satisfy everyone both for auto-focus and against auto-focus for accessibility and navigation reasons: don't auto-focus, but permit a short keyboard shortcut. For example, while viewing this ticket, type /. (A Vim-like shortcut.) I'm so used to that on GitHub I automatically attempt to use that shortcut on other sites, and am always sad when one supports neither that, nor auto-focus. As it stands, it takes 8 <Tab> strikes.

[Ivoz]

but permit a short keyboard shortcut. For example, while viewing this ticket, type /. (A Vim-like shortcut.) I'm so used to that on GitHub I automatically attempt to use that shortcut on other sites, and am always sad when one supports neither that, nor auto-focus. As it stands, it takes 8 <Tab> strikes.

This is a solution for a tiny tiny minority of users that know about vim-like keyboard shortcuts and are looking for them to work on random webpages. I guess it doesn't really harm anyone else, but neither is it a end-of-the-line solution for everyone else.

Perhaps you can say that searching packages is the most common use case, but you risk isolation users from all the content you have to offer.

I find this claim particularly weak. Since we are serving the use case of the vast majority of visits, enabling autofocus is going to risk people not visiting the links above the field, and they'll be discouraged from looking for help, donating, logging in or registering? If someone is looking for help, search being autofocused (the big banner form in the middle of the page, which one might reasonably _expect_ to be the case by default) will be the tripping point that will stop them? I'm having a hard time believing that's plausible.

If one really wants to go back to one of these less-visited links via keyboard navigation, it's also quite easy... you just press shift+tab a logical number of times. Same as pressing tab to navigate.

To me it absolutely makes sense that the huge big search bar serves as the starting point for navigation, as it is the main focal point and use case of this page.

[sersorrel]

I'm personally "meh" on this, but it seems that many other package management websites autofocus the search field, some even on non-main pages.

Going roughly by Wikipedia's list of dependency managers (since there unfortunately doesn't seem to be an equivalent list of package registries), I found 10 registries which do auto-focus the search field and 4 which do not. (Those which do: Hackage, Crates.io, CocoaPods, Packagist, CPAN, CTAN, package.elm-lang.org, plugins.gradle.org, NuGet, and RubyGems; those which do not: LuaRocks, npm, OPAM, and Quicklisp)

Hackage and CTAN also focus the search bar on package pages; the other registries I looked at do not.

[nlhkabu]

Thanks everyone for your contribution to this discussion. Thanks to the recent OTF funding for accessibility, I've had time to look into this issue in more detail. I've opened a ticket with my findings here: https://github.com/pypa/warehouse/issues/6088

TLDR: Based on the available accessibility recommendations, and the data that shows how users are using the page, we should not focus the search box.

[pradyunsg]

Thanks @nlhkabu for the update!

A minor point that you're probably already aware of but doesn't hurt to restate -- if we're going down the route of adding a keyboard shortcut for focusing on the search bar, it's kinda important IMO for the shortcut to be reasonably discoverable. :)

[amcgregor]

I'll add the note that if you visit YouTube.com whilst logged in, typing / activates the search, there, too. I'm a fan of Mousetrap as a tiny helper library for binding and unbinding shortcuts (with and without modifier keys) as needed.

Additionally, both sites (YouTube and GitHub) follow the convention of pressing ? to show a popover shortcut reference, in terms of discoverability. (Not too dissimilar to Apple's "hold command down" when using external iPad keyboards.)

:D