Update date input to recommend accepting month names

[frankieroberto]

Back in May 2022, we discovered that hundreds of users were inputting months using full or abbreviated month names in the ‘Apply for teacher training’ service – see full table of inputs.

We made a change to accept these as valid months which dramatically reduced the number of errors. This change was also later made in another service, ‘Find a lost TRN’.

Given this data and the comments in the backlog thread about people with dyscalculia finding it harder to convert month names into numbers (although possibly most users need at least a second or so to think about this?), it feels like it’s worth adding to the general guidance?

One unresolved open question is about whether this should be advertised, or just be a hidden feature? Arguably the hint text could say something like "For example, 31 8 2005 or 31 aug 2005" to make it clear that both forms are accepted (and avoid people having to do the conversion in their head unnecessarily) but perhaps this just adds confusion?

[netlify]

✅ You can preview this change here:

Built without sensitive environment variables

Name	Link
🔨 Latest commit	cc2c5f5
🔍 Latest deploy log	https://app.netlify.com/sites/govuk-design-system-preview/deploys/64d9f7a27cb5740008d77d3a
😎 Deploy Preview	https://deploy-preview-2889--govuk-design-system-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[stevenjmesser]

One unresolved open question is about whether this should be advertised, or just be a hidden feature? Arguably the hint text could say something like "For example, 31 8 2005 or 31 aug 2005" to make it clear that both forms are accepted (and avoid people having to do the conversion in their head unnecessarily) but perhaps this just adds confusion?

Mmm, how would you explore that? If you wanted to get that validated, what are some potential options?

And as a counterpoint, would a change to the hint text (without validating the need for it) create any irreversible problems? Perhaps it's small enough change with such minimal risk that it's one worth making anyway.

Be good to get your thoughts on those questions, but given that the changes proposed so far were in response to behaviour observed through error rates, and the changes have reduced the number of errors, I think it's safe to say that it helps users complete their task and is more applicable to their real interactions with the component.

I'm going to see what others think but do let us know your thoughts on those questions.

[querkmachine]

I'm a little concerned this is an area where we might need to provide more in-depth guidance in its own section, rather than only saying that month names should be allowed.

Some possible questions I can see arising being:

1. Does the month field need to be made wider if you accept month names?
2. What level of abbreviation should be used? ('Ju' could be June or July, 'Ja' is probably January but could be a typo of 'Ma' for May, and 'Febr' is almost definitely meant to be February. Should only three letter abbreviations be allowed?)
3. What data validation needs to take place? Do we need new error messages for unrecognised text?
4. How should dates be formatted on the checking answers screen or if the user returns to the page later?
5. Do services localised into other languages, like Welsh, need to support month names and abbreviations in those languages? Do any of the above need amending to account for localisation?

[frankieroberto]

One unresolved open question is about whether this should be advertised, or just be a hidden feature? Arguably the hint text could say something like "For example, 31 8 2005 or 31 aug 2005" to make it clear that both forms are accepted (and avoid people having to do the conversion in their head unnecessarily) but perhaps this just adds confusion?

Mmm, how would you explore that? If you wanted to get that validated, what are some potential options?

And as a counterpoint, would a change to the hint text (without validating the need for it) create any irreversible problems? Perhaps it's small enough change with such minimal risk that it's one worth making anyway.

Yeah, I'm not sure how you’d validate it either way to be honest. I guess you’d have to do some dedicated user testing, including some users with dyscalculia, low numeracy or related issues?

For the DfE services, we decided not to change the hint text, and just leave the acceptance of month names as an un-advertised feature.

[frankieroberto]

@querkmachine all good questions, thanks! 🙌

I'm a little concerned this is an area where we might need to provide more in-depth guidance in its own section, rather than only saying that month names should be allowed.

Maybe!

Some possible questions I can see arising being:

1. Does the month field need to be made wider if you accept month names?

Good question. I think this would encourage more people to use month names - but hard to know if that's a good thing or not? On the downside, it's more keys to hit on your keyboard, but on the upside, for some people it may well be easier than converting months to numbers in their head.

2. What level of abbreviation should be used? ('Ju' could be June or July, 'Ja' is probably January but could be a typo of 'Ma' for May, and 'Febr' is almost definitely meant to be February. Should only three letter abbreviations be allowed?)

I think for the 2 DfE services that have adopted this, only the 3 letter abbreviation and the full month names are accepted. Case insensitive.

3. What data validation needs to take place? Do we need new error messages for unrecognised text?

I had a quick look at the existing error messages listed on the page, and I think they all stand, with no need for any changes (eg "Date of birth must include a month" doesn’t mention numbers vs words).

Happy to get a second opinion on this though!

4. How should dates be formatted on the checking answers screen or if the user returns to the page later?

If the user returns to the page (eg to edit it), I think the month would have to be displayed as a number, regardless of how it was entered - as it’s unlikely that you'd store the date different depending on how the month was specified.

This would also be consistent with existing behaviour which would be to strip any leading zeros from the day or month if you came back to the screen (even if you entered the day or month with a leading zero).

On the check your answer page though, I think there would be a good argument for always showing the month name in full, following the GOV.UK style guide for displaying dates. The current page doesn’t specify this either way, so I imagine different services do different things?

(I just checked and the service I’m currently working on displays the date using the full month name on the Check your answers page. The service doesn’t yet accept months as names or abbreviations.)

5. Do services localised into other languages, like Welsh, need to support month names and abbreviations in those languages? Do any of the above need amending to account for localisation?

Good question - but given the design system website doesn’t currently include any guidance (error messages, etc) on Welsh or other languages, is this out of scope for now?

[dav-idc]

Hopping in to note that this seems related to an accessibility usability concern that was flagged for us back in February, based on the results from a service's audit.

• Potential accessibility issue with date field pattern  govuk-frontend#3240

[cjforms]

@frankieroberto The current draft says
"You should accept month names written out in full or abbreviated form (for example, ‘january’ or ‘jan’) as some users may enter months in this way."

Please change this to:
"Accept month names written out in full or abbreviated form (for example, ‘january’ or ‘jan’) as some users may enter months in this way."

because:

• it's clear
• it's shorter
• it removes the ambiguity of 'should', which can be interpreted as 'must' or 'may'

[frankieroberto]

@cjforms thanks Caroline! I like that change, and I’ve committed it in 86b0b22.

Over to the Design System team to consider this now I think!

[joelanman]

Just to say I'm in favour of the change in guidance, that month names be accepted with no change to the visual interface. It fits with our validation guidance that you should only error on 'information that’s too ambiguous for you to use' - a month name is not ambiguous input.

https://design-system.service.gov.uk/patterns/validation/

[stevenjmesser]

Suggested a few changes to make before we accept it, @frankieroberto, but it's looking good!