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
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
Form #2: Using
title Attributes Instead of
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
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
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
select element, and the
textarea in Form #1.