Last month’s column, ‘Colons at the end of labels?’, attracted a small storm of correspondence – well, it certainly felt like a storm for a topic that I thought was obscure even in the world of the forms geek. And the points made were excellent because they all pointed out that I’d completely ignored the issues of screen-readers. Doh!
The original problem
You are writing captions or labels for fields in forms, for example “Name” or “Date of birth”. Should they be finished with a colon, or not?
My previous answer
Previously, I said that as I’d never seen any user bothered by the colon/lack of colon – it didn’t matter. And my advice was to pick one and stick with it.
The new problem
Rumour has it that screen-readers ARE bothered by the presence or absence of the colon. For example, Tom Haggie drew my attention to a software checklist at http://www.usdoj.gov/crt/508/archive/oldsoftware.html. It includes the question:
‘Are all descriptions or labels for fields positioned immediately to the left or directly above the control, and do they end in a colon, so that it is easy for screen reading software to associate the labels with the corresponding fields?’
My investigation so far
Now, I thought that the crucial thing for screen-readers was to be sure to use the ‘Label’ attribute so that the label is correctly associated with the input box or other widget that it corresponds to. I didn’t think that colons made a lot of difference.
For example, WebAIM’s article mentions ‘associating form elements with a text label by using the label element’ (amongst other good advice) – but it is silent on the topic of colons.
Jim Thatcher’s article mentions the label attribute, and also placing the label close to the corresponding box. But says nothing about colons.
So I contacted Ginny Redish (www.redish.net) who has done a lot of usability testing with blind and partially sighted people. Many of them use JAWS, the most popular screen-reader in the USA. She replied:
“I have watched people using a screen-reader on forms, but I do not recall whether the forms had colons on the screen or what the tags for the fields said.” (Same experience as mine.)
She went on to explain that when working through forms, users prefer to remain in the ‘edit’ mode of the screen-reader, where it interprets key presses as entries for the field and moves from field to field according to whatever it finds tagged as labels. The crucial point, therefore, is the tagging – as mentioned in the other articles. Whether or not you include a colon in the tag will not make any difference.
With her usual keen eye for language, she also pointed out that the checklist sentence above is ambiguous. The clause ‘and do they end in a colon’ could be interpreted as part of making it easy for the screen-reading software – or it could be a separate requirement that happens to have been stuck into the sentence at this point.
And finally, she pointed out that you can choose whether or not to get JAWS to read out the punctuation. So if the colon helps the screen-reader, that’s good – but it may be invisible to the users.
My request to you
And that’s as far as I got. I know I’m still trying to find out if other screen-readers rely on colons at the end of labels. If you know the answer, please get in touch.
Meanwhile, I stand by my previous advice: make a decision for or against colons, then stick with that decision forever.
(P.S. If you’re interested in how blind and partially sighted people use the web, you should be sure to read Ginny’s excellent articles on the topic. Details of how to get them are at: http://www.redish.net.
I’d like to thank Ginny Redish, Tom Haggie and Calum Benson for their help. Any errors are mine.
This article first appeared in Usability News, 4 June 2006
image: Falling in love with forms by Jeffrey Zeldman, creative commons licence
#forms #formsthatwork