I <3 Steve McConnell*
Coding Horror
programming and human factors
by Jeff Atwood

February 10, 2008

Where the Heck is My Focus?

The web is quite mouse-centric. Ever tried navigating a typical website without your mouse? I'm not saying it can't be done-- if you're sufficiently motivated, you can indeed navigate the web using nothing but your keyboard-- but it's painful.

There's nothing wrong with the point-and-click navigation model of the mouse, although it can degenerate into mystery meat navigation if you're not careful. I don't expect web designers to create keyboard-centric websites; the mouse is a natural and intuitive enough way to navigate web sites. But so is the keyboard, in certain circumstances. What frustrates me is when web developers fail to pay attention to the most rudimentary of keyboard support in their designs.

Let's pick on eBay. Here's the eBay signin form.

eBay sign in form in Internet Explorer 7

This form is a perfect example of keyboard navigation trumping mouse navigation. Done right, it reduces user interface friction to a minimum:

  1. Type your user name
  2. Press Tab to advance to the next field
  3. Type your password
  4. Press Enter

Of course, that assumes the user knows how to use the keyboard. In my experience, this is not a safe assumption. I've seen many users log in using the excruciatingly slow mouse way, and it's not pretty. At the risk of creating a legion of back seat drivers, I suggest that when you see coworkers users using the mouse to log in, you should gently-- gently-- let them know that they might be able to save some time by sticking with the keyboard for these little online forms. I'm not saying you should go commando, but a tiny bit of keyboard expertise will serve you in good stead.

This is an incredibly simple little login form. And yet there are at least three ways web developers can screw this form up for keyboard use. That's why I added the caveat done right, above. It almost never is, and keyboard users always seem to get the shaft. To make this HTML form work properly with keyboard input, the eBay developers have to:

  1. Set the focus to the first field so I can start typing in my user ID.
  2. Structure the HTML form fields so that when I press the Tab key, it advances through them in a logical order.
  3. Ensure that the HTML form submits when I press the Enter key.

You might expect the tab order on the eBay login form to proceed in the same order you read the form (in Western cultures, anyway):

eBay sign in form, expected tab order

If so, you would be wrong. I guess two out of three ain't bad. The tab order, for some unknown reason, goes directly from Password to the Sign In button, completely skipping over the "remember me" checkbox directly under it. This is a mild omission, to be sure. I've seen far worse, web forms with tab orders that resembled a Rubik's cube. But tab order on a login form is so fundamental -- when web developers screw up basic tab ordering on a form with four fields, that's veering dangerously close to "I don't give a damn about my craft" territory.

All the developers you know remember to test their web forms using the keyboard. Right?

But even if developers do remember to test for basic keyboard behavior, there's a deeper problem here. Keyboard navigation relies heavily on the focus. In order to move from one area to the next, you have to be able to reliably know where you are. Unfortunately, web browsers make it needlessly difficult to tell where the focus is. Can you tell which field has the focus in Internet Explorer 7?

eBay sign in form, IE7, closeup

I think it's fair to call that incredibly subtle. Let's see how Firefox 2 does.

eBay sign in form, Firefox 2, closeup

Wow. Good luck with that. Now how about the same form in Safari 3?

eBay sign in form, Safari 3, closeup

No wonder users rely on the mouse so much. Most browsers do an embarassingly bad job of making the focus obvious, so users feel compelled to click on fields to orient themselves.

The focus behavior is just as bad when the focus moves to the sign in button. It's technically an image masquerading as a button, but this is still a fairly common technique; it should be handled well. Is it?

focus-button-ie7 focus-button-firefox2 focus-button-safari3
Internet Explorer 7 Firefox 2 Safari 3

Of the three, only Safari really gets focus right in my estimation. Here's hoping the next versions of Firefox and Internet Explorer copy this more obvious focus indicator. If users can orient themselves using a clear, unambiguous focus, they're a lot more likely to warm up to a little time-saving keyboard navigation.

Posted by Jeff Atwood    View blog reactions
« The Years of Experience Myth
The Dramatic Password Reveal »
Comments

Totally agree - what's worse is seeing users press enter to go the the next field...it happens.

Mike on February 11, 2008 1:59 AM

But isn't there a blinking cursor in the text field if it has focus? (Not that I haven't seen this inexplicably violated...)

Atario on February 11, 2008 2:07 AM

> But isn't there a blinking cursor in the text field if it has focus?

Yes, a slim 1 pixel flashing line. And even then, only if the focus is on a text field that allows input.

Jeff Atwood on February 11, 2008 2:11 AM

I'm not convinced that there should be check boxes or links between the login fields and the submit button...

Calvin on February 11, 2008 2:16 AM

Facebook is particularly bad. If you check the box to remember your password, it comes up with a popup that messes with your tab order.

Mikel Ward on February 11, 2008 2:18 AM

Interesting, I listed this as one of a few advantages Safari has over Firefox. I was told (amongst other things), that if I really couldn't see the highlighted textfield that I could "always go and edit userChrome.css" to resolve the problem.
http://tinyurl.com/2f63n9

Des Traynor on February 11, 2008 2:21 AM

If you write accounting software, users insist it can be driven entirely from the keyboard. This is because book keepers spend all day at the keyboard and don't want RSI and do want to be able to work as quickly and efficiently as possible.

The solution goes a little further than simply having a visible cursor althought I certainly agree knowing which field is highlighted is helpful.

Web Accessibility Initiative (http://www.w3.org/WAI/) is probably a good place to start if you want to think a little more about accesibility and ease of use.

Robin Fisk on February 11, 2008 2:25 AM

Firefox 3 beta does this (puts a blue border around the active field) already.

Mikel Ward on February 11, 2008 2:27 AM

well,it seems web designers forgot about the keyboard when it comes to navigation which is wrong because almost all the forms on the web can be filled faster using the keyboard eg.creating a new email account.Even though Safari obviously wins when it comes to focus highlighting I'm a bit disappointed with the color used,it should be a bright color like orange or something yellowish.Just as shown in the ebay form there are a lot of buttons which are blue thus using the color blue to highlight them is like no highlighting at all.If there is a way to change the color then i rest my case,also the color red does not qualify since it is exclusively used to display errors.

gogole on February 11, 2008 2:27 AM

Hey Now Jeff
My focus is getting so bad these days I'm needing glasses.
Davo
Coding Horror Fan

David Dawkins on February 11, 2008 2:28 AM

As always, for Firefox there's a handy add-on that rectifies this omission. Two even:

https://addons.mozilla.org/en-US/firefox/addon/1310
https://addons.mozilla.org/en-US/firefox/addon/2690

Still, it would be nice to have it implemented properly in the FF core.

Jeroen on February 11, 2008 2:31 AM

I've found another related issue, in my bank. When logging in, they expect n digits for the passcode, and so, when you have typed n digits, they "helpfully" hijack your pointer into the next textbox.

nomendil on February 11, 2008 2:32 AM

I sit in IRC channels on freenode where people ask webdev questions. A particularly common one is "How do I remove that dotted line from links on my page".

Very occasionally, people are actually interested in 'rebranding' the focus indicator to fit their site design, which poses an interesting question towards user consistancy. Personally I'm happy to replace the dodgy dotted line with something a bit nicer looking, provided it's clear what the intention is

Gareth on February 11, 2008 2:34 AM

mmm, properly drawn fonts, mmm. Sorry, didn't mean to drool over Safari. Shame it doesn't have all Opera's other UI sugar (fast-forward, paste and go, search from the address bar, scale page etc, link address in tooltip).

Yeah, I agree with Mike that the enter key trap is a pretty nasty one for new users. Used to get me all the time. That either needs javascript or a change in the way browsers handle forms so that the user can at least choose to use enter to go to the next field. And maybe space to send the form once the form's submit button is in focus.

Opera doesn't highlight form fields, but it does highlight buttons nicely.

John Ferguson on February 11, 2008 2:39 AM

I'm not certain that this is an omission by Firefox. It could even be seen as a problem with Safari.

In FF, you can use the :focus psuedoclass to determine what happens when the field has focus. That could be a border, a different background colour, or an enormous blue highlight. In other words, it is up to the page designer to determine what happens on focus.

In Safari, it could be that the effect of anything on :focus is wiped out by the blue glow, which I would consider to be incorrect. I'm not sure on this point though as I don't have Safari to hand.

Colin Ramsay on February 11, 2008 2:40 AM

Apparently, not having the "Remember Me" in the tab-order is a security issue instead of a usability one; it prevents people accidentally toggling the "Remember Me" when using a public terminal.

In other words, this was a deliberate decision by eBay, not a simple case of carelessness.

However, you're right - many sites don't give a crap about tab order.

Robert on February 11, 2008 2:48 AM

Another annoying "feature" is stealing focus when the user is faster than the script being loaded (see e.g. Google search). Shameless plug: I've chucked together bits and pieces to get a script which will avoid this in major browsers - See the link below.

Victor on February 11, 2008 2:52 AM

You need this: http://userstyles.org/styles/305

Nikolai on February 11, 2008 3:01 AM

Keyboard access. The only browser that *gets* it. http://help.opera.com/Windows/9.20/en/keyboard.html

JK on February 11, 2008 3:03 AM

Hitting tab the correct number of time can be a trial when there are a large number of elements on a page that can have focus. This mouseless browsing extension in firefox looks useful:

http://www.mouseless.de/index.php?/content/view/17/30/

Oli on February 11, 2008 3:21 AM

I'd actually expect the tab order focus to be:

1- User ID
2- "I forgot my user ID"
3- Password
4- "I forgot my password"
5- Keep me signed in
6- Enter.

I'd instinctively double-tab from the user ID field to the password field, but end up on the Enter button.

Damian on February 11, 2008 3:24 AM

I agree with Robert. If when you want to go to a website sharp'ish and want the least questions possible (especially about the next time you login), then its just username, pwd, login... thats it, thats all I want to enter. Show me the damb site already. So impatient!

Matt on February 11, 2008 3:38 AM

Yes, this totally annoys me. Wordpress is the worst for this I feel, I think they do it for bots, but a bot would just use a getObjectByID I'd assume.

Meh

Sarkie on February 11, 2008 3:47 AM

Hi guys,
you should try "vimperator" (@ vimperator.mozdev.org) its an extension for firefox to let you use the keyboard instead of the mouse. When you press [f], labels pop up for all links, and when you type the name of the label its like clicking on the link. After getting used to, it works like a charm, and no more mouse!

Hugo on February 11, 2008 3:50 AM

It's a breeze to navigate with keyboard in Opera using Shift+arrows or Q/A to go between links and input elements.

igorsk on February 11, 2008 4:02 AM

What Colin said. Firefox and IE7 aren't showing what the website creator didn't ask to show. This website needs to focus more on :focus styling.

Carl on February 11, 2008 4:24 AM

I've got one web app I sign in to, where the text box gains the focus, then loses it _as you're typing_ when it loads some script, then loses it _again_. It's infuriating.

Lloyd on February 11, 2008 4:43 AM

This is actually something that every web developer should know how to do properly. Although what properly actually is is a matter of debate. Here is my tuppenceworth.
As Damien says the correct tab order (as it stands) is
username
forgot
password
forgot
remember me
enter.
But it should be:
username
password -- at this point enter should submit the form
enter
remember me
forgot
And it should look like that. The reason being that the first two fields are going to be used 99% of the time so they should come first and as Robert points out a user should be given more opportunities than necessary to check remember me.
But there are some subtleties that can really improve things for the keyboard user. The :focus pseudo class should be used to provide visual feedback (and the :active which for some reason IE uses when a field gets focus). This is something that should be consistently applied to every link.
You can also do this using javascript. And with javascript you should hijack the enter key until the last field or the enter button has focus. How many times have you pressed enter to move to the next field and accidentally submitted a form?
Finally in ebay's case labels should be used so that the mouse user has a large clickable area.

Neil Anderson on February 11, 2008 5:05 AM

There is one really annoying flaw with the Safari focus model - if you're typing in a form and click the submit button, focus immediately pops back to the text field. The number of times I've double submitted because I thought I didn't click the button....

Andrew Herron on February 11, 2008 5:28 AM

To Colin + Carl: Although 'good' focus styling can be achieved via CSS, there should still be a sensible default style provided by the user agent, to be overriden. Much the same as fieldsets, buttons, drop-down menus should all be as usable as possible by default, whilst retaining a sensible level of 'neutrality'.

Bobby Jack on February 11, 2008 5:51 AM

Firefox users, I strongly recommended a script for the Stylish extension called "Bright Focus (for buttons, links, and textboxes)"
http://userstyles.org/styles/305

it replicates the focus behavior of Safari (at least I think it does since I've never used Safari myself)

Dejan on February 11, 2008 5:52 AM

I don't think this should be blamed on the browser. As others have said, using the :focus pseudoclass to define the exact look of an element that has focus is the optimum solution as it allows developers to notify the user while keeping the look and feel of the design inline with the rest of the site.

Phil Nash on February 11, 2008 5:52 AM

I'll have to respectfully disagree with your first point (that it should stick the focus on the username box). Sometimes, perhaps most of the time, that's good or neutral, but when it's not it's really, really annoying.

Ian Toltz on February 11, 2008 5:58 AM

Too many "experienced" web page developers out there, huh?

PaulG. on February 11, 2008 6:01 AM

I'd like to chime in with the other users who pointed out how great Konqueror is in this respect. First there is the access keys, which you can view by pressing Control and then follow by pressing a letter or a digit (not that this doesn't clash with other short-cuts because the Control key is released before you press a letter). It should be noted that this works better than regular access keys defined in the HTML source, because the shortcuts keys are (1) visible and (2) only assigned to items visible on the screen. That means that even if you have a page with hundreds of links, as long as only a few (less than 36) are visible at a time, you can activate all of them with just the keyboard.

Second, Konqueror renders controls in the current KDE widget style, which means that elements which have focus are clearly visible. So when it comes to keyboard navigation, Konqueror definitely beats the Internet Explorer and Firefox.

With regard to tab order: this is one of my biggest GUI annoyances and in my experience the problem is present in regular applications as well as on the web. Apparently many developers use the mouse almost exclusively and don't even test their dialogs with the keyboard, resulting in completely random tab ordering. I wish GUI tools like Visual Studio and Qt Designer would do a better job of automatically ordering controls in a sensible way, instead of defaulting to the order of creation. Of course it should be possible to override the order, but it would be nice to have a more sensible default.

Maks Verver on February 11, 2008 6:18 AM

Firefox 2 is particularly bad on the Mac: tab does not allow you to move to a drop down list field. This drives me crazy.

Akira on February 11, 2008 6:24 AM

Anyone working on software for the US government is required to make their application keyboard only accessible as part of Section 508 Compliance. And to the rest of us not required to meet Section 508 yet, a recent court ruling found an online bank liable for handicapped customers inability to use their web site. Keyboard Nav is only the tip of the iceberg for making applications accessible to disabled users.

Maybe you could write a blog entry about section 508 compliance. www.section508.gov

Dan on February 11, 2008 6:29 AM

As someone who occasionally gets stuck doing web development work, sometimes there just aren't good solutions for this sort of thing. I mean, eBay's login page, no problem. But something in ASP.NET with a complex master page layout? You have to plan well to make it work right. Maybe you say that the top of your master page gets tab indices 1-1000, a content page gets 1001-9000, and the bottom of the master page gets 9001 and up, but you're depending on everyone following convention, which can be problematic when you take into account the poor quality of most corporate development teams (well, that I've worked with, anyway). Rather than looking at the problem in terms of which browser does it best, I'm usually frustrated by how poor the underlying language is for solving the issues.

Ralph on February 11, 2008 6:35 AM

Did anyone try to tab down on this page to enter a comment?
And also what happened after you tabbed past the 'Post' button...

Ec on February 11, 2008 6:44 AM

As always you do not even mention Opera in your articles. I know that bloging isn't the same as journalism but totally neglecting Opera in this case just because you do not like it is very sad for such good writer that you are.

Well, the feature you forgot to mention here (but some commenters did mention, but forgot to name it) is called spatial navigation and is present in firefox as an extension and out-of-box in Opera. When I'm in my laptop and do not have a mouse I always use this feature instead of the trackpad.

Taken from: http://www.opera.com/support/tutorials/nomouse/

"Spatial navigation allows you to move in any direction to the next link or form input. To use spatial navigation, press Shift+Down, Shift+Up, Shift+Left, and Shift+Right, and Opera will select the most appropriate item in that direction."

By the way, this is how the focus is shown in opera:
http://img216.imageshack.us/img216/2910/61800975qe7.gif
As good as Safari, I like black more because of the better contrast against the majority withe backgrounds.

Next time try to do your homework about opera too...

Hoffmann on February 11, 2008 6:51 AM

I have to agree that showing the focus is a problem in many web pages I visit. I've gotten used to hitting the tab key and typing. I really hated three keyin fields for a phone number. At least until they started changing focus automatically to the next field. But really now, why do they need three fields? If they can parse the keyin to move to the next field, they can parse the field later.

Another peeve of mine is hijacking the middle mouse button. More and more I find that I have to mouse over to the edge of the page, click the middle button and ease the mouse down to begin the slow scroll. Then I can sit back and read several pages without further input.

- les

Les on February 11, 2008 6:56 AM

I agree with Viktor and Ian. There are a lot of web sites that put focus on username, but it happens after the form has loaded... and after I've started typing, and 9 times out of ten, my "obscured" password ends up getting typed right there in the username field, for all those people standing over my shoulder to see. I personally dislike just about any occurrence of a program stealing focus. I think if it's going to be used on a page with nothing but a login form, then it should be sure the browser is in focus and not pull you in, and it should check to see if anything is entered in the username field before trying to focus. Try to remember the multitaskers!

Jason Beck on February 11, 2008 6:58 AM

The problem I have seen in the past on some web forms is the tab from the login field would give focus to the link line of "I forgot my user id" (to use the example image from above) instead of going to the password field.

GeneralSQL on February 11, 2008 7:01 AM

And how about when there is just no submit button!
Like on Facebook. When I am using it from my phone, I can easily fill in the fields - but there is just no "enter" to make the form submit. That is so frustrating.

Evgeny on February 11, 2008 7:20 AM

And also - STEALING FOCUS!
For some reason lately GMail is being stealing focus in Safari. I am opening several tabs, type urls quickly and wait for them to load. If one of these tabs is GMail then even though I intend to type in the url of tab #3, GMail steals the focus and changes the tab I am at in Safari.

That really can make one furious.

Evgeny on February 11, 2008 7:21 AM

Ec:
Tab worked great on this comment form. If you tab past post, it went to the codinghorror picture at the top of the site...

I started out writing mainly desktop apps, so Tab order was very important when we switched from DOS to windows programs, but there were some old hold outs from the DOS days that wanted our app to use enter to move between fields.

Jeff, great blog. Sicne I only recently converted to web apps (new job) I've gained a lot of "walking around knowledge" from this blog. keep it up!

Wayne

Wayne on February 11, 2008 7:21 AM


A nit and an addition.

The nit:

eBay is between a rock and a hard place. Yes, you and I looking at that form would expect the checkbox to be highlighted after the Submit button, but that would cause problems for people who expect "login" forms to always be <login><tab><password><tab><space> (<space> being the activator instead of <enter> because, you guessed it, many web forms don't get the damned default button paradigm right so the only way to know what the heck button is being pressed is to highlight it and press it yourself!)

The second option they have is keeping the ingrained keyboard pattern in place, but move the visual cue (the location of the checkbox) to AFTER the submit button. However, this too is bad form, as it then visually indicates that the checkbox is not being submitted.

The solution, IHMO, ties in with the suggestion below.


Open up any Windows or OS X dialog box with multiple buttons and text fields, and what do you see? You see the focus ring around the current control, of course, but you *also* see an indicator around the default "enter" button. THIS IS CRITICAL. Why has the web forgotten this?

If only we knew for a certainty that "Enter" was going to submit the "Submit" button, not the "Reset form and lock my account until I call a support representative" button, we could confidently follow your <username><tab><passwd><enter> advice instead of trying to tab to the right button and hitting <space> instead!

But, we don't know this for a certainty, and I suspect anyone who's lived through the past decade with a keyboard control tendency has been burned by "enter" not submitting the right button on the page.

Tom Dibble on February 11, 2008 7:28 AM


(Sorry for the repost ... what's the point of saying 'no HTML' and then not auto-encoding < and >???)

A nit and an addition.

The nit:

eBay is between a rock and a hard place. Yes, you and I looking at that form would expect the checkbox to be highlighted after the Submit button, but that would cause problems for people who expect "login" forms to always be <login><tab><password><tab><space> (<space> being the activator instead of <enter> because, you guessed it, many web forms don't get the damned default button paradigm right so the only way to know what the heck button is being pressed is to highlight it and press it yourself!)

The second option they have is keeping the ingrained keyboard pattern in place, but move the visual cue (the location of the checkbox) to AFTER the submit button. However, this too is bad form, as it then visually indicates that the checkbox is not being submitted.

The solution, IHMO, ties in with the suggestion below.


Open up any Windows or OS X dialog box with multiple buttons and text fields, and what do you see? You see the focus ring around the current control, of course, but you *also* see an indicator around the default "enter" button. THIS IS CRITICAL. Why has the web forgotten this?

If only we knew for a certainty that "Enter" was going to submit the "Submit" button, not the "Reset form and lock my account until I call a support representative" button, we could confidently follow your <username><tab><passwd><enter> advice instead of trying to tab to the right button and hitting <space> instead!

But, we don't know this for a certainty, and I suspect anyone who's lived through the past decade with a keyboard control tendency has been burned by "enter" not submitting the right button on the page.

Tom Dibble on February 11, 2008 7:30 AM

Well I don't know what you expect when the HTML DOM itself does not fully support the concept of "focus". Although you can set focus to a specific control you can't make a call to get the control that currently has focus. There is no "hasFocus" or similar methods/properties in the DOM.

Matt on February 11, 2008 7:32 AM

@Akira:

"Firefox 2 is particularly bad on the Mac: tab does not allow you to move to a drop down list field. This drives me crazy."

This seems to derive from the inexplicable default behavior of Mac OS X to never focus on things like dropdowns and checkboxes. Drives me ()#*& crazy! Of course, luckily, there is a system-wide setting which sets what should be "normal" behavior. On the downside, apps which "emulate" controls instead of using native controls (Firefox for one, the 4D programming environment which I need to use at work for another) don't inherit this setting naturally and tend to forget to look at it. This is yet another reason why you should always be using the native controls, not roll-your-own controls made to look like them!!!

Tom Dibble on February 11, 2008 7:45 AM

The out-of-order tab order on eBay is particularly annoying. You expect it to go like this: username, tab, password, tab, space (to check the box), tab, enter.

It ends up going like: username, tab, password, tab, space -- oh, look the form was submitted!

James Cassell on February 11, 2008 8:02 AM

Unless there is a way to determine which control has focus - do NOT place focus on the user-name field (or anywhere else) after the page loads. I hate having the focus move from the password field back to the user-name field without my knowledge, just because the page finished loading, causing me to type my password there instead for all to see. This is a serious security issue.

KG on February 11, 2008 8:10 AM

Jeff, you are right on the mark with this article! The user interface of PC software has improved dramatically over the past 20 years, but the new generation of Web applications seems to have forgotten these important user interface lessons, and unfortunately software usability has taken a giant step backward with Web 2.0. I discuss more UI blunders in my article, "PC's and the Disabled: 20 Molehills that Become Mountains."

http://www.devtopics.com/pcs-and-the-disabled-20-molehills-that-become-mountains/

DevTopics on February 11, 2008 8:19 AM

The worst is flash applications. If you leave your mouse sitting on a web page while you use the keyboard to navigate to, say, pandora, flash will steal some sort of pseudo-focus because the mouse is hovering over it. It will additionally disallow you from using ctrl-tab or even regular tab to escape this fate, which makes it even more insidious than normal focus issues. If you have any tabs laying under it, you must move your mouse, or, if you really want to work, make creative use of the obscure "move window with keyboard" shortcuts in your OS of choice to move the window out from under the mouse.

The best workaround is to keep flash apps in a different browser window. Power-hungry as they may be, they can't steal your alt-tab. This, fortunately, makes sense for pandora, but as part of normal browsing it might not.

Ben on February 11, 2008 8:33 AM

In your example I would expect the tab order to be 1, 2, 4. How often do you expect to toggle the "remember me..." check box?

Andrew on February 11, 2008 8:54 AM

"mmm, properly drawn fonts, mmm. Sorry, didn't mean to drool over Safari."

They're not properly drawn.
http://codeplusplus.blogspot.com/2008/01/web-font-shorts.html

Sean on February 11, 2008 9:04 AM

Personally I think ebay's tab order is correct. The "stay logged in" checkbox is a default value set to false (i.e. ebay assumes that you do not want to stay logged in) so you tab over it which prevents you from accidentally keeping yourself logged in on a public computer.

Perhaps Ebay's problem with this form is not the tab order but the fact that they put the "stay logged in" checkbox between the password field and submit button making you think that it should be in the tab order when it shouldn't be.

I think that the "forgot my username", "forgot my password", and "stay logged in" options should not be on the form at all but should be in some other obvious place on the page.

Timothy Lee Russell on February 11, 2008 9:06 AM

@Timothy

Agreed, and I'll take it one step further.

What do you do when you're focusing a text field? You type. Pretty understandable by even the most novice web user.

What do you do when you're focusing a checkbox?

You... press the space bar.

How many users know that the spacebar toggles the value of a radio button or checkbox? (I'm about to hear cries of "the smart ones!" or "the ones worth having!" given this blog's audience :)

Skip the non-text controls like Safari does.

Rob

Rob S. on February 11, 2008 9:31 AM

Once again, young-uns figuring out what VT-220/*nix/database developers knew and did 20 years ago. Ignoring your elders. Pity.

BuggyFunBunny on February 11, 2008 9:32 AM

Also there should be a sensible action when the enter key is pressed. Too many web login screen do nothing - they should submit the damn form! I shouldn't have to click on the submit button or tab over to it before pressing enter.

mikeb on February 11, 2008 10:01 AM

I just press tab the required number of times to get focus on whatever field I need to type in. On my bank's webpage I have to press tab four times to get from the user name to the password field. While it would be ideal to just press tab once, it seriously takes 0.2 seconds longer to press it the extra number of times. Not a big deal.

And realizing what has focus is as easy as breathing, regardless of the browser you're using. Just pay attention.

Brent on February 11, 2008 10:03 AM

The funny thing is that although safari is really good with showing focus, OS X in general is hard to get into a keyboard friendly state. For a while I had repeated issues with dying mouse batteries, and it took me quite a while before I had figured out how to use the accessiblity features to enable keyboard navigation and then even more to get to the point where you could tab through all of the links on a web page. The funny thing is that normally I'd just look up how to do this, but with my mouse battery dead and keyboard support off there was no way I could do it. I couldn't even launch safari or shut down the computer.

BobMac on February 11, 2008 10:29 AM

@Maks Verver: Konqueror uses KHTML. Safari uses WebKit. WebKit is based on KHTML. Maybe that has something to do?

@Matt: Well, there are onFocus events you could use... But then you have to add the event to all elements you care about, and keep track of which one is focused with your own code :-\

Nicolas on February 11, 2008 10:41 AM

You don't have to order the HTML. There is the tabindex attribute for certain elements, see http://www.w3.org/TR/html401/interact/forms.html#adef-tabindex

pengian on February 11, 2008 10:54 AM

"While it would be ideal to just press tab once, it seriously takes 0.2 seconds longer to press it the extra number of times. Not a big deal."


You can hit the same key 4 times in just 0.2 seconds? I still have trouble with Unreal Tournament's dodge jump. :-\

KG on February 11, 2008 11:03 AM

I wouldn't blame the browsers, it's not their place to. Web developers can make their focused text boxes stick out if they want. I think a browser should ONLY render the page correctly as the developer intended. It's the developers job to make their UI user friendly.

Jesse on February 11, 2008 11:07 AM

Not sure if this has been mentioned earlier, but I think the 'enter to move to the next field' thing comes from the Terminal/Mainframe world, where I've seen data entry applications work exactly that way, at hospital check-in stations for instance. Data entry people who have worked on such systems for years, don't expect a screen to advance until they've walked the cursor through every data field, and finally reached the magic one near the bottom that is 'supposed' to confirm all that data entry.

Obviously the PC world has developed a different paradigm, but the other one is still in use in plenty of places.

RoverDaddy on February 11, 2008 11:13 AM

Someone should create a JavaScript plugin that adds a consistent focus behavior to all modern browsers. If someone else doesn't, I will when I get some time or if I get paid to do it.

Thanks for the article, keyboard navigation is important - especially for form entry.

Marc on February 11, 2008 11:39 AM

Fortunately check boxes don't trigger on the Enter key in web forms. Unfortunately, people forget to grab the Enter key and submit the damned form before you tab over to the Submit button in the first place... Then again, there's always that person that's trying to learn to use the keyboard on web forms and is hammering the Enter key trying to figure out why the check box won't check.

Vizeroth on February 11, 2008 11:54 AM

"The second option they have is keeping the ingrained keyboard pattern in place, but move the visual cue (the location of the checkbox) to AFTER the submit button. However, this too is bad form, as it then visually indicates that the checkbox is not being submitted."


Easy. Put the check box to the immediate right of the submit button.

Keshi on February 11, 2008 12:16 PM

Wayne:

Yes - but is the order very logical? I agree that it is a nice feature to start in the name field but wouldn't you expect the search field at the top to be the first tabstop?

My point is that the tab ordering is not always clear even on a rather simple page and I think that a clear and simple tab ordering is as important as having the focus highlighted.

And the fact that the tabs 'wraps around' after you past bottom of page and starts with the first picture is ... well not what I would expect.

Ec on February 11, 2008 12:30 PM

Part of the problem is that you can never satisfy everyone. Going through the comments it appears that there's a division over whether you should set the tab focus to the 'Keep me signed in for today' checkbox or skip it and go to the 'Submit' button.

I've just completed a project to migrate part of an internal accounting application from a native windows application to a web-based application. The accountant is upset because she can't use the enter key to move from field to field anymore.

I think anyone who's designed a UI realises that there will always have to be a compromise at some point. It wouldn't surprise me to discover that ebay's marketing department insist on having the 'Keep me signed in for today' checkbox where it is, but the security auditors insist that it doesn't automatically get focus. I've been there and done that!

Naked Programmer on February 11, 2008 12:55 PM

Upon using my tab button to get down to this field, it comes right after the URL field, however not knowing that I went through every link on the page! Then I found that Jeff has a hidden Hit Counter done by statcounter.com. Don't believe me? After the "Subscribe via email" link, hit Tab again, and it doesn't take you anywhere and doesn't highlight anything, however in the bottom left corner you see it's address there :P

Sean on February 11, 2008 1:15 PM

This happens at the citibank website (citi.com), when you enter your username and hit tab; it flies over to the signin button. Some would say its a security feature (to force you to doublecheck you're typing your password on the right field i guess), but its a huge annoyance.

-mp

Mauricio Pastrana on February 11, 2008 2:38 PM

I'm still waiting for the hotkey combo that lets me move the cursor with the arrow keys so, when navigating a webpage, I can get to that button down the bottom without tabbing through every link button/textbox in between.

David Hodges on February 11, 2008 2:49 PM

Firefox's mystery meat navigation hits you all over the place. To see one very obvious example, try using Find (Ctrl-F) on a typical web site with information sprayed all over the place with div's and a mixture of different fonts, type styles, and colours. On the first find result you can see some element on the page highlighted. On the second... [pause]... oh, it's over there. On the third... no, it's gone. Something is being found somewhere, but there's no obvious highlighting so there's no way to see what's been found. As a result the Find function is rendered nearly useless, since manually scanning the page to try and locate where the current Find focus is, is only marginally better than manually scanning the page the find the desired object in the first place.

Dave on February 11, 2008 4:39 PM

Most annoying bug in an application ever, and it's still there.

1) I open IE
2) I begin typing the address I want to go to.
3) My homepage loads and fires off a focus that takes my cursor out of the address bar I was just typing in.

Seems like back in the day it even revalidated the address bar and took away whatever you were typing to replace it with the address that just loaded. IE still does that to this day. Couldn't IE check to see if you are typing in the address bar and let you keep the focus there?

Mattkins on February 11, 2008 8:06 PM

When it comes to highlighting the field in focus, what you see in Safari is what you see in client apps in OS X as well.

Diego on February 12, 2008 2:03 AM

By the way, what happened with the font in your site...??? It looks ugly in Firefox... Did you do something or is it my machine..???

Christian on February 12, 2008 4:31 AM

You know, when we all evolve that third prehensile arm in order to operate the mouse, this will be a moot point.

Chris Chubb on February 12, 2008 7:34 AM

If you let your browser remember name/password for a login page, these fields are populated automatically when the page opens. The best is then to set the initial focus on the [Sign In] button. Only on the name field if it's empty...

Luke N. on February 12, 2008 10:31 AM

"If you let your browser remember name/password for a login page, these fields are populated automatically when the page opens. The best is then to set the initial focus on the [Sign In] button."

I never set it to remember my user-name / password, because otherwise I would eventually forget them. I also don't feel comfortable with having my passwords (e.g., my Amazon password) stored anywhere.

KG on February 12, 2008 11:59 AM

>Most annoying bug in an application ever, and it's still there.
>1) I open IE
>2) I begin typing the address I want to go to.
>3) My homepage loads and fires off a focus that takes my cursor out of the address bar I was just typing in.

This is a generic idiotic windows behavior - not limited to IE.

Start typing and *any* dialog that comes up grabs the focus.
NO! Wrong! The system should pay attention to what *I'm* doing. It's a *machine*. It works for me. I don't work for it! Focus should stay with what I, they guy who *paid* for this pathetic excuse of an OS, not what some dimwitted programmer decided was important that day.

Not that I have a strong opinion about this or anything.

And can we do something about those *&^(*&#)_* alert messages in the bottom right corner too? The ones that say to "Click Here for more information" (e.g. MSConfig) and then don't actually do anything?

Cheers!

ThatGuyInTheBack on February 12, 2008 1:46 PM

Others have requested a Bright Focus [http://diveintomark.org/archives/2006/04/25/new-focus-indicator] like Safari's in Firefox. Bugzilla users can voice their support for such an enhancement by voting for bug #251198 [https://bugzilla.mozilla.org/show_bug.cgi?id=251198].

Robin Lionheart on February 12, 2008 2:49 PM

Good article but I take issue with one oversight (as other posters have also said).

If you are having a generic page, say a portal with the front page + a login or google with the search box, do not set a first focus. With the way the focus is handled it's very frustrating to start typing then have the page grab your focus when it loads. You are much better off just having the relevant field being the first one in the HTML. That way, even without an initial focus, if I want to navigate by keyboard only I can simply hit tab once to focus on the first field in the login list.

Logo on February 12, 2008 2:54 PM

Having the tabstop skip over the remember me checkbox greatly reduces accidental invocation of the feature - this is particularly important on public machines.

If you want to navigate by keyboard and don't want to worry about good web design, konqueror has a nice feature where pressing the ctrl key overlays tooltip like tags over each link with a corresponding hot-key.

Jerry Gartner on February 12, 2008 7:46 PM

At work I have to remember about 7 diferent passwords. At home is no different because I wipe my personal data from my browsers every two or three days.

The solution for my headaches was this wonderful pice of free software http://keepass.info/

- It gives you the option to mast the pasword or not.
- You can double click an entry, the password is copied to memory for 10 seconds before the buffer is cleared.
- You can use only a master password or to also include a key saved in a file.

Ricardo C. on February 12, 2008 8:18 PM

Jeff, You seemed to be focused on the focus http://www.codinghorror.com/blog/archives/001011.html (December 04, 2007 Please Don't Steal My Focus)

right before posting this I was reading an important and long email and gmail stole my focus to make me login again...and the find the email i was reading to finish....'

Ever seen a focus fight?
when two items on the page both try to get focus at the same time: the browser wigs out and flashes back and forth between the two till you have to alt+f4 or give it the ole three finger salute alt+ctrl+del

Syama on February 12, 2008 9:23 PM

The :focus pseudo class works fine in Firefox, but don't hold your breath waiting to see it in IE. It doesn't work in IE6 or IE7.

In a recent web app I had some users who were heavy keyboard users and couldn't tell where the focus was, so I modified the CSS to show a bright orange border showing the control with focus. It worked great in my default browser (Firefox). Then in IE, no luck. There really didn't seem like any easy hacks to work around this either.

Maybe someday IE will support it (IE8?), but for now I have pointed users to Firefox if they want this feature.

Marc on February 12, 2008 10:09 PM

I don't need "reveal password".

I hate tooltips in places where I don't need them. Tooltip pops up and kind of grabs my focus. If I was looking at a row below another row, of course some tooltip wants to be there blocking my view. Why not put tooltip in certain place of the screen somewhere and also allow to disable the tooltip or all tooltips.

In general programs do lots of annoying things or won't behave like I wanted them to behave.

Don on February 13, 2008 1:54 AM

"Not sure if this has been mentioned earlier, but I think the 'enter to move to the next field' thing comes from the Terminal/Mainframe world..."

And dealing with user expectations on this can be really fun...

I had someone storm out of the building and go AWOL for three days because he was so angry with me that the Close button closed the form and not "the record". It was hard to be sympathetic: that's what the little 'X' in the corner of the form does for every other Windows application on the face of the Earth.

Politely explaining that users do not have to manually open and close records in Windows (and that it is automatically done behind the scenes while you work) did not help. I stopped short of explaining how hard this would be in practice with a modern relational database system.

I actually marvelled how he managed to get out of the building: I had visions of him frantically pushing on doors marked "pull".

Paul Coddington on February 13, 2008 2:06 AM

I do agree that the whole focus thing and tab order could be better handled but it really isn't that much slower to use the mouse. The mouse is a good tool and works very well, are the few seconds you might gain using the keyboard really worth redesigning a site.

Christopher on February 14, 2008 7:54 PM

A site is not needed to be redesigned, if it is designed in the first place properly. But surely there will always be managers, who don't think some good tab ordering is so important, that more money should be poured into the project. And we will always be seeing the results. Anyway, if it is too hard to set tab ordering, then of course its waste of time and money. But setting tab ordering should be easy to do with development tools.

Don on February 15, 2008 12:09 AM

"But isn't there a blinking cursor in the text field if it has focus?"
In Firefox, not always:
https://bugzilla.mozilla.org/attachment.cgi?id=99019
(although it is marked as fixed for FF3)

Tony on February 15, 2008 11:36 AM

Opera has updates their browser to highlight userinput fields with big blue boxes.
It is available in the latest snapshot.

Bart Stavenuiter on February 17, 2008 11:50 PM

Thanks for another great article :) I think there's a stronger argument for keyboard navigation in websites than RSI and efficiency, good as they are - To the sight-impaired, keyboard navigation is often essential.

Many of the websites named and shamed here are nighmarishly hard to use if you rely upon a keyboard and certain screenreaders to navigate. I sometimes wonder if there's a discrimination-by-exclusion case under disability rights legislation somwhere in here?

Owen on February 18, 2008 8:44 AM

For any vim users out there...I've currently installed the vimperator plugin for firefox. It's a little strange at first but after a couple hours, I love it! good bye mouse.

mr morrow on February 21, 2008 12:30 PM

There is a blinking cursur field on the screen and that clearly indicate where the focus is. This is a non-issue!!!

Renegade4ever on April 1, 2008 10:31 AM

Unfortunately, a blinking cursor does not apply to buttons, images, and such that are not text fields.

http://babelfish.altavista.com/ has rather poor focus order, while http://babelfish.yahoo.com seems fine.

On the AltaVista version, should I click in the top text entry field and press tab, I would expect it to go to the "Select from and to languages" drop-down box that is immediately below. No, in Firefox I usually must press tab approximately 27 times, or shift-tab 6 times!

Tashara on April 6, 2008 4:51 AM

Let me put this scenario to you.

If you are going to say 'Remember me on this computer' - you are going to do that exactly once. That once you may have to use the mouse. Every other time, you are logged in automatically.

On the other hand, if you are not going to check that box, you do not ever need focus on that checkbox. Actually, a lot of users have the habit of Tabbing to the submit button before pressing enter to submit the form. I know, this habit is entrenched usually by developers not following your rule no. 3. Anyway, if you do that, you might be irritated if you have to tab twice after password EVERY SINGLE TIME.

Having the user who is going to use that mouse once, or a tab and a shift+tab once is way way better than having another user have to tab an extra time every time.

cloud9ine on April 17, 2008 11:11 PM

it's ok in firefox three now, so you don't need to bother.

Creative Spy on August 29, 2008 12:48 PM

p.s.: i've described that @ http://creativespy.com some time ago.

Creative Spy on August 29, 2008 12:50 PM






(no HTML)


Verification (needed to reduce spam):


Content (c) 2009 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved.