Using Title in Basic Form Elements August 22, 2009
For a long time, I’ve been an advocate of using <label> whenever possible and generally shunning the use of title attributes whenever a label would do. I felt this way especially about forms buried in HTML tables. In fact, back in 2001 when Doug Wakefield and I were running through the testing that developed in the Access Board’s Guidance on HTML Forms, we told developers to always use explicit labels when putting forms into tables.
This week, I worked on a project that changed all that. It’s no secret that I’m under contract to create a simple online tool for the Federal government and ITI that enables IT companies to quickly create and edit VPATs in XML format. The form, however, needs to look like a tabular VPAT because, quite frankly, that’s what people are used to seeing. It’s the format we’ve used for almost 10 years now. I knew that headers and ID were great for making tables accessible, but screen readers want something actually tied to the form element— like the labeled element. Problem is that location in a VPAT table is meaningful— it is much more than a layout table.
The solution, of course, was to use the title attribute even where we would have once people to use <label> only. When put in a data table format, even basic <input type=”text”…> and <textarea> tags get the title treatment to provide the same information that location within a VPAT table would provide to a visual user. It was a humbling moment indeed.
This isn’t a new suggestion, as others have made the same recommendation. It’s also part of the WCAG 2.0 techniques (H65: Using the title attribute to identify form controls when the label element cannot be used). But it does still irk me that my old HTML 4 book doesn’t say anything about title being included in the spec for these form elements— despite the fact that JAWS picks it up fine.
BTW, about the VPAT XML online tool. Details will be available once it’s officially posted, but the version I’ve brewed up is working great right now.
I think the key is that title CAN be used when CANNOT be used. A few issues with using title for form elements:
- Title, by definition in the HTML specs, is for “advisory” information. If title is vital for accessibility, this sure seems like more than “advisory” to me. At a minimum, it seems to go beyond the spirit of the spec. Now you could argue that in your case the table headers provide the accessibility and that the title attribute on the form elements “advises” them of that accessibility in a more readily available way – and I’d be cool with that. What we want to avoid is developers abandoning label and just adding title to every form element.
- There is nothing that defines that assistive technologies should read title text in these instances. The fact that they do is entirely arbitrary and could even be considered to be a mis-implementation of HTML (much like IE’s rendering of alt text as a tooltip in everything before IE8).
While I’m not at all opposed to this technique, it should be used with caution and care.
@Jared. Bingo! This is one of those instances when I feel sadly trapped by the AT vendors as opposed to what the HTML spec recommends. If I did it the other way (using just the table markup) then AT gets all flummoxed with the form. We all need clearer techniques and better implementation!
I like to think of specs and guidelines as constantly evolving to suit the needs of the time, much like natural language.
From that standpoint, what I see is that title has simply grown out of its advisory role and has taken on a new role. The confirmation of that lies in the fact that (as was mentioned) both WCAG 2.0 and most (if not all?) AT recognizes “title” as an acceptable (though arguably less desirable) substitute for label.
For my part, I’m willing to use the title if I can think of no good way to incorporate a label. In so doing, I see myself as helping to force the growth of the HTML specs to allow more flexible and more universal use of “title”