Hint text: Collate and review existing research #251
Labels
🔗 component
Reusable parts of the user interface that have been made to support a variety of applications.
⏱ days
A few unknowns, but we roughly know what’s involved.
hint text
Existing practice on full stops
<p>
tags rather thandiv
tags for hint textShould we use full stops in hint text? The options are:
Always use full stops
One argument for this is based on screen reader behaviour. It is suggested that JAWS in particular needs a full stop to know that it needs to pause after the hint text. This seems to be a particular problem if there is also a validation error being displayed.
Counterpoint: there seems to be evidence on the other side too, that screen readers can actually handle this OK as long as the hint text is part of a separate HTML element. Some guidelines recommend omitting full stops but always testing with screen readers.
There is an ongoing discussion about whether to make hint text a
<p>
tag which will apparently help this, but for now in GOV.UK frontend it will be a<div>
tag.Another argument for always using full stops is that it works better where hint text contains more than one sentence. It's clear that the first sentence should end in a full stop, but if the second one doesn't, does the inconsistency cause problems or friction for users?
Counterpoint: hint text should never be long enough that it needs two sentences. If you need to write two sentences, you're not writing hint text any more.
We could restrict the use of hint text to helping people avoid validation errors in a particular field. If you need to explain more about a question, for example where to find information or what the question means, then you either need to use body text or rethink the question. In practice, though, designers won't always be able to do this.
Some guidance that argues for full stops (including Universal Credit) makes an exception where the hint text ends with an example: this is based on reported (though not very well documented) user behaviour of including the full stop when entering data into the field, and thereby triggering validation errors.
"Enter a postcode in the correct format, for example SW1A 1AA."
The NHS guidance says this problem has been observed but without giving more detail. In contrast, HMRC reports user research where the lack of a full stop was distracting and drew users' attention because it looked like a mistake.
Never use full stops
The main argument for this is stylistic consistency with error messages and other text that might generally be called "UI copy". This is seen in guidelines from Microsoft and the Office for National Statistics, among others.
NHS quotes Amy Hupe https://twitter.com/Amy_Hupe/status/1238418276490915841 on why error messages don't have full stops (nhsuk/nhsuk-service-manual-community-backlog#17):
"Needless to say, this approach isn’t perfect. For example, if you have a 2 sentence hint, it’s tricky: should you include a stop on the end of the second sentence or not? Or if the hint or error contains a question mark, what then?"
The main focus of this discussion is whether validation errors should have full stops: hint text is only involved because the preference is for hint text and validation errors to be consistent with one another. If we don't mind about that, then perhaps we don't have to do the same thing in errors and hint text.
Use full stops except with example formats
The systems that recommend this all seem to have "use full stops" as the default, with special cases where you should omit them. I couldn't find any examples of the opposite position. Systems that recommend leaving them out don't seem to acknowledge special cases where they should be included.
Draft guidance for NHS content guidelines reads:
"If you're using hint text or error messages to tell users how to enter information in a text input box, with an example, and there is a chance that users will copy the full stop and this will cause validation errors, do not end your sentence with a full stop. Example: "Enter a valid post code like SW1 2AA" with no full stop.
This is also the position we take in the Universal Credit guidance:
"Use correct grammar and punctuation, including full stops. The exception is for examples of formats (like the date format.) These should use this pattern:
For example, [give example]
No full stop."
The text was updated successfully, but these errors were encountered: