Embargo date input differs from displayed output

[mietcls]

UX crash

Embargo date input differs from displayed output. Make it the same one everywhere.

EDIT: there are a lot of "solutions" out there for date pickers, but the non-native offer is not on par with accessibility standards, and writing the solution ourselves would take us even further away. We decided to align all output to YYYY-MM-DD and let the native date picker element handle the input side, which will format the date according to the browser.

---

Solution: we align the input field with the convention we have in the library world: YYYY-MM-DD.

Context

Human error

When you input a date for embargo, it is formatted as DD/MM/YYYY. When it is displayed in the detail pages or search pages, it is formatted as YYYY-MM-DD – which causes confusion and makes the interface prone to error for researchers and reviewers (while correcting). The quality of our data might suffer from it.

Technical background

We use a browser default date picker, which does not offer the option to customise the input.

"The displayed date format will differ from the actual value — the displayed date is formatted based on the locale of the user’s browser, but the parsed value is always formatted yyyy-mm-dd."

More information: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date

Screenshots

Output (as expected)

Input (deviation)

Expected behaviour

[nicolasfranck]

The date input is shown in a format as chosen by the browser locale, which is in this case "dd/mm/yyyy". For America that is mm/dd/yyyy for example.

Having an input date controls the input. Apparently I see no formatting option in the html specification, so we have to resort to the current browser settings.

We can always show the interpretation next to the value in the display? It is recommended anyway as there are different conventions in use in browsers.

Anyway, it will always be confusing if the format of the stored value is different from the user's convention.

[mietcls]

Thank you for taking a look!

The date input is shown in a format as chosen by the browser locale, which is in this case "dd/mm/yyyy". For America that is mm/dd/yyyy for example. Having an input date controls the input. Apparently I see no formatting option in the html specification, so we have to resort to the current browser settings.

Yes, as mentioned in the issue: "The displayed date format will differ from the actual value — the displayed date is formatted based on the locale of the user’s browser, but the parsed value is always formatted yyyy-mm-dd."

We can always show the interpretation next to the value in the display?

This will clutter the interface and probably make things more confusing. There are ways to manipulate the display of the date via JavaScript, or we can use a date picker.

It is recommended anyway as there are different conventions in use in browsers. Anyway, it will always be confusing if the format of the stored value is different from the user's convention.

In the context of metadata and consistency in the way we've noted down dates in the past years, we cannot rely on the recommended conventions throughout the internet, it is not the convention for us in the library.

So the options I see:

• or we have to make sure everyone sees the output as set by their browser (only the display, we do not touch the way we parse the data). However this will make it confusing to offer support at the help desk.
• or we make sure we align the input field with the convention we have in the library world: YYYY-MM-DD. This one seems the more logic one, and makes sure everything is consistent.

I am looking for a practical solution – if there are others, let me know!

[netsensei]

or we make sure we align the input field with the convention we have in the library world: YYYY-MM-DD. This one seems the more logic one, and makes sure everything is consistent.

Since the HTML specification doesn't offer direct control over the formatting of the input via a dedicated attribute, we most likely will need to resort to a JavaScript plugin which implements a data picker, instead of relying on the one provided by the browser:

https://flatpickr.js.org/ is a good alternative.

[verheyenkoen]

This can be done without a library with some custom JS and CSS while still using the built-in datepicker, like so: https://jsfiddle.net/verheyenkoen/sa39hgbL/8/

[mietcls]

@verheyenkoen thank you for exploring this, good suggestion. Do you know what the impact is of this change on accessibility (screen readers etc)? Using the native browser options usually "fixes" this problem.

Context: We have an audience that includes people with visual impairments, in this back office setting there's usually administrative support to help guide that audience – but if we start using our components front office settings for instance, we need to take this into account.

[verheyenkoen]

@mietcls I can't really tell if that causes any problems of that kind. Maybe the design crew can weigh in?

[mietcls]

@verheyenkoen this is a shared responsibility between front-end and design, if we can test it with a screen reader I'll be able to let you know what the impact is? The fiddle is hard to test, would be nice to test it in this branch.

[mietcls]

Issue scope adapted according to ping-pong session 🏓