Multiple form labels and screen readers
Just about every website needs some forms. Sometimes there are many of them, sometimes just a single contact form. Regardless of their number, they need to be usable and accessible, which can sometimes be a little more work than it would be if theory and practice aligned a little better.
Say you have a simple form with an input field whose value needs to be validated, either by a JavaScript running in the browser or by a script on the server (preferably both). When the data entered by the user does not match what is expected, you need to notify the user somehow.
For sighted users this is generally not a problem. If you output some text stating what the problem is and highlight it visually, most people will notice it. For screen reader users it’s a little more tricky though.
To make sure that the screen reader associates the message with the correct input field, the text should be in a label element that is explicitly connected to the field. No problem so far actually, but then the designer tells you that it has to look differently. The validation message should be below the input field instead of next to the label text. Or it should be next to the input field, or some other location not directly adjacent to the label text.
You start fiddling with extra markup, absolute positioning, negative margins, and end up with something that seems to work reasonably well. Until you resize the text, at which point things get misaligned.
You may be able to find a half-good solution that works within certain constraints, but if you’ve been down this road you probably get the point. Positioning error messages this way is fragile. It would be so much easier if you could just put the error message in a second label element associated with the input field.
Well, it turns out you can do that. From The LABEL element in the HTML 4.01 specification:
The LABEL element may be used to attach information to controls. Each LABEL element is associated with exactly one form control.
The for attribute associates a label with another control explicitly: the value of the for attribute must be the same as the value of the id attribute of the associated control element. More than one LABEL may be associated with the same control by creating multiple references via the for attribute.
Sounds great, doesn’t it? A quick check in graphical web browsers shows that they associate multiple labels with the input field (as evidenced by the input field gaining focus when either label is clicked). But what about screen readers? It would be so useful if this would work…
Unfortunately, and perhaps unsurprisingly, it looks like it doesn’t quite work as well as you’d hope. I mentioned this briefly in Use the label element to make your HTML forms accessible, but I think it’s worth bringing up again since full support for multiple labels would help us make forms more accessible to screen reader users while keeping visual designers happy.
I am far from an expert user when it comes to screen readers, but I’ve done some limited testing with mostly disappointing results.
- Apple VoiceOver does not recognise more than one label element associated with a form control and reads only the label that comes first in the document’s source order.
- JAWS and Window-Eyes both do the opposite and read only the last label when an input field gains focus.
- The only screen reader of those that I tested that does handle multiple labels is Fire Vox.
The exact results may obviously depend on user configuration and reading modes, and there may be other screen readers that get it right, but these results indicate that screen reader behaviour is too inconsistent for multiple labels to be a reliable technique.
A couple of years ago, Bob Easton set up a multiple label test case that reveals similar results, discussed in Speaking form labels - Summary.
Sorry to write at such length about something that appears to have no practical use. I just wanted to highlight a case where I think screen readers following the HTML specification more closely would help web developers to increase the accessibility of HTML forms they don’t have full visual control of.