Title Attributes as Form Control Labels

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

Some text preceding the "Your Name" input field.

Some text preceding the "Your Nickname" input field.

Some text preceding the "I like fruit" checkbox.

Some text preceding the "I like meat" checkbox.

Some text following the "I like meat" checkbox.

Where is your home?

Some text preceding the "Northern Hemisphere" radio button.

Some text preceding the "Southern Hemisphere" radio button.

Some text following the "Southern Hemisphere" radio button.

Some text preceding the "Sex" select combo box.

Some text preceding the "Leave a message" textarea.


Form #2: Using title Attributes Instead of labels

Some text preceding the "Your Name" input field.

Some text preceding the "Your Nickname" input field.

Some text preceding the "I like fruit" checkbox.

Some text preceding the "I like meat" checkbox.

Some text following the "I like meat" checkbox.

Where is your home?

Some text preceding the "Northern Hemisphere" radio button.

Some text preceding the "Southern Hemisphere" radio button.

Some text following the "Southern Hemisphere" radio button.

Some text preceding the "Sex" select combo box.

Some text preceding the "Leave a message" textarea.

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.

Tagged , , , , , , , , , .
Comments (RSS)

5 Responses to Title Attributes as Form Control Labels

  1. 1. Steve:

    Very helpful information. Thanks. I will update my web site evaluation criteria accordingly.

  2. 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…

  3. 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.

  4. 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.

  5. 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 repetitive title attribute, but could benefit in some cases, I suppose, from one that provides some additional but non-crucial information, as we all know the title attribute is meant to be used. But even then, at least where the label is visible, my preference would be to use good and clear label text to the exclusion of a title attribute, ensuring that any useful information that helps a user to understand and complete the form is there explicitly in the label or the form itself.

Comments are now closed.