Colons at the end of labels – revisited

In 2006, I wrote twice about colons on the end of labels on forms. This is the second of those posts. I’ve updated it in 2025 to reflect on how the topic has changed in the past 19 years.

A colon and a question markIn May 2006, I wrote about Colons at the end of labels?, meaning the labels that we place on forms that serve as the question.

That post 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 is whether to put a colon after a label

You are writing captions or labels for fields in forms, for example “Name” or “Date of birth”. Is it important to add a colon after each label, or not?

For example, let’s suppose that your form includes a question about the name of an event. In the GOV.UK Design system in 2025, this exact question is one of their examples for the ‘text input’ component. You’ll notice that in this example, they write out the full question “What is the name of the event?” and finish that question with the “?” which is conventional for punctuation in English.

What is the name of the event? (with a box to type into)
Label as a full question – Example from the GOV.UK design system ‘Text input’ component

But sometimes, we need to ask a series of questions about a topic. It might seem repetitive to put an entire fully-formed question as the label for each of those questions, so we might consider an abbreviated label. I’m sticking to the same topic here, and our abbreviated label will be “Name of the event:” or “Name of the event”. In case you don’t immediately spot the difference, the first one has a colon and the second one does not.
Name of the event: (with a box to type into)
Name of the event (with a box to type into)

My advice is that people do not care about colons in labels

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.

Correspondents told me that screen readers do care

It seems that, back in 2006, screen-readers were bothered by the presence or absence of the colon. For example, Tom Haggie drew my attention to an accessibility checklist that included 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?’

Software accessibility checklist first published in the US Department of Justice website in 2001  (now links to the Web Archive)

The ‘label’ attribute mattered more than the colon

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 was silent on the topic of colons, and continues to be in 2025.

Jim Thatcher’s article mentions the label attribute, and also placing the label close to the corresponding box. But said nothing about colons in 2006, and hasn’t added anything since then.

So I contacted Ginny Redish who has done a lot of usability testing with blind and partially sighted people. Many of them used JAWS, the most popular screen-reader in the USA in the early 2000s. 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.”

Ginny Redish

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 advice from the 2001 Software accessibility checklist (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 people who use JAWS the screen-reader get it to read out the punctuation. So if the colon helps the screen-reader, that’s good – but it may be invisible to the users.

In 2025, nobody needs colons on labels

Fast forward through a couple of decades of iteration on the web in the world of screen-readers, and I’m glad to say that screen-readers no longer rely on a colon in a label. (It’s possible that they never did).

Since writing my original blog post, I have watched hundreds of people fill in forms. Never once has anyone complained to be about the presence or absence of a colon in a form label.

If your label is a fully-formed question such as “What is the name of the event?”, then add a question mark to it in the usual way.

If your label is a shorter prompt, such as “Name of the event”, then do not add any punctuation to it.

Test your form by asking someone to fill it in while you watch – ideally, someone who might have to complete it in real life.

I’d like to thank Ginny Redish, Tom Haggie and Calum Benson for their help. Any errors  are mine.

A version of this article first appeared in Usability News, 4 June 2006

#forms #formsthatwork