Getting TabIndex To Work For You
As part of a recent project I adopted a lengthy form, consisting of several "tabs" and at least a hundred input fields. Due to the nature of this form the tab order of each field was important. Not having paid much attention to the tabIndex property in the past I learnt a few things about it that I thought worth passing on.
The Form I was working on had the tab order of most of the fields set using the Notes Field's property box. You can tell a field has a tab order if there's a number in the corner of it, like so:
This is where my problems began. As with most things Notes they don't translate all that well to the web. Annoyingly, Domino doesn't apply a tabIndex to any dropdowns, which come across as SELECT elements in the browser.
The W3C say the following elements should support tabIndex:
A, AREA, BUTTON, INPUT, OBJECT, SELECT, and TEXTAREA
Because of this, tabbing through forms doesn't always work the way you'd expect. This is also down to the way browsers interpret tabIndex. Internet Explorer cycles through all fields/elements without a tab order, before starting on those that do. Hence, with Domino forms, all dropdowns are likely to come before normal text fields!
Another problem with the Notes tab order property is that it doesn't auto-update. If you copy a field from the top of a form and paste it at the bottom, it will still have the same tab order as the original field. If you insert a new field in the middle of some others you have to update the order of all those below it. Basically, you have to manage the order yourself, which is a pain in big forms.
Note that tabIndex does not have to be unique. It's ok to have more than one field with the same order, which can be useful, as I'll describe later on.
The reason I've not paid much attention to tabIndex in the past is that browsers generally do a good job of getting a natural tabbing order right. Assuming no fields have an explicit order the cursor will pass through the form top to bottom and left to right. For most forms this works fine. My problem was with a table like this one (focus on the first field and tab through):
| Person 1 | Person 2 | |
| First Name | ||
| Last Name | ||
| Country | ||
| Sex | Male Female | Male Female |
| Age |
The way the browser tabs through this form doesn't really make sense. You'd want to enter all details for Person 1, going down the first column of fields, before going back up to the top of the second to enter details for Person 2.
The easy way to do this is make use of the fact that tabindex doesn't have to be unique. We can add a tabIndex of 1 to the all fields on the left column and value of 2 to all those in the right, like so:
| Person 1 | Person 2 | |
| First Name | ||
| Last Name | ||
| Country | ||
| Sex | Male Female | Male Female |
| Age |
Feels more natural doesn't it. To do this in Notes you could use the field property mentioned above, although I opted to add tabIndex="X" straight in to the HTML Attributes. Either way is fine.
In summary. Don't ignore tabindex. Don't assume people click the mouse in to each field. Tab order is an important usability consideration. TabIndex is your friend; just don't let Notes manage it for you (dropdowns!) and don't feel you have to have a unique value for every field on the form. Best bet is to leave the browser to decide on an order and then over-ride it when you get a situation like the one I just described.
Skip to the 
You can subscribe to an individual
Great tip Jake! Working for a government agency, usability is always a concern and tab order helps with the flow.
Hi Jake,
This work's fine with fields that are displayed on the same form. But, you also need to take into account for when people use DHTML to show/hide sets of fields using tabs.
In the above event, you can add an "onkeypress" event to detect if the tab key was pressed. If so, then change the tab (and set of fields) and focus on the next field.
You will also need to allow for "SHIFT+TAB" to allow users to go back between tabs!
Later
Patrick
(e.g.
1. Last Field in First Tab
onkeydown="CheckTab(1, 'tab2', 'First Field in Second Tab')"
2. First Field in Second Tab
onkeydown="CheckTab(0, 'tab1', 'Last Field in First Tab')"
/********************************
Name: CheckTab()
Purpose: Used to allow for tab navigation (i.e. Using Tab Key) around the page and tabs.
Input: intType = Tab Type (i.e. 1 = Forward, 0 = Backward)
Output: None
********************************/
function CheckTab(intType, strTab, strField)
{
// Check if tab key pressed
if( (intType == 1 && !event.shiftKey && event.keyCode == 9) || (intType == 0 && event.shiftKey && event.keyCode == 9) )
{
// Click the Next Tab
ClickTab(strTab);
// Focus on the Field
document.getElementById(strField).focus();
}
}
/*******************************/
)
I think Patrick is on to something. You could include a hidden input on your form (no form field, just html) with a delimited list of your form fields as the value.
With the function bound to the keypress event of the appropriate controls (see W3C note abave) all you would need to do is consult this hidden input for the tab order whenever Tab was pressed. Pretty easy drop in code. Your maintenance task is reduced to simply ordering the field IDs in the list.
You should take a look at this webpage: {Link}
It's pretty good at explaining how to create accesible forms (without tables!). In particular, you'll probably be interested in this example:
{Link}
BELLA XXBELLA XX
BELLA XX
BELLA XXBELLA XX
Jake
I'm not able to test this at the mom. but my approach would have been to group the related fields/labels into fieldsets with a natural internal tabbing order that the browser manages and then to align the fieldsets into columns (or whatever else) with CSS.
No explicit taborder needed at all (assuming my approach works ...
Regards from a sailing catamaran in Turkey, courtesy of the wonders of Marina WiFi.
It's a hard life.
Ron
Hi,
I have a problem when I have a series of text fields and then a Richtext field.
The tab doesnot work for the rich text.
Great post! Thanks