Tabbing thru fields –
tabbing order in HTML forms, and related issues

Tabbing is not just a convenience; it is also an important accessibility feature, since it makes it possible to fill out a form without a mouse or other pointing device. (See Techniques for Web Content Accessibility Guidelines 1.0, section Keyboard access.) It's hard to say how many users know about this nice feature, but the idea is applied in many other programs than Web browsers, too.

Wrong order?

But if the order of form field elements in an HTML document, as they textually appear in "HTML source", does not correspond to the intended filling order, serious problems arise. This is usually caused by attempts to use tables for layout purposes, e.g. to put questions in a form into two columns. The simple answer is: just don't do that. Using a table to express the logical structure of a form is a different thing, of course. You could e.g. put captions (explanations) for fields into one column and fields themselves to another. Note that doing so, the order of the fields in "HTML source" corresponds to the filling order.

Consider this schematic example:

It's intended to be filled out by going through fields 1 to 4, then proceeding to the column containing fields 5 to 8. But since the textual order of the input elements in "HTML source" is 1, 5, 2, 6, etc., that's the tabbing order too, at least by default. And there is no reliable way of changing the tabbing order from the default.

Even if tables are used structurally, problems sometimes arise due to browser bugs related to align attributes for tables. The simple cure is to avoid such attributes.

"Saving space" causes trouble

On Web pages, you need not "save space" by using multi-column presentation. Although Web pages can be printed on paper, too, HTML forms aren't filled on paper. (Well, a user could print a page containing a form, fill it on paper, and send it, but for such purposes, formats other than HTML are much better. PDF and MS Word formats are commonly used.) It is better that the user does not see too many questions at a time, since that way he can concentrate better on the question he is answering right now, then scroll downwards if needed.

So just make it a structural table, with field names in one column, fields in the other. (Technically, you could use the presentation where the fields are in two columns and still get the tabbing order right. But you would need to use nested tables: make it a table with one row, two cells, each cell containing a table, which consists of one column of texts and one column of input elements.)

Big form - big trouble

A very large forms, with dozens of fields, inevitably causes problems. To begin with, who's going to fill out a huge form? Who's going to do it without going to the bathroom and noticing upon return that the modem line just fell down, or Windows crashed, or connection to server was lost? Or consider the frustration caused when the user accidentally hits the ESC key which may erase all of the input. So if you really need to ask for lots of information from the user, try to create a "chain" of form submissions so that the user can fill out some data, submit it - to a form handler which processes the data and sends back a page containing a form with new fields to be filled out, etc. This is relatively complicated and requires that the pages carry some identifying information. The form handler could put the already submitted data into hidden fields in the new form it is going to send, or store that data onto the server and generate a unique identifier for the data set, putting just that identifier into the form. So there's some work to be done, but that's the user-friendly way.

Would tabindex help?

The tabindex attribute, which can be used to suggest a tabbing order by assigning different tabbing index numbers to fields, is part of the HTML 4 specification. But this does not mean that you need to use it! Generally, you should design the form so that the default tabbing order is suitable for it. And Netscape 4 for example does not support the tabindex attribute at all.

What about JavaScript?

It would be possible to use client-side scripting in an attempt to affect the tabbing order. The general idea is to use the focus() function to focus on the field that should be filled next. See section Focusing and Tabbing in the JavaScript Forms FAQ. But this would fail even on some JavaScript enabled browsers, and naturally on all JavaScript disabled browsers.

"Auto-tabbing"

Sometimes one would like to cause "auto-tabbing" so that when a field has been completed, the next field is automatically focused on. For example, if a text input field should contain a four-digit number, or at most four characters, then one might wish to automatically proceed to the next field when the fourth character has been entered.

There is no way to specify that in HTML, in any direct way. Admittedly browsers conceivably could use the value of a maxlength attribute in that way, but no browser is known to do that. In JavaScript, one could do it, though it would not work in all JavaScript implementations. Since it's just an optional enhancement to the user interface, no harm is caused by it when it does not work; the user just uses the normal ways of filling out a form. But it may cause problems when it works! It may confuse users that things happen "on their own", and they might get upset after making a typo in the last character of a field and finding themselves in the next field. But in some cases, the benefits might overweigh the risks.

The principle is simple: use the onkeyup attribute with an event handler that checks the amount of data in the field, and conditionally focuses on the next field. Example:

The markup for the first field illustrates the idea:

<input name="year" size="4" maxlength="4" onkeyup=
"if(this.value.length>=4) document.dateform.month.focus()">

Of course, if there is a large number of fields, it becomes tedious to write such markup. You could perhaps use preprocessing tool with macro definition capability. Another alternative is to use JavaScript-based tools like the one explained on Mikodocs page Automatically Jumping To The Next Field.

There's a problem, though. Suppose the user types the year and automatically gets to the second field but then notices he has mistyped the year. Using Shift TAB to get back to the previous field does not work, since the onkeyup event in the previous field takes him forward to the next field!