Instant typing search pattern

Question

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?

Answer 1

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.)

Answer 2

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.