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 label
s.
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 label
s
Form #2: Using title
Attributes Instead of label
s
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 label
s. 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 input
s, 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 label
s 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 input
s, the select
element, and the textarea
in Form #1.
Comment #1.
Steve:
Very helpful information. Thanks. I will update my web site evaluation criteria accordingly.
Comment #2.
eleg:
You’re not allowing keyboard-only users* to get access to the title’s attribute content: AFAIK no browser shows this information on focus, only on pointer’s hover. And when you have no pointer, you’ll have no info… :-/
Very bad idea, in my opinion, especially for radio-buttons and check-boxes.
The only case I could imagine it is a useful technique is a search field, with the text of label as the predefined value of the field, which wiped on focus (very common behaviour). The title attribute then allows the blind user to have access this information (which disappeared).
* not only blind persons, but also Parkinson’s disease patients, mobile phone’s users ASO…
Comment #3.
Jason:
@eleg
Thanks for your comment.
You’re correct, of course, that browsers don’t display the title attribute tooltip on focus.
The point of this research was not to suggest that title attributes be used in place of explicit labels for any or all controls in a form, but simply to confirm support in various screen readers for use of the title attribute on form controls.
In those cases where it may be reasonable to leave out or hide a form control’s label, the purpose of the form control should nonetheless be clear to sighted users from its placement and surrounding context. Using a title attribute on the control is simply an alternative to using an explicit but hidden label or no label at all. The title attribute also provides the form control with programmatically determinable label text that can be used by assistive technologies like screen readers.
For two other examples in addition to the search field example you mention, see WCAG 2.0 Technique H65.
Comment #4.
Graham Armfield:
Interesting research Jason – thanks.
Problems can arise when developers use both title attributes and labels but then don’t check that they align – and I have seen that done unfortunately. I believe the default action for JAWS would be to favour label over title but I know you can configure that to reverse it or use the longer of the two.
Not sure about other screen readers though.
Comment #5.
Jason:
@Graham,
Yes, misuse/abuse of the
title
attribute is an all too common problem anywhere it occurs, not just with form labels. Obviously, a well-labelled form control doesn’t need a repetitivetitle
attribute, but could benefit in some cases, I suppose, from one that provides some additional but non-crucial information, as we all know thetitle
attribute is meant to be used. But even then, at least where thelabel
is visible, my preference would be to use good and clearlabel
text to the exclusion of atitle
attribute, ensuring that any useful information that helps a user to understand and complete the form is there explicitly in thelabel
or the form itself.