Summary: You can make the best use of browsers' default behavior in tabbing, if you simply put the fields into your document so that the textual order of form field elements in the HTML document corresponds to the intended order of filling them.
|
|
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.
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.
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.)
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.
Web browsers typically let the user proceed from one
form field to the next one by "tabbing", i.e. by pressing
the TAB key. So after filling out a field, the user does not
need to use the mouse to focus on the next field by clicking on it;
instead he just presses the TAB key. Typically, he can also
move backwards using Shift TAB.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.
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.
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()">
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!
Note: Another often asked question relates to controlling the size of controls, such as buttons. This can be achieved using styles:
By default, the dimensions of the button is automatically set to the dimensions required to accommodate the content inside, such as an image. There will often be times when you want to manually control this dimension to fit your design. By using another CSS declaration, you can. To control the width/height of the button, use the following style declaration:
style="width:whatever_width;height:whatever_height"