govuk-design-system-backlog
govuk-design-system-backlog copied to clipboard
alphagov
Dates
Also known as: 'Ask users for dates'
Use this issue to discuss this pattern in the GOV.UK Design System.
Anything else
- Related to the 'date picker' component issue
- Read the draft guidance on 'date picker' component in Google Docs
- Download the code for 'date picker' from GitHub
- Related to the 'date input' component issue
- Read the draft guidance in Dropbox paper on Calendar control
For the "Year" field should users be able to enter "80" if they were born in "1980" or should there be a minimum length of 4 characters imposed?
The GOV.UK Design System does not currently contain any specific guidance about the formatting of years as numbers. The GOV.UK Styleguide does not specifically mention it either but as it only includes examples in the 4 character format so, it would appear safer to do that.
If you have a specific use case where you think there is a clear advantage for collecting years as two digit numbers please add it here as it could definitely be something to include in our guidance.
It's a good question. As Hanna says we don't currently have published guidance on using 2 digits.
Personally I think it'd be nice to support users who enter 2 digits if it's unambiguous. However I guess there's always the chance that for example if someone enters 30 in year and meant to put it in month. Requiring 4 digits would avoid that.
I agree with @hannalaakso that it is safer but it is clearer too. There are situations where ‘80’ could mean ‘1980’ or ‘1880’.
What about use of two digit format in case of days / months ? https://design-system.service.gov.uk/patterns/dates/ suggests that there should be a single digit in situations where two-digit would have 0 at the beginning. (ie. 03 07 1999)
@adrianbiskupski The pattern is flexible so 03 07 1999 and 3 7 1999 should both be accepted. But you should not force leading zero on days and months between 1 and 9.
The leading zeroes are not needed. Like @joelanman said not adding them is "ever so slightly quicker, and more natural - dates in the real world, calendars etc, don't tend to have leading zeroes. It's a 'computery' pattern and we try and stay away from those."
It was incredibly common for people to enter two digit years when I tested passports - even with the hint text. This might be related to passports showing a 2 digit year on the document - though most users will of course know their date of birth.
It was common enough I specified that we should accept two digit years - but I think I only allowed it where we thought it was unambiguous. For dates of birth of living people it's easier than years in general - no people born in 1880 are renewing their passport now.
If we hadn't done this, I think we'd have seen at least 50% of people on the page fail validation. It's not a major fail, but one we were able to avoid.
For many services if you're collecting a date in recent years, you can pretty unambiguously cast it to 4 digit year. - but this would be something the service would have to think about it. I don't think we'd want to do it by default.
I wonder if anyone has looked at how we might offer commonly set dates. I'm currently pondering something like this:
When this pattern was in GOV.UK Elements, it had a note to explain the invalid HTML this pattern uses. It would be good to also have it in the Design System as the question about it keeps on coming up:
Note: The
patternattribute is not valid HTML for inputs where thetypeattribute isnumber. It is added deliberately to force numeric keypads on iOS devices.
@selfthinker To double check, the latest HTML 5.1 spec still lists pattern as an attribute that must not be specified on number fields (just in case the spec was changed).
https://www.w3.org/TR/html51/sec-forms.html#ref-for-element-attrdef-input-pattern-16
Would definitely be good to add a note that we're non-standard here for a reason.
Just a small point that the example given for Date of Birth contradicts the autocomplete information that is given below it.
@amyhupe I haven't delved to far into autocomplete before but my instinct tells me that it works on the name attribute of the input field. In the example code given for Date of Birth https://design-system.service.gov.uk/patterns/dates#asking-for-memorable-dates, the input fields are given the prefix dob, whilst in the section below that states autocomplete should be used for Date of Birth the fields are prefixed with bday https://design-system.service.gov.uk/patterns/dates#use-the-autocomplete-attribute-when-asking-for-a-date-of-birth
It might be a small point but just something I spotted.
Hi @ChazUK — thanks for explaining.
Just to clarify, the dob prefixes are used on the id and name attributes, which aren't part of the autocomplete functionality.
The autocomplete attribute uses the bday prefix as the guidance specifies. I hope that makes sense but please let me know if not.
Thanks
Are there any prior examples of how people are capturing fuzzy dates? In the Design System docs it says
For example, allow users to enter ‘December 2017’ for a field that says ‘the date you lost your passport’.
I assume people aren't following this to the letter and offering a text field then having to deal with the aftermath. After a request from one of our DfE teams we've opted to use the regular date pattern but omit the day, like this. It seems like a sensible approach, would be nice to see if there are others too.
We do exactly what you suggest: use the normal pattern without the day number. It's simple but isn't a solution in all cases:
-
Users who know the exact date sometimes put the day number in the first field.
-
A reduction in precision isn't the same as a reduction in accuracy. Users still want to let us know that dates aren't necessarily accurate.
@peteryates GOV.UK uses 'fuzzy dates' on some of the finders (example here)
On my service I added a details link to expand a more fuzzy date:
So far it's been through one round. We didn't test it explicitly, but I think most / all participants mentioned it and seemed clear on the purpose.
One thing that's not stated, is that I feel services should know that the date they've been given is approximate. I recall a service from a few years ago that whilst it asked for the approx date, stored an exact date as a result, and then kicked off all sorts of legal things about that specific date that the user didn't even choose.
There's a number of discussions here about what we allow users to enter, but I'm wondering about how we should play back dates a user has previously input or selected.
(1) a user enters the date 1st Jan 2000 as '01' in the day field, '01' in the month field and '2000' in the year field. On a subsequent CYA page, should we play that back to the user exactly as they input it (e.g. 'Date of payment: 01/01/2000'), or strip out the zeroes (e.g. 'Date of payment: 1/1/2000')? The latter obviously looks better, but it isn't what the user literally entered and date guidance seems to suggest we shouldn't assume what the user means when it comes to entering dates.
(2) if a CYA page has a mix of date styles - for example, one line on the CYA page replays the date as '1/1/2000' and another line replays a quarter date chosen by radio button as '1 Jan to 31 Mar 2019' - do we accept this as is or should we be looking rejig the dates to a matching format e.g. change the '1/1/2000 to '1 Jan 2000' so it matched the '31 Mar 2019' format?
@jonathaninch I'd suggest when displaying date you use the gov.uk house style for dates.
So in this case it would be 1 January 2000. This is also good as it would help users spot if they've transposed days and months.
I've been working on a service that has been testing with screen reader users. We discovered that users who skipped the hint text got confused as to how to enter the date.
"Do I type it as letters or numbers, like 'January' or 'JAN' or '01', 'Monday' or '06'?"
Did not see these issues with the user when they did not skip the hint, that includes an example. To help users that skipped the hint we have added a visually hidden content of " in numbers" to the labels.
<label class="govuk-label govuk-date-input__label" for="passport-issued-day">
Day<span class="govuk-visually-hidden"> in numbers</span>
</label>
Currently still testing.
@R-Derby can you check whether the hint text is associated correctly with the fieldset using aria-describedby? If that relationship is set up correctly the hint text should be read by the screen reader when the first date field is focused.
@36degrees Thanks I've feed that backs the development team. The user behaviour we had seen was to tab manually very quickly. In some cases even before the H1 would end.
Still testing
I tried with voiceover on Safari yesterday with an example from the design system and saw the same - when tabbing on to the first checkbox, only the hint of the item is read out, not the hint of the fieldset.
@edwardhorsford for the date component there shouldn't be any hints associated with the individual inputs, so I'd expect the fieldset hint to be read out as normal.
@edwardhorsford for the date component there shouldn't be any hints associated with the individual inputs, so I'd expect the fieldset hint to be read out as normal.
Sorry @36degrees I think I got confused by a different bug report. Ignore me.
For 'send documents for a customs check' we wanted to have hint text where example day was >13 and month <9, but we also wanted to show an example date that would not cause an error if entered - so the date would need to be in the past, and ideally be very recent (within the last month).
We have settled on showing the 23rd of the previous month as the example, and for months when the previous month contains 2 digits, showing the 23rd September (23 9 2020).
We're developing a service for HMRC and asking some users to enter a date that they have to copy and paste from a different system.
We've been having feedback from users that it would be quicker if the cursor moved to the next box once it had been filled.
@jeanesims are you thinking of testing that on your service? Would be good to get more research on this, including lower confidence users, and disabled users. Would be interesting to know if it increases error rates too
If your users have to copy the date in from a different system, I would say that constitutes a specific user need and therefore good grounds for just using a textbox that can accept the format of the other system.
