I've been meaning to implement the pattern of an "instant search" on a Desktop site, which would work by simply starting to type and have the input focused on a search form.

The only example I have right now would be InvisionApp, where you can search for projects or screens immediately.

Other than that I have only found this mention of the pattern on here (or anywhere for that matter):

Starting Instant Search as you type

But this question only deals with a specific implementation and not the general idea of the pattern.

My question: is there a conventional name for this pattern? And are there any possible drawbacks to this? Accessibility/Usability issues?

  • Do you mean 'incremental search'? en.wikipedia.org/wiki/Incremental_search For example, it's what a modern browser (Chrome, Firefox) does when you start typing directly into the address bar. Mar 30, 2018 at 15:41
  • No, slugolicious below described it as well. I'm talking about simply typing, no matter whether you've focused on an input field or not. And upon the first keystroke have a search or filter input field focused. Apr 3, 2018 at 14:23

2 Answers 2


You might be thinking of "autocomplete". You can find autocomplete information in the combo box design pattern in the WAI-ARIA Authoring Practices 1.1. The design pattern contains information for making the concept accessible.

However, what you describe is a little different from autocomplete, though. It sounds like you want the user to be able to start typing no matter where they are on the page and have the focus automatically move to the search field with that first letter entered. I would not recommend that. Having the focus move without the user's consent can be disorienting. You can provide a shortcut key to the search field if you want (such as the accesskey property), but that too can have issues (such as the discoverability of the access key).

Screen reader users use single key shortcuts to navigate to certain web elements. For example, 'B' will take you to the next button, 'T' will take you to a table, 'L' will take you to a list, 'H' will take you to a header, etc. If you want a screen reader user to benefit from your "instant search", they'd either have to:

  1. switch out of navigation mode so that keyboard input goes to your application instead of the screen reader, OR
  2. temporarily send keystrokes to the application instead of the screen reader, OR
  3. be forced into "application mode" by your website, which automatically turns off the screen reader navigation mode.

None of these are very pleasant, and number 3 is the least desirable. Having a dedicated search field is usually the best way to go and allow the user to put the focus there themselves. (It you use role='search' in your html, that will allow a screen reader user to quickly move to that area by using landmark navigation.)

  • Thank you for your input. Screen readers was exactly what I was concerned about most – do you have any more information how this works exactly? I'll be focusing my search on this as well. Apr 3, 2018 at 14:25
  • What is the "this" you're asking about ("how this works"). I'm very familiar with using screen readers so if you have questions about that, perhaps you should start another post. Just make sure you include the "accessibility" tag on your question so I'll see it. Alternatively, you could contact me directly at my stack exchange id at yahoo, but if your question is of interest to others, others might want to see the answer. Apr 4, 2018 at 22:11

You're describing a specific variant of the incremental search pattern where typing from anywhere launches the search, as long as a text field isn't focused. The GNOME HIG calls this "type to search". It's used extensively on the GNOME desktop.

Potential drawbacks:

  • Losing track of context. If the UI changes significantly on search, the user might lose track of where they are.
  • Unexpected behavior. When the feature is hidden from sight, one might be surprised to see results appear when accidentally hitting a key. And if they lose track of where they are, it's not going to be a pleasant surprise.
  • Loss of data. If implemented poorly, triggering a search from a screen with a certain state could result in an unexpected loss of data.
  • Slowness. Not only might retrieving and rendering results be slow, but getting back to the original screen might take a while too. The added wait can be frustrating if the search was triggered by accident.

All of these depend on the implementation, of course.

I haven't researched the accessibility issues for this, but clearly accessibility has to be kept in mind. Clearly, the feature can't just be ported straight to screen readers, so the screen reader UI has to be designed separately.

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.