TitleAttribute for Form Controls
TitleAttribute for Form Controls
Search forms often provide an example of controls that lack on-screen prompting text. The screenshot below is cut from the IBM web site.
The form consists of a text entry field (input with type="text") and a push button with value="Search". There is likely to be no question in a sighted visitor's mind what goes in the entry field; but for a blind user, they would land on the text entry field, and their screen reader would just say "edit" or "edit box" with no hint as to what goes there. It is true that continued exploration would give a very good clue ("button search"), but that is extra effort that is completely unnecessary if the title attribute is added to the input element, title="search". With that, screen readers will announce "Search edit".
It is interesting and a bit daunting that this is not what IBM does. Instead they use an invisible image, place alt="Search for:" which is announced "Search For colon" by JAWS, and warp the image in a <label> tag:
<label for="q"><img src="//www.ibm.com/i/c.gif" width="1" height="1" alt="Search for:" /></label> <input id="q" maxlength="100" name="q" type="text" />
There is nothing inherently wrong with this technique, though it is a kind of "hack". Unfortunately, some testing tools don't yet recognize the title attribute as a valid way to satisfy the forms provision in Section 508, so that may be the reason IBM uses this technique.
The label construct is in a sense inadequate because it can only assign text to one form element. If the prompt is at the left side of a row in a table of input elements, you cannot use the label element to associate that prompt with each of the form elements in the row (because id's must be unique). If an input element is characterized by two pieces of text, say column and row headers, then the label element can technically tie two pieces of text to one control, but in tests of this configuration, none of three screen readers picked up both pieces of information.
Here is an example of a table of input elements that might occur in a hypothetical web-based tax form.
We discuss tables in detail in the lesson on Accessible Tables. One might hope that table navigation with a screen reader would automatically speak the properly marked up table headers. That would be true when navigating the table in "web mode" or tables reading mode. But a user is going to be listening to these controls in forms mode, not in table reading mode, and in this situation the table headers are not spoken.
The title attribute for the input elements provides a simple and clean strategy of labeling in this case. Here is part of the code for the table above with the title attributes filled in.
<table cellpadding="0"> ... <th>W2 Gross</th> <td><input type="text" size="20" title="taxpayer w2 gross" /></td> <td><input type="text" size="20" title="spouse w2 gross" /></td> </tr><tr> <th>Dividends</th> <td><input type="text" size="20" title="taxpayer dividends" /></td> <td><input type="text" size="20" title="spouse dividends" /></td> </tr></table>
The last few versions of the major screen readers all support the title attribute on form controls. So when on-screen prompting information is not available or is dispersed, i.e., when the label element won't work, use the title attribute in the input element (or select menu, etc.) to indicate the purpose of the control.
It is important to use the label element, if possible, so that visible text is what is heard by screen reader users. That way, when the text changes, screen readers will hear the change, whereas the "hidden" title attribute might not keep up with changes.