Offer a DD-MM-YY date field input feature and documentation

[Jane24]

Feature Request - Add Date field example

Would be great for the UI kit to include an example of how to capture a date in our forms. GOV.UK has an example that we could use.
We want to note that there is no auto-tab between fields.
http://govuk-elements.herokuapp.com/form-elements/example-date/

[klepas]

Hi there @Jane24. (:

There has been a recent exemplar that implemented a _birth_date capture field. We intend to take this pattern and provide it within UI-Kit. This will be another few sprints off, as we’re currently swarming on releasing a new version of our guidance/documentation (the design guide).

From what I recall there were another few exemplars earlier in the year, prior to the existence of UI-Kit, that implemented a variety of other date entry/selection patterns. Off the back of my head, these included selecting a calendar date in the future and to selecting a day and timeslot for an appointment — there might also be others that have user testing behind them for us to pull from.

We want to note that there is no auto-tab between fields.

Could you elaborate on this? (:

Thanks for raising this issue.

---

Related issues

• Incorporate humanised date helpers #390
• Form input type[url] type[date] doesn't receive styles #381
• Feature Request - Calendars #30

[Jane24]

Hi there
Thanks for the response.
We're mostly capturing DOB and Expiry dates (of identity documents).

Regarding the auto-tab: we currently use set of 3 fields to capture the dates, as in the GOV UK example. Auto tabbing works if the user enters 2 numbers for the Date and Month fields - the field focus automatically moves to the next field in the set of 3. But users won't necessarily enter 09, for example, and shouldn't need to. If there's a mix of auto tab and manual tab it's confusing for users. Prob better to just drop the auto tab for this set of fields.

Is that how it's been implemented for the exemplar?
Jane

[klepas]

Regarding the auto-tab: we currently use set of 3 fields to capture the dates, as in the GOV UK example. Auto tabbing works if the user enters 2 numbers for the Date and Month fields - the field focus automatically moves to the next field in the set of 3. But users won't necessarily enter 09, for example, and shouldn't need to. If there's a mix of auto tab and manual tab it's confusing for users. Prob better to just drop the auto tab for this set of fields.

Ah, gotcha — of course! Thanks for elaborating.

Is that how it's been implemented for the exemplar?

In the recent exemplar (which was in alpha, and a low-fidelity prototype), I don’t believe there was any Javascript implementation that would auto-tab when 2 numbers we entered, but when we add this as a form pattern in UI-Kit we very much should also provide this functionality.

[Jane24]

Dates are about the only field that I'd consider auto-tabbing for. Just found a reasonable solution.
Only auto-tab after all spaces are used in the field, but only if it's validated.

Example:
Month, inserted 04, (...)saved and jumps to next field

Month, inserted 13, (outside possible range), background turns red, and will not jump to next field.

Month, inserted 4, will not jump because does not fill the input (2 digits). User has to tab themselves.

[klepas]

nod

My only concern in tabbing is an accessibility concern — I need to do some testing to ensure that any JS-powered auto-tabbing and focus to the next input field (from DD to MM to YY; stop) also hits the label for that next field; otherwise, eg. a non-sighted user using a screen reader will hear something like “day [the label], empty text field [the input]” — they enter say ’02’ — and suddenly they hear “empty text field”, because the tabbing would skip the next label (in this case “Month”).

[Jane24]

Yes, You're right. I'd go back to my initial comment that there should be no auto tabbing between fields.

[klepas]

@Jane24

Thanks again for opening this. I think adding the auto-tabbing would be a rather nice feature, if we can ensure we don’t screw over screen readers.

I’m not sure when we will get the chance to get onto this, but it’s definitely in our backlog now.

Edit: I also renamed the issue — let me know if it’s not representative of what you meant? :)

[Chris820]

A lurker adding in thoughts regarding A11y:

Moving a users focus is considered to be a change of context. And shouldn't be done when:

1. something receives focus (3.2.1, Level-A)
2. the setting of a UI component is changed (3.2.2, Level-A). Unless notifying the user of this beforehand.

The described setting of d-m-Y values in seperate date fields would be an example of 2. So it should be okay to do provided there's some words telling users that it's going to happen before the fields (and if you don't mind sacrificing the design to include these words).

This relates to the G13 technique on the WCAG website, for further thrilling reading.

[klepas]

Thanks @Chris820 — spot on.