Show mercy to keyboard users (yourself included) by setting the default keyboard focus

As more of my UI work moves from client software to web sites, I'm often struck by the lack of attention most web sites spend on details of UI interactions. As a case in point, compare the degree to which a software company considers its keyboard users. Most client software products do a fair to middling job of keyboard support, but at least provide some basic facilities like keyboard accelerators for input fields, and give at least a bit of thought to the order in which a user will tab through fields. Most web sites, in comparison, apparently fail to give the keyboard user the slightest bit of thought. 

Keyboard support is often considered to be something done just for people who, for various physical reasons, can't use a mouse. That's an important community to serve, but not the only reason to think about keyboard users. Most people use a keyboard at some point in a given computer session. The vast majority of people searching with Google, sending email, IMing, twittering, and so on, every day are doing so with a keyboard. Laptop users routinely find themselves in situations where using a mouse or pointing device is cumbersome. As with many services initially intended for users with disabilities (closed captioning, sidewalk curb cuts, wheelchair ramps), keyboard support benefits the broader public. 

For all people complain about Microsoft Windows, the platform and its applications do a great deal of work in service of keyboard users. As much as I love my MacBook, I'm often frustrated by operations that have no obvious keyboard shortcut. And I was amazed to discover OS/X disables a good portion of its keyboard support by default, requiring a trip to System Preferences to fix. Still, OS/X does a fantastic job of keyboard support in comparison to almost every web site today. 

The very simplest thing a UI designer to help keyboard users is deliberately pick a good control to receive the keyboard focus by default. This is usually a trivial task—just figure out which control the user is likely to want to interact with first, and put the focus there. Often this control will be a text box. In a decent visual UI designer, setting the default keyboard focus is usually something that can be done purely through design-time UI, without resorting to code. In HTML, the default focus can usually be easily set with a tiny amount of the most rudimentary JavaScript in an onload event handler. [Example: onload="document.myform.textbox1.focus()"]

Yet virtually no web pages bother to do this. This is pretty remarkable, even more so for web forms with text input fields. On such pages, almost every user is going to have to click the mouse on the first input field so they can start typing. Every user, every day, will have to spend a second or two to do this. In a minute or so, a web developer could permanently eliminate the need for that extra click. So why don't more people bother? 

As far as I can tell, the most prominent class of web sites that consistently set the default keyboard focus is search engines: Google, Yahoo, Windows Live, etc. Most other sites don't bother, even those like Facebook that have obvious fields, like Search boxes, that could receive the focus. And even the search engines that do set the keyboard focus don't appear to reflect a consistent corporate design goal.

Google home page sets the default keyboard focus

 

Other Google properties generally don't

Google's home page sets the keyboard focus, but the main page for other Google properties like Google Reader, Google News, and YouTube don't. Windows Live does, but Microsoft's corporate home page doesn't. This last example is particularly telling. Microsoft spends untold hundreds of hours every year ensuring that its Windows products comply with regional accessibility regulations such as the wide-reaching Americans with Disabilities Act. American federal agencies generally insist that suppliers like Microsoft create products that comply with these laws if they want to do business with the agency. I have no specific knowledge, but it's reasonable to assume that the Microsoft home page doesn't fall under these regulations—maybe for the simple reason that no one's paying to use the page. 

I think the primary reason web companies ignore keyboard users boils down to expectations. Web sites don't bother to set the keyboard focus because other web sites don't, and because by now users don't expect them to. This double standard is so pervasive that, as much as I care about well-designed keyboard support, the web version of the product I work on generally doesn't set the keyboard focus either. It just never occurred to me as something to worry about, even as I devoted attention to keyboard users of the downloadable Windows client version of the same product. 

Starting to write this post provided me the impetus to finally address this UI problem in some portions of on Cozi's marketing site. Some pages like the Cozi sign-up page had forms that were completely straightforward to fix. The Cozi home page proved tougher to fix. I wanted to set the focus to the search box. Unfortunately, that control happens to use hint text, the light gray text inside a field that serves as a field label. Like most HTML implementations of hint text, the particular implementation we happen to use clears the hint text when the control receives the focus. This means setting the default keyboard focus has the unwanted side effect of removing the hint text, thereby obscuring the purpose of the very field the user might want to type in. As it turns out, we've been developing a better hint text implementation anyway that won't disappear until the user starts typing, and I'm looking forward to eventually using that control for our search box. 

In the meantime, I've at least resensitized myself to the interests of keyboard users, myself included. If your web product has a commonly used form or search box, why not take a minute to put the default keyboard focus in the right place? Setting the default keyboard focus is only a simple tiny step towards designing a good experience for keyboard users, but at least it's a start.

Comments

[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

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

[)amien

[Grin]

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.

[Michael]

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.

[spugbrap]

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.

[Ignas]

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.

Jim

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

[Anthony]

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.

[shinmai]

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

[Rob]

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.

document.getElementById("username").focus();

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.