Sometimes, often as a result of a web page's layout or design, a label element cannot be used to identify a form control. Certainly, one can always use a visually hidden label, which is my preferred approach: you never know how the design might change in the future, at which point, if you've already got the label in the markup, it's easy enough to make it visible and position it should you need to, without touching the HTML.
But I know that some people are reluctant to add an explicit element if it is only going to be hidden and the same information can usefully be provided by other means. This is one situation where using a title attribute on a form control comes in. It is precisely the topic of WCAG 2.0 Technique H65: Using the title attribute to identify form controls when the label element cannot be used.
Screen Reader Support?
Based on our experiences with screen readers, we know that there is pretty good support among them for this method of identifying or labelling form controls. Technique H65 specifically notes support in JAWS and Window-Eyes. But equally from experience, we know that not all screen readers behave the same when it comes to markup and techniques that we expect they should otherwise manage in a straightforward and consistent manner. So I quickly performed a test to confirm how well a number of popular screen readers support the use of title attributes on form controls in place of actual labels.
The Test
Below are two forms identical in all ways except that the second form uses title attributes on each form control instead of explicit label elements. As such, in Form #2, the form controls appear visually to have no associated label text, but they each have a title attribute that contains the same text as the explicit label does in Form #1.
The forms were tested using the following screen readers, each one with its default out-of-the-box settings:
- JAWS 9.0.2191
- JAWS 10.0.1178
- JAWS 11.0.1471
- Window-Eyes 7.2
- NVDA 2010.2beta1
- SAToGo 3.1.24
- VoiceOver 3
- Orca 2.30.2
The forms were traversed simply by using the TAB key to move from one control to the next and listening to how the screen reader announced each control when it received focus.
Also note that there is some additional text inserted between each of the form controls. This was added to see if the screen reader, when announcing a form control that has no explicit label element, would apply its own heuristics to try and determine the control's label text instead of, or in addition to, using the title attribute provided. Sure enough, this is how Orca behaves.
The results follow the two test forms below.
Form #1: Using Explicit labels
Form #2: Using title Attributes Instead of labels
Results
Things are pretty good, and I'm happy to confirm, in case there was ever any doubt, that there is consistent support among the screen readers tested for form controls that use title attributes in place of explicit labels. The one exception is Orca 2.30.2.
With Form #2, Orca (tested with FF3.6 in Ubuntu 10.04) tries to determine label text from the surrounding context instead of using the title attributes provided, and reads the text preceding a form control as its label text, sometimes also including the control's title attribute. For the text inputs, the select combo box, and the textarea, Orca reads the text preceding the control as its label, and does not announce the control's title attribute. For the checkboxes and radio buttons, Orca reads the text preceding each input as well as its title attribute.
Interestingly, JAWS 9.0.2191 in FF3.6 behaves oddly with Form #1, where explicit label elements are used. For the checkboxes and radio buttons in Form #1, instead of announcing the explicit labels for those controls, JAWS 9 reads the text that comes after each control's label. It does, however, properly use the label for the text inputs, the select element, and the textarea in Form #1.