Initial focus to a text field – good or bad?

I think that in (almost) every project I work in, when a web page contains one or more form elements, the most common question is: should we set initial focus to the first element in the form when the page has loaded? Heated debates follow, where people argue very convincingly for their view on it.

However, to me it isn’t an easy black or white-question.

My take is that it is all about context. In some web sites, it is expected and it will heighten the experience for the end user. Helping them saving time and become more efficient by easing the load from them of having to tab to, or click, in the field is a good cause. Take Google, for example: 99% or more are there to perform a search, and not to click on any of the links. Verdict: initial focus is justified (and is used).

Then you have web sites that are filled to the brim with content and navigation options, but additionally they offer some kind of search functionality as an alternate way to find what you’re looking for. Here, initial focus wouldn’t be helping the user since, most likely, not as many will start with the actual search option. Examples: Amazon and Technorati. Verdict: no thanks, no initial focus (and it isn’t used).

Why is initial focus ever bad?

For a couple of reasons, actually. Let me name the two most important ones:

  • If the user is accustomed to using any keyboard navigation their web browser or operating system offers, an initial focus might interfere with that; the result will just be some characters in a text field instead.
  • Accessibility. Let’s say that you can’t use your mouse and have to rely on the keyboard to navigate around in a web page (or if you just want to only use the keyboard). If you have a web page with a lot of content, navigation etc, you expect tabbing to begin from where the web page starts.

What’s your take? Initial focus or not?

29 Comments

  • Jens says:

    As you say, if it quite clear that the user will use the form put focus on the field, otherwise do not.

  • Kanashii says:

    I think things like Google are the exception and if the form field is the top of the document it might be OK but I would imagine it'd be pretty crappy for a screen reader user to be dropped in the middle of a page and not knowing where in the page they are and what they missed on the way down.

  • Chris says:

    This question is interesting. It's truly an accessibility-problem if you focus one field. There are other issues with setting focus.

    But imho it's essential to set a reasonable tab-order or access-key (which i dislike for other reasons), because it's a pain in the ass if you have to tab through a long list of navigation-links before reaching the form.

  • Rik Lomas says:

    Obviously it depends on the site. If your site is like Google where 99% of users go straight for the text field to search, then it makes sense to focus on the field. However, for most sites, where there are plenty of routes for the user to choose, then forcing focus on the input is not the best thing to do. So yes, it's usually a bad thing. Unless you're Google.

  • In most cases no, but occasionally it can be very useful.

  • Martin says:

    I reckon it is a good thing for a login form with the username receiving the initial focus. Why else would one do something else other than entering your username which is the first field?

  • Another point to note is that although Google's home page sets focus to the input field (which I agree is a Good Thing), the results pages don't. I've seen other sites where they also set the focus to the input box on the search results page; the result is that you can't scroll down the page looking at the results until you've removed focus from the field. Highly annoying…

  • As the others have said, don't do it on pages that have too many fields. It's good for a page that has one task to perform and has limited inputs. A search box or a login form would be about it. However, I hate scripts that use window.onload. I've often been midway through typing a password and the focus switches to the username box. Gah. Use DOMContentLoaded or equivalent.

  • Lachlan Hunt says:

    Another reason it's bad is because of Find-as-you-type in Firefox. I'll often go to a website and just start typing to find what I'm looking for on the page. It's incredibly annoying on some sites where I find I'm suddenly typing in a text box instead.

    A good example of where this exceptionally bad is MSN. As soon as you start typing, focus is immediately given to the text box, even if you explicitly take focus out of it!

  • Tim Hofman says:

    I only use it on pages with forms to log in or retrieve passwords etc. Pages where you can be almost a 100% certain that the user is on the page for that action.

    On other pages it's a no go for me. It can be/is quite irritating when you have to navigate all the way back with your keyboard to something like the main navigation, just because of a initial focus on a field.

  • Robert Nyman says:

    Thanks, all! Good to see that you share my opinions on it.

    Chris,

    A well-structured web page where the tab order is what you expect, paried with any eventual skip links to help the user out.

    Martin,

    If the web page only consists of a login, absolutely. But if you have one with lots of elements and sections, I wouldn't like it.

    Jonathan,

    Couldn't agree more. That's what the intention of my ELO object is; to implement support in all the major web browsers for checking when the actual DOM itself has finished loading.

    Lachlan,

    Oh, absolutely. Find-as-you-type is a suberb feature that every web browsers should support, and such annoyances is just terrible.

  • Jens Meiert says:

    Approach 1: Test with users.

    Approach 2: Use your experience (and/or common sense).

    πŸ™‚

  • Usually bad. I understand why google does it but I still hate it. It's a usability problem. I just myself hate focus being taken from me.

    You know, it's just like you said… it works for google, so they do it, but it doesn't work for Amazon, so they don't. So then you just don't know what to expect when you go to a website. Do you suddenly have focus in a form field or not?

    Google I'll forgive, because they are the titans, and they are almost a seperate web entity unto themselves. But others… give me back my damn focus. Punks.

  • Another problem with giving focus to an input field is it breaks using the Backspace browser keyboard shortcut. Do a Google search, click the Next link, hit the BS key expecting to go back to the previous results and what happens? I'm not sure if Safari uses the same shortcut, but under Firefox this behavior is really annoying since it is the primary method I use to nav back.

  • Tommy Olsson says:

    If the main purpose of the page is to fill in a form, then initial focus may be justified. Otherwise it is a bad thing.

    I'm an Opera user who loves the spatial navigation. If there's a form but no initial focus, all I have to do is hit the Tab key to go to the first form field. If there is initial focus to, e.g., a search form, and I don't want to search, I may have to 'unfocus' the search field before I can use spatial navigation.

  • Robert Nyman says:

    Thanks for sharing, guys. And that's right, Daniel. Be tough on them! πŸ™‚

  • Jules says:

    What about a situation whereby there was an error on the form and you want to direct the user to the field in error?

    Robert: Weird thing is happening – Jonathan Snook's gravatar is appearing beside your comments and nothing beside yours.

  • Robert Nyman says:

    Jules,

    Interesting question. Personally, I hate focus set to form fields directly as you leave them if you didn't fill them out correctly. But if it's when submitting a form, it might help, although I prefer showing where the error occurred in some other manner than setting focus to the field itself.

    Also, I think the gravatar issue you mention was some temporarily loading problem…

  • Rumoroso says:

    If the user uses screen reader (x. Jaws) and the initial focus is in the text field, he will not read the previous content. In many cases (maybe, in all cases) this initial content includes necessary information (site headings, information about the form, links, required fields, etc) and if the form includes required fields, when there are errors , they appear appears before the fields.

  • Robert Nyman says:

    Rumoroso,

    Interesting. Thanks for the input.

  • Rudy Johnson says:

    Good

    – for a website like Google which only has one main purpose > searching using that infamous single input text field

    – for a contact us or search page with only form fields on it > the website owner know why a visitor has hit the specific page so help the user out with a small time saver

    not so Good

    – content rich pages

    – pages where the focus is not the intended *focus*

    It all comes down to case by case basis.

  • Robert Nyman says:

    Rudy,

    Thanks for sharing. Also, I removed the link in your comment since your name is also linked to your web site; no need for double linkage! πŸ™‚

  • Andrew says:

    Yes! It's bad. I'm every so often use laptop and keyboard navigation. Try scroll down with arrow keys on page with big content and focused text field.

    It is best use tab key and go to text field or link or all that is wanted. Use tabindex attribute for text field instead focus.

  • Robert Nyman says:

    Andrew,

    Good points.

  • Rudy Johnson says:

    ooops, thx Robert N … I did not even notice that, my bad!

    Have a good day!

  • Robert Nyman says:

    Rudy,

    No problem at all! And a good day to you too!

  • BB says:

    I would recommend not putting an auto-focus on login pages. I've lost count of how many times I've keyed in my username and am halfway through typing in my password when the page finally finishes loading and sets the focus to the username field. The result? Half my password in the username field. In short, a great way to infuriate your readers!

  • […] Initial Focus to a Text Field – Good or Bad? – Robert Nyman […]

Leave a Reply to Robert Nyman Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.