Clarify 'Date Input' error messages

[dashouse]

What

Raised by a user at DWP

On the date-input component (https://design-system.service.gov.uk/components/date-input/#error-messages), the example shown has each field (day, month and year) styled with the red border.

But then there's a similar example on dates (https://design-system.service.gov.uk/patterns/dates/#error-messages) where just one of the fields has the red border. There's another similar example on the error summary page, too: https://design-system.service.gov.uk/components/error-summary/

While we have a good understanding of when to highlight individual fields (for example when a month is a number greater than 12, or we know there cannot be a 31st of February) the example of "date in the future" has an example of just the year being highlighted, and also an example of all 3 inputs being highlighted.

We need to clarify what the example would be in this scenario.

Who needs to be involved in this

Devs, Stephen, Mark

[timpaul]

After a team discussion we agreed that all fields should be highlighted by default. Highlighting single fields only is optional - a single field should only be highlighted if we can be 100% sure that that is where the user needs to fix the error.

[StephenGill]

I've had a go at summarising how we'd want to handle errors in the date input for different scenarios. What do you think @joelanman @christopherthomasdesign?

///

Scenario #1: required day, month or year field is missing
Highlight: missing day, month or year field only
Error message: ‘Date must include a [year]’

Scenario #2: one of day, month or year field is impossible
Highlight: impossible day, month or year field only
Error message: ‘Enter a real [year]’

Scenario #3: more than one of day, month or year field is impossible
Highlight: all date fields (day, month and year)
Error message: ‘Enter a real date’

Scenario #4: date is in the past when it should be in the future, or vice versa
Highlight: all date fields (day, month and year)
Error message: ‘Date must be in the future’ or ‘Date must be in the past’

Scenario #5: date doesn’t meet other requirements (eg it’s inconsistent with another date the user has entered, or the service needs the date to fall within a particular range)
Highlight: all date fields (day, month and year)
Error message: ‘Date must be in the next two weeks’ (for example)

Choosing which error message to show

Highlight one validation problem at a time. If there’s more than one validation problem, show the highest priority one. Priority order is:

• missing information
• impossible information
• invalid information

[timpaul]

I'm not sure we could always confidently say which field has the error? For example if someone enters '31 / 2 / 2020'. It could be the day or the month field that is wrong. In that instance I guess we'd go for Scenario 3?

[joelanman]

yeh thats an interesting one, I agree it fits best in scenario 3, which we could slightly expand to with 'the date as a whole is impossible (for example 31 feb)'

[StephenGill]

Thanks - I've added something covering that.

PR should be ready for approval now: #1155

[terrysimpson99]

Thanks @StephenGill Coincidentally, we recently worked on this so I'm delighted it's being discussed here. Dates are so common and have multiple failure modes. The burden on users with accessible needs is higher than for other users so it's worth the effort to try and be specific with the error message.

Your comment of 7 Feb is almost identical to what we did but we added:

• Your scenario 1 only deals with one missing field. We also deal with two fields missing. Message: 'Date must include a [day] and [month]'
• We trap non-digits (these are a particular problem for month fields - for example people sometimes try to input 'jan'). Message: 'Date must have a [month] that is a number'
• We trap impossible numbers for day and month (year number errors are handled via one of the total date errors). Message: 'Date must have a [day] that is a number between 1 and [31]'
  These are in addition to the other error messages. We also replace 'Date' with [the thing] such as 'Effective date must have ...' but I think that was implicit in what you're saying.

[StephenGill]

Thanks @terrysimpson99 - is there a reason you went for 'Date must have a [month] that is a number' and 'Date must have a [day] that is a number between 1 and [31]'

Rather than - '[Month] must be a number' and '[Day] must be a number between 1 and [31]'

?

[terrysimpson99]

@StephenGill The reason is lost in the paraphrasing that I did. We don't say 'Date...' we actually say 'Effective date...' in the service. For example 'Effective date must have a month that is a number'. This follows the pattern at https://design-system.service.gov.uk/components/date-input/ which says:
"If an incomplete date is entered and you know what is missing
Say ‘[whatever it is] must include a [whatever is missing]’."

I presume the guidance is written so it works the same regardless of how many things/dates are on the page. If there's only one thing/date on the page then it could work. If it can be endorsed for accessibility then I'm fine with either format.