Hint text

[davidhunter08]

Use this issue to discuss hint text in the NHS digital service manual

[sarawilcox]

It would help to explain to content designers why we shouldn't include a full stop in an error message. That's GDS practice and here's the explanation (via Amy Hupe):
"We discussed this a lot. We didn't want to include full stops on the end of error messages that end in examples (for instance, if your error message says "Enter a valid post code like SW1 2AA.") as we thought it could confuse users about the format."
"The same was true for hints and we wanted them to be the same if they appeared next to each other. We also wanted to minimise unnecessary characters where necessary. So we decided to use no full stops by default as consistently as possible."
"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? Etc."

[sarawilcox]

Another comment: Out of interest—did you find this had any #Accessibility implications?

With many of the common #ScreenReaders using punctuation for pauses, did removing them cause any issue with the Screen Reader running into the next sections?

[sarawilcox]

I've just run this error message example through VoiceOver and it runs together these sentences in a way that isn't very clear. It reads them as:
For example, 31 3 1980 error
Date of birth must be in the past day month year

Adding in full stops like this does make it clearer.

[mcheung-nhs]

@sarawilcox - I've tested this with JAWS and NVDA.
With JAWS, the sentences do run in to each other without the full stops. Adding the full stops do cause a separation and makes it clearer.
With NVDA, the sentences do not run in to each other and there is a pause between each line of text with and without full stops.

[sarawilcox]

Full stops in error messages and hint text

I don't think that we can give content designers definitive guidance on when to use full stops in hint text and error messages yet, but I think we can suggest that they bear 2 things in mind.

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.

Test your hint text and error messages on screen readers to check that they do not run into each other if you leave out the full stops, as in the example above (What is your date of birth?). Including a full stop may make it clearer for people who use assistive technology.

[sarawilcox]

A comment on GOV.UK Slack to the effect that it was fine to leave out full stops for sighted users but not for screen readers.

Screen readers will pause after a change, for example from h1 to body content, or from question label to radio button label. So you don't need a full stop at the end of h1 text or at the end of error messages. However, you do need a full stop between 2 sentences of the same thing. In most cases hint text is only one sentence or phrase so the screen reader will pause because it detects the change.

A full stop is potentially unhelpful when the hint text ends with an example because the user may be unable to distinguish between the example itself and punctuation.

So a recommendation that it's better to include a full stop after each piece of hint text except where it ends with an example.

[sarawilcox]

Hi @mcheung-nhs would it be possible to check a couple of other examples, please? Do screen readers pause between each element in a form (e.g. between H1 and body content, between hint text and error message)? That's what someone on GOV.UK Slack told me.

In the example I looked at above, VoiceOver didn't seem to pause between hint text and error message or between error message and text input. But I don't know if that's the same across other screen readers.

A good example to test might be our error messages page: https://service-manual.nhs.uk/design-system/components/error-message where we have headings, hint text, labels, and error messages. Do screen readers pause between the different elements? E.g. between the error summary and elements further down the page.

Looks like JAWS was the more problematic one last time you tested.

Thanks very much.

[sarawilcox]

A comment from DWP in the UK GOV Slack content channel:
"our hint text guidance says use a full stop unless it ends with an example"

[mcheung-nhs]

Hi @sarawilcox, I looked at some further examples with JAWS on the error messages pages as suggested and I get similar results to what was commented on GOV.UK slack you mentioned, i.e. when reading content which are different elements such as moving from headings to list items, then JAWS announces the element type so there is a break between content. However there is no break when moving from a label to a span, a span to another span or a span to a label.

[sarawilcox]

Thanks @mcheung-nhs. Do you think the lack of a break between labels and span is problematic?

I was looking at this code, for example:

<div class="nhsuk-form-group nhsuk-form-group--error">
  <label class="nhsuk-label" for="name">
    Full name
  </label>
  <span class="nhsuk-error-message" id="name-error">
    <span class="nhsuk-u-visually-hidden">Error:</span> Enter your full name
  </span>
  <input class="nhsuk-input nhsuk-input--error" id="name" name="name" type="text" aria-describedby="name-error">
</div>

It presumably reads it as Full name Error, which is misleading. But I don't think we'd want any punctuation after Full name.

We have the colon after "Error" in the span text which may make it read "Error: Enter your full name" nicely.

Do you know if anyone's published any guidance on this?

Someone is suggesting full stops in the span text here: https://stackoverflow.com/questions/15883778/pausing-in-a-screen-reader-for-accessibility. I wonder what you think?

I'll see if anyone on the GOV.UK Slack can help.

[mcheung-nhs]

Hi @sarawilcox

I tested the error message code above and as found previously, with JAWS it doesn't read nicely:

"Full name error colon" - pause - "enter your full name"

I then tested it with the error message in a <div> instead of a <span> to see if that made a difference. It didn't.

I then tested it with the error message in a <p> instead of a <span> and this did make it read better:

"Full name" - slight pause - "error colon enter your full name"

In NVDA all instances read the same.

So this could be a solution in this instance without having to resort to any extra punctuation.

For reference, this is the page I used to test:
https://mcheung-nhs.github.io/accessibility/tests/nhs.uk/form-error-message-elements.html

[sarawilcox]

Thanks @mcheung-nhs. How come we use span rather than p usually? Would it matter if we used p?

[mcheung-nhs]

Hi @sarawilcox - I asked the question in the govuk-design-system slack channel and they have raised an issue to consider changing hints and error messages to paragraphs (alphagov/govuk-frontend#2083) although there are a few considerations, such as how long hints are and if they include multiple paragraphs or list items. I'll look at creating this as a separate issue.

[sarawilcox]

After a meeting with Alistair Duggin and a follow up meeting today, we've decided to test this further, when we do testing of components and headings and inset text, to find out to what extent it causes users problems.

@mcheung-nhs and @davidhunter08 to create a prototype.

[sarawilcox]

One of several issues that needs prototyping and testing.

[sarawilcox]

Some recent thinking from GOV.UK Slack: "If the hint text is a sentence, full stop it.
If it's for a date, such as "For example 18 06 1981" or the postcode one, don't use a full stop"

"No for short statements. Yes for multiple sentences."

[sarawilcox]

The GOV.UK design system has been updated to say: "Keep each hint to a single short sentence, without any full stops."

We've got a task in the backlog to consider the GOV.UK guidance and conversations on cross-gov Slack and to update our guidance, if appropriate.