Where the Heck is My Focus?

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

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.

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

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…

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

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.

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.

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.

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

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 logintabpasswordtabspace (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 usernametabpasswdenter 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.

(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 logintabpasswordtabspace (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 usernametabpasswdenter 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.

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.

@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!!!

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!

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?

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.

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/

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.

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?

“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