« Bill Buxton's "Sketching User Experiences" | Main | Directional keyboard navigation could improve PC-based browsing too »

October 10, 2007


Matt Hamilton

Setting keyboard focus to a textbox by default works well for some pages, but not others.

For example, I can remember visiting a site where I wanted to scroll down a page. I instinctively hit "space" to scroll down, and nothing happened, because my keyboard focus was in a search box. That was pretty frustrating. It stops the arrow keys and pgup/pgdn keys from working too.


Matt Lacey

There is another issue here.
Because web developers have not been setting focus by default, the keyboard didn't have any immediate impact when used. At some point the keyboard began being used for navigation. (And why not, it's not being immediately used for anything else.)

Do you use the backspace to navigate back to the previous page? I do quite a lot and it's a right pain when I've navigated through a stack to almost the page I want but can't because the cursor has become trapped by a text box. I am then forced to move to the mouse to perform the task of moving back through the history stack.

Or consider Google reader, as per your example. If the cursor was immediately set to the search box, I wouldn't be able to use all the keyboard shortcuts to navigate posts. For me at least searching in GR is something I don't do very often. Far more frequently I want to read my messages and having the Space, J, and K keys to help me do that is a great benefit and time saver.

Some times it is appropriate to set the focus of an item on a page, some times it isn't. Now, how do we deal with the backspace key?

David Eliason

I agree with Matt & Matt. I use both the backspace key and arrow keys to navigate, and it is very frustrating to navigate a site that puts the focus in a textbox on every page.

I guess the best solution would be if this could be made a per user setting. Preferably in the browser settings, and not for each site.

Kent Boogaart

It's all about probabilities, I think. If it is probably that the user will want to start typing once the page loads (google, online form) then setting focus is a good thing. If, however, it is unlikely (informational page) then setting focus is not so good. For that reason, I think you're better off leaving focus off the search text box unless it's actually a dedicated search page that the user has requested.

Damien Guard

Setting the focus can be especially annoying if navigating back/forwards through pages in the cache with the keyboard.

Surely it would be possible to make a GreaseMonkey script that found the first text box with the word search in the id or class attribute and set the focus for those people that want it?

Anything more would probably require adding to the standards.



I strongly disagree for the reasons already mentioned.

Setting (I'd even call it "stealing") focus on a web page completely destroys the user's expectations of the software he's currently using -- which is his web browser. Aside from the mentioned problems with scrolling and navigation, web browsers themselves feature search boxes that might have keyboard focus.

All one-key keyboard shortcuts simply stop working when a site steals focus.

So, I think the polite thing to do is to leave keyboard focus where it is. The sole exception to that would be sites whose single purpose it is, to enter text (like Google's homepage).

That's why I think that the Google and Microsoft examples given in the article just illustrate the right thing to do.


Reader actually does the right thing. When it loads, focus is in 'keyboard shortcut' land so that you can immediately start interacting. The default thing a user wants to do is hit space over and over to get through their feeds, not search for something.


I agree with the other commenters; setting focus can be useful for pages that have one clear purpose, like a dedicated login page. But, if there's a login form in the sidebar of a large page, you probably wouldn't want to set the focus there, because logging in is clearly a secondary feature of that page.

One thing to note when you do try to automatically set focus, though, is that having it triggered by the onload event may do more harm than good. Onload waits for all the scripts, images, etc. to load before firing, which may take a while. Meanwhile, the HTML has already rendered and the form appears ready, from the user's perspective.

I can't count the number of times I've gone to a login page, clicked the username field, started typing my username (or, worse yet, gotten as far as typing my password), and had the focus stolen and set back to the beginning of the username field.

Some sites put a little script block at the bottom of the page, right before the closing BODY tag, and set the form field focus, there. This seems to work a lot better.

Jonathan Snook

Also, especially relying on window.onload (or ) is troublesome because there's a lag between initial render time and when that even fires. How often have you come across a login page, begun typing before the page has loaded all the images, get halfway through the password field and have the page shift focus to the username field. Half the password gets entered in the wrong place.

Don't set initial focus. Let the user do it.


Couldn't you make the search field (the one with the hint text) at least be the first one in the tabindex? Actually i consider tabindex on form fields to be a better way of doing it than javascript that focuses things, because it leaves it working for people who use keyboard for navigation (backspace as a back key), while still making the website easy to use without a mouse. Also - you can add elements of your page that don't have such a high priority with tabindex, while you can only focus one single control.

James Littlefield

Amen! This was something we had to deal with very early on at PeopleSoft when we first released browser based applications. People who were known as 'heads down users' relied heavily on the keyboard for entering transactional data. Many adjustments where made to address the needs of heads down users; we even created ways individual users could personalize the behavior of the application to their preferences. I am amazed when I go to many major websites and see little or nothing has been done to accommodate keyboard centric users.


Cameron Simpson

Well, a default focus is a nice sounding idea, but ...

In practice, this makes web pages that _break_ the browser navigation controls. You go to the page, and suddenly all the keys you expect to work... stop! It is because some input form now has the focus, and I, the user, didn't give it the focus. It totally breaks the user's mental model of the browser.

What _should_ exist is an easy and common keystroke convention for "take me to the primary widget on this page"; at least common per browser. That way web pages might indicate where focus should start, where currently you advocate just taking it, and users don't have focus snatched away.


The first time I found my favorite homepage had started stealing focus so that on page load I had to click on the url bar to enter a new url, I was so angry, then I set my homepage to about:blank and lived a happier life.


Like many have said before, setting default focus is really annoying on pages with more than one screenfull of content, but for pages with only a search form, sign-up forms or comment-forms in new windows (which is a horrible practice, but if it's used I'd rather get it over with as quick as possible :-) it works like a charm, BUT should be used with caution. If the page is image-intensive or has a larger bandwith payload for other reasons, it should really be done WAY before the window.onLoad-event fires.

The reason for this is obvious; a user loads the page, starts typing in the input box (or worse yet, boxes), and suddenly the cursor either jumps to the beginning of the text, or selects all the existing text, erasing what the user has written. So it's important that the page loads fast, and the focus is delegated as early as possible.

Like so many other JavaScript-tricks, this too needs to be used in moderation, and with careful consideration. It can be a great timesaver (like Googles front-page) or a really annoying usability glitch (I tried hard to find a real example, but many forums f.e. first load a bunch of flash-ads and after that focus on the login-form making keyboard navigation a pain).


I hate the focus stealing, half the time I open my browser I have started typing a URL before my homepage has loaded, then when i am halfway through it nicks the bloody focus!

All it takes is a tab press to get to the intended focus of the web-page, leave my focus where it is!

Bud Strong

When you click LOGIN to load a page less than one screen, and with the sole purpose of signing in to a website, I ALWAYS expect the keyboard focus to go to the Username: field! I don't care about those other cases. I don't know how many times i have typed my login and had to type it again after clicking the Username box. It doesn't require onload.


works fine.

Peter R

Another problem is that as a developer, I cant find a consistent way to do it. Each browser's java-script engine seems to do focus differently and it is just not worth the effort trying to make a separate case for each browser. I cant even figure out a way to get Webkit (Chrome and Safari) to do it at all!

Until java-script engines are more unified I am leaving focus alone.

The comments to this entry are closed.