<input type="text" name="searchtext" title="Search">
<input type="submit" name="mail" value="search mail">
<input type="submit" name="web" value="search the web" title="search the web: opens in a new window">
The Basics: prompt placement
Before control; in left-to-right languages, either to the left or immediately above the control. Buttons are self-labelled prompts. Check boxes and radio buttons are special types of buttons, and so the prompt is part of the button (increases target area), and placed immediately after the control to show the semantic difference
Implicitly positioned labels do not work correctly in IE6 and lower, and with some screen readers (JAWS 6.2; probably others, but don't know). The for attribute in the hybrid version makes it an explicit association. Implicitly associated labels are made available through MSAA, and are legal according to the specification, making this a user agent problem. Having said that, I don't like implicit associations. Semantically, a label is associated with its form control; it doesn't make sense to say the prompt is the parent, and the form control is its child. It would make more sense to say that the prompt is part of the form control, as they are in XForms.
When there's no default option, it's useful to make the first option a prompt, but it should provide context, and the control should still have an explicit label (or title attribute). Relying on the first option as a prompt might work in some circumstances, but it soon breaks. For example, if a mistake is made, the user's selections should be retained. They now have a drop-down box whose label is a value that might not be accurate.
Basics: Multiple labels for a control
first name optional
<input type="text" id="multi1" name="multi">
first name optional
for="multi2">name <input type="text" id="multi2" name="multi">
first name optional</label>
<input type="text" id="multi3" name="multi">
<label for="multi3">first name optional</label>
for="multi4">name (first name optional)
<input type="text" id="multi4" name="multi">
The tabindex attribute specifies the position of the current element in the tabbing order for the current document
Valid for elements that can receive focus (a, area, button, input,object, select, and textarea)
The tabindex attribute expects values between 0 and 32767
The lower the number, the earlier the interface element will be visited (except zero)
A tabindex attribute value of zero "0" means the element is navigated in the order it appears naturally in the source order
Although intended to be an accessibility aid, explicit tabindex values often cause problems, as they're easy to go out of sync, resulting in a tab order that is unexpected and confusing to the visitor unless great care is taken.
Use of the tabindex - continued
Adding a positive tabindex attribute value to a non-interface element explicitly puts the element into the tabbing order
Not legal according to HTML 4.01 and XHTML 1.0
Not supported by all user agents
If a tabindex attribute value of 0 is used on a non-interface element, the interface element will be added to the browser's tabbing order at the order it appears naturally in the source order
A component such as a slider would require adding to the tabbing order so that it can be operated with the keyboard; in this case, you would use tabindex="0". If you need to be able to focus on the element, but do now want it appearing in the browser's natural tabbing order, you would use tabindex="-1"