Dates

[jrbarnes9]

Use this place to discuss the dates pattern in the ONS Design System

[jrbarnes9]

#194 resolved

[jrbarnes9]

#206 resolved

[jrbarnes9]

#517 resolved

[jrbarnes9]

#550 resolved

[jrbarnes9]

#672 resolved

[jrbarnes9]

We could do with independent field error styling for the date component so error messages can be specific to the invalid field

[jrbarnes9]

#1573 raised

[jrbarnes9]

Raised #1896

[Al-Davies]

#UR Findings
tested as part of health monitoring survey - usability testing 6-12 December 2022 (testing involved multiple instances where participants had to enter dates for samples and symptom dates). No guidance was given within the survey on how to enter the dates

• All 5 participants entered dates in full i.e. 12.12.2022
• Where error messages were displayed (i.e. warning to enter dates after a specific period) participants understood warning messages and corrected dates accordingly
• When questioned about why they had entered 2022 rather than 22, participants said that the box sizes to enter the year was larger than those for the date and month, therefore leading them to assume they needed to enter a 4 digit year.

FULL DATE

• often users expect to autotab from date to month when completing date entries
• "ah, so this doesn’t move over when I've done the date" "I prefer it if it just moves to the next box"
• "some sites automatically jump to the next field, some don't, but automatic is my preference"

MONTH/YEAR ONLY

• this pattern has been successfully used for Census EQ - where users are asked for date of entry to the UK - where they are only asked for month and year. Many participants remember the year, but may be less sure about the month. Asking for date would likely lead to high inaccuracy.

[mr-nick17]

This component contains invalid html and is therefore breaking web standards. The min and max attributes are not valid on input type of text and considering that browser validation is recommended to be turned off there's little value in having them. Self closing tags are also invalid /> and should be removed.

[daniellecorke]

Hi Nick, thank you for your feedback. I have raised #3098 to look into this.

[daniellecorke]

Update: Thanks for highlighting this issue for us Nick.

We have completed #3160 to remove min and max HTML attributes for inputs with type set to "text". This will be available in our next release. We didn't find invalid html for the self-closing tags and we will now close #3098.

Please let us know if you have any further feedback.

[mr-nick17]

Thanks for the update. I would encourage as part of your investigation, and developer good practise, that the html output is run through a validator e.g. https://validator.w3.org/nu/#textarea. Doing so would have highlighted the min max on the incorrect input type much earlier in the development cycle. With regards to self-closing tags, although technically the html is valid, it is not good practise, by checking the 'date' output (and ignoring the upcoming fix for min/max) this info is supplied with regards to void elements

Info: Trailing slash on void elements has no effect and interacts badly with unquoted attribute values.

[daniellecorke]

Thanks for this input Nick, I'll pass it on to the team.