What element should have the focus after a search?

Question

A website has its own search (there are reasons for this; no, a Google site search will not do).

So, after a search is executed, for accessibility what element should have the focus? The number of search results? The link to the first result? Something else?

I'm not finding explicit guidance on this.

---

Update based on feedback and questions:

I apologize for not being able to link to the site, or a reasonable mockup or wireframe of it. I am not allowed to.
It is a public site (with some small private sections). It is essentially a huge archive of documents and other media, with a lot of odd metadata, and various retrieval methods that don't make it a good fit for using Google.

It is government-related, and pressure for accessibility comes from that direction (in addition to the obvious goodness of accessibility in general).

A user might arrive at the page via a pre-defined search (with search terms in the querystring), or they might do the search themselves from scratch. The search form, simple at first glance but with the ability to add search fields and search many aspects of content and metadata, always remains at the top. They might well modify the search after seeing the results.

From what I can tell, they have a team testing this site having an actual blind user, and also one or more people rather ... er, mechanically applying guidelines. I am not told which items of feedback came from which tester, though I might guess.

Answer 1

My piece of advice considering screen readers would be to set their focus on the information / H2 that tells the user how many results the search resulted in.

The reason for this is that the user need some kind of confirmation that his/her search actually was completed and that the search actually resulted in "no results" or "34 results" or whatever the H2 might consist of.

When the user then wants to edit the search phrase, all major screen readers has a built function that changes the focus from whatever the user might be looking at to the first input field, normally the search field.

Answer 2

Focus after a search should remain in the search input field.

When looking for "explicit guidance" on how to create best of breed search UX, google.com is the gold standard. Paraphrasing my own answer on another search-related question:

Consider google.com, undisputedly the market leader of online search. (...) Their design patterns are employed across all the vendors, including Yahoo, Bing and more. Not only has these patterns made practical sense for the vast majority of installations. They also set user expectations.

Now your question isn't as clear cut as the one referenced. When I test various vendors on your topic, I find variation:

• Focus remains in the search input field after a search:
  • google.com
  • yahoo.com
• Focus seems undefined after a search:
  • bing.com
  • duckduckgo.com
  • amazon.com
    ^{(moreover, and probably since this isn't a pure search service,
    focus wasn't in the search input field in the first place)}

Google and Yahoo are the big players here. I would most definetely follow their lead.

I have worked with search UX for a decade, and the universal feedback from users is that they love Google. If they struggle with a task, they very often ask me "why can't it be more like Google?". This happens to such an extent that I usually advice (again paraphrasing):

From a general methodology perspective, if you deviate from Google's established design pattern, you must have a thorough, researched rationale, or you impose a risk on your client.

To be clear, I have never worked for or received money from Google. Quite the opposite, I have worked for several competitors, witnessing how they have bled users and money from not following this advice. Obviously, for some types of competitors, differentiation is a key success factor, but I assume this not is a need for your site.

^{P.S. I'm answering based on the context provided in the original question. Based on the comments there may be special needs, but there's not enough additional information to act on it, so therefore sticking with the general methodology. I agree with Andrew Martin that observing users is a great idea, but unless you have very special needs, Google has done that for you already.}

^{P.P.S. Is it a publicly available site with mostly unstructured data? If yes, have you considered Google CSE? It's incredibly powerful for its price, usually beating the crap out of CMS-internal search features due to e.g. its language support (including synonyms, lemmatization, CJK etc.). Again, I'm not affiliated.}

Answer 3

Consider what your user will do with the search results. If this is a typical web content search where the user will hopefully identify a useful page and select it to see the content, there may be no need to focus anywhere - OR you could focus on the keyword field, in case the user does not see useful results and wants to modify the search. I'm not sure that this addresses your screen reader requirement though.

If the user is going to manipulate the results somehow, perhaps by selecting multiple results for deletion, making items favourites or adding a comment to an item, that is a different use case.

If the primary requirement is that "screen reader users would know that something has been returned" and you are trying to draw attention to a different part of the screen - perhaps it make sense to focus on the number of results returned.

It would be helpful to see a wireframe / have a better idea of the context.

Answer 4

On mobile the virtual keyboard would occupy half(?) of the screen area, if the search field is focused after the search.

Answer 5

If this is about accessibility then you probably want to shift focus to the first answer. This will give the user the chance to quickly tab through the list to get to the result they want.

However, behaviour at this stage during the search process may be particular to your users. They may regularly search again, click the first link, move through the pages of results...

I would advise either observing live users or examining server logs of page impressions to find regular patterns of behaviour and tailoring your solution toward that.