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.

  • 3
    Why must an element have focus? What is your use case? For instance neither Google nor Amazon have anything on focus.
    – Mayo
    Commented Aug 29, 2016 at 19:23
  • That's a good question Mayo. The client (website owner) thinks that "the results" need focus after search, as they are not the first elements on the page. In fact the search form itself persists above the results. (This site is a complex integration, and there isn't a lot of control over many things, including source order of elements.) The idea the client has is that by putting focus "on the results", screen reader users would know that something has been returned.
    – GHolmes
    Commented Aug 29, 2016 at 19:59
  • 1
    Could you lightly gray out some areas and keep the search result section in white? Better yet: do you have a mock-up or screenshot we can see?
    – Mayo
    Commented Aug 29, 2016 at 21:30
  • @Mayo, for practical purposes, google.com has focus on the search input field, even though you can't see the cursor. The reason you can't see it is that their behaviour is JacaScript based with additional features; e.g. hitting arrow down will select the first result. However this granular behaviour would be rather expensive for a regular client.
    – bjornte
    Commented Aug 30, 2016 at 8:06
  • Do you have any further information on how you are implementing your search? It would also be useful to see the proposed functionality and layout of the page. Some points to consider include: If you choose to skip to the search results you may also skip over filters or sort elements. For users of assistive technologies you may need some way of informing them that the page has updated and search results have been returned? This might fall into the realm of WAI-ARIA?
    – Sheff
    Commented Aug 30, 2016 at 9:33

5 Answers 5


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.

  • I agree. I'm not sure what the final outcome is going to be - I don't make the final decision - but this reasoning is compelling.
    – GHolmes
    Commented Sep 1, 2016 at 15:45

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.


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.

  • Agreed, a wireframe would be great.
    – bjornte
    Commented Aug 30, 2016 at 8:17

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


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.