[BITV/A11Y] Datetime picker UX needs to be improved.

[marcoambrosini]

Feature request

Setting date and time with our current picker is very expensive and creates a lot of friction. I think we need to go back to the drawing board and come up with something better!

To do

Replacing the current datepicker with a native obehavourne

• [x] Evaluate and document browser compatibility
  • https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local#browser_compatibility
  • https://github.com/nextcloud/browserslist-config/blob/2ee74e812ceb22721c904b77aa886a420c79f9fc/browserlist.config.js -> https://browserslist.dev/?q=ID4wLjI1JSwgbm90IGllIDExLCBub3Qgb3BfbWluaSBhbGwsIG5vdCBkZWFkLCBub3QgRmlyZWZveCBFU1I%3D -> check oldest and latest version
  • some older versions were tested via https://live.browserstack.com/ simulator
  • [ ] Android Desktop v4.4 (should be an android app, not an desktop/android, that doesn't make sense)
  • [x] Chrome Desktop v87
  • [x] Chrome Desktop v103
  • [x] Edge Desktop v101
  • [x] Edge Desktop v103
  • [x] Firefox Desktop v100
  • [x] Firefox Desktop v101
  • [x] Opera Desktop v86
  • [x] Opera Desktop v87
  • [x] Safari Desktop v13.1 !not usable
  • [x] Safari Desktop v15.5
  • [ ] Samsung Desktop v17 (should be an android app, not an desktop/android, that doesn't make sense)
  • [x] Chrome for Android v103
  • [x] Firefox for Android v101
  • [x] UC Browser 12.12
  • [x] Safari for iOS v12
  • [x] Safari for iOS v13
  • [x] Safari Desktop v12 !not usable
  • [x] Safari for iOS v15.6
  • [x] Document known limitations
• [x] Adapt styling
• [x] Provide native attributes / events: all possible props and events from https://github.com/nextcloud/nextcloud-vue/blob/master/src/components/DatetimePicker/DatetimePicker.vue#L206 have to be moved to native datetime picker
• [x] Check and adapt datatypes https://github.com/nextcloud/nextcloud-vue/blob/master/src/components/DatetimePicker/DatetimePicker.vue#L184
• [ ] Tests in different places / components

Native date picker limitations

• Most important one: all browsers provide there own implementation of native datetime picker. That means, that there could be some odd behavior in some browsers / versions and they are very different. I've tested it mostly in current Chrome and Firefox. But: the tendency is that browser implementations will be better with a time. E.g. look into last implementation on Safari and compare it with an older versions.

• Bug for type="week".

Chrome: it is possible to pick a week, but mostly not possible to change the week from a keyboard.

Firefox: almost unusable. Neither keyboard nor picker (mouse)

• Bug for readonly attribute. (tested on type="date")

Chrome: doesn't work at all.

Firefox: works only for keyboard input.

• Focus goes too fast away.

Firefox: It is not possible to use a piker via keyboard at all.

• It is not possible to exit a picker (via Esc) without closing an action menu.

Firefox: focus doesn't work at all.

Chrome: I don't know how could it be possible to listen a "close" event from native picker on ActionMenu. First Esc goes to previous date. Second Esc closes action menu completely. See more https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement#events.

• I had no success with step attribute for minutes. I haven't seen any difference. Firefox + Chrome.

Firefox 103.0.1 (64-bit) desktop

Tested on Linux using https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local

Missing picker for time

Picking date	Picking time

UC Browser several versions

Buggy + seems too old.

Safari iOS older versions

Buggy. Can't open picker + can't put a date via input. Not usable.

Safari iOS v12

Partly usable. User is not able to choose year + month.

Safari iOS v13

Partly usable. User is not able to choose year + month.

Safari Desktop v12 + Safari Desktop v13.1

Buggy. Can't open picker + can't put a date via input. Not usable.

Chrome Version 104.0.5112.101 (Official Build) (64-bit) desktop

Colors of disabled dates have too low contrast

Chrome Desktop: Colors of disabled dates have too low contrast (some days in month are disabled and input field shows it in this way). Icon on the right side have too low contrast too.

[raimund-schluessler]

@ma12-co Could elaborate what bothers you?

[marcoambrosini]

@raimund-schluessler this came out in one of our open design calls and I left this here as a reminder. I don't remember the specifics but we found various counter-intuitive things about it and some unnecessary steps.

[JuliaKirschenheuter]

I see there several problems regarding navigation via keyboard:

1. Navigation order: double left -> left -> double right -> right -> month -> year -> OK

2. Datetime picker body is completely inaccessible

In this point there should be done also a lot:

• to make a difference between current month - next/previous month,
• to make a difference between weekends,
• to make a difference between current and next/previous day,
• not only color difference
• allow different keys to navigate inside of Datetime picker body
• it's not even possible to type in a date manually and get it accepted, especially when the format is not known in advance

3. All icons must have descriptions

4. It is not possible to quit a Datetime picker via keyboard.

Datetime picker as a popover

Datetime picker as a popover is completely inaccessible via keyboard: ActionInput type="datetime-local". Popover will gone by the next tabulation.

Probably would be better solution to check existing implementations of Datetime picker and use a modern / accessible one rather than use this one https://github.com/mengxiong10/vue2-datepicker

[PVince81]

see also https://github.com/mengxiong10/vue2-datepicker/issues/684

[JuliaKirschenheuter]

@marcoambrosini, @skjnldsv what is your opinion, how could we move on?

• wait until upstream ticket will be closed?
• search for another library?

[raimund-schluessler]

@marcoambrosini, @skjnldsv what is your opinion, how could we move on?

* wait until upstream ticket will be closed?

* search for another library?

Searching for another library is not a good idea, I think (unless the current one is abandoned/deprecated, which it isn't). I would rather try to fix the issue in the upstream library.

[marcoambrosini]

I think needs some design and usability research @jancborchardt & @nimishavijay

[ChristophWurst]

@JuliaKirschenheuter is currently investigating how much effort it would be to fix the existing upstream lib. As alternative approaches she will research if there are other capable (and hopefully accessible) Vue date picker options. And lastly, if both of those are too much work, how much effort it would be to create an accessible date picker from scratch.

Based on that information we'll take a decision on how to move forward with this topic.

[JuliaKirschenheuter]

There are 3 ways, how could we move forwards with Datetime picker:

• Fix vue2-datepicker

  This is not our code. Fix this would take much time (fix js movements, fix accessibility and connect all related fields, provide all descriptions). There are much fix to fix: accessibility issues and visual bugs (desktop and mobile, mobile + zoom). We still have dependency to the upstream library. We don't know when fixed issues will be merged. Last but not least: this one seems not good design-wise.

• Use other one

  See below

• Create one from scratch Will take a lot of time: js base, css base, css mobile, accessibility. Then we have to maintain it all the time. This is just a datetime picker. All other accessibility tickets will slowly move forwards.

Me and @st3iny researched around. There are so many different datetime pickers, but most of them are not accessible. There are 2 options, which we could use:

• Native datetime picker https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local
• Vaadin web components datetime picker https://vaadin.com/docs/latest/components/date-time-picker

Native datetime picker

Pro:

• Have good compatibility (IE is not relevant https://docs.nextcloud.com/server/latest/developer_manual/app_publishing_maintenance/app_upgrade_guide/upgrade_to_22.html#ie11-removal).
• W3C standard https://html.spec.whatwg.org/multipage/input.html#local-date-and-time-state-(type=datetime-local) https://www.w3.org/TR/2011/WD-html-markup-20110113/input.datetime-local.html
• Native: good accessible via keyboard
• Looks nice
• We still can add / change default styles

Contra:

• Native: looks different on different platforms / browsers
• Localization is limited to local browser settings (not NC settings)
• We would have not much possibility to influence accessibility from outside
• The non-announcement of browser validation error messages in Safari/iOS with Voiceover and Firefox/Android with Talkback
• On Android devices with Talkback, in order to hear a previously selected date in a control, it is necessary to open the calendar view.

Please have a look at https://www.hassellinclusion.com/blog/input-type-date-ready-for-use/ https://a11ysupport.io/tech/html/input(type-datetime-local)_element

Vaadin web component datetime picker

Pro:

• Well supported and contributed
• Have good documentation
• We can support localization (as it is with vue2-datepicker)
• Can be installed via npm
• Can be good integrated in Vue and our system
• Looks nice

Contra:

• We still have a third-party dependency
• 2 fields to "support": date and time
• Is not completely accessible right now:
  • Error messages will not be shown (they are connected via aria-describedby, but the message has display: none)
  • Can't select year / month via keyboard
  • Color contrast issues
  • Voiceover? Talkback? Orca / Jaws?
  • If some other problems will come up, we would have a same situation as it now (but less problematical)

See more:

https://github.com/vaadin/web-components https://www.npmjs.com/package/@vaadin/vaadin-date-time-picker https://cdn.vaadin.com/vaadin-web-components/23.2.0-alpha3/#/elements/vaadin-date-time-picker#property-i18n https://github.com/vaadin/web-components/tree/master/packages/date-time-picker

---

@nextcloud/frontenders please feel free to add something there. @nextcloud/designers please feel free to add something there.

I've talked to @jancborchardt: preference is on native datetime picker

[CarlSchwan]

personally I also prefer a native datetime picker, this also makes things like mobile support easier.

[jancborchardt]

Yeah, even though there are certain drawbacks for the native datetime picker, there are way more for all these 3rdparty libraries.

And then it’s as expected on the platform, just like we also do with our native font stack because custom fonts just resulted in too many issues. A big reason for datepicker libraries was bad browser support, but now that this is mostly fixed and often much better (especially on iOS and Android), it’s better to go with native & standard.

[dartcafe]

While reading through this issue, I would like to understand, why the datetime picker has to be accessible. At least if this addresses accessibility to visually disabled people, I would guess that they would prefer a textfield rather than a picker.

Is that an issue, which is addressed from affected ones, or the result of a review?

Maybe I didn't get the intention right, but I would like to understand that.

[ChristophWurst]

There are 3 ways, how could we move forwards with Datetime picker

At the moment it does look like the native date time picker is the most promising option, so we will try that approach.

As a short term todo we need to compile a list of browsers that we support and test each of them with an example of such native datepicker to capture a snapshot of the current browser capability, the accessibility, design and so on. As an example, we noticed that the Firefox date time picker does only have an input menu for the date, not for the time or am/pm switch. Wherever we find lack of feature/accessibility/etc we should document these limitations and see if there are known limitations or workarounds for those browsers. That means, with the given example, searching the Mozilla tracker for any related tickets and checking their status. If we do not find any blockers then we can proceed with this migration.

[AndyScherzinger]

@dartcafe we got 2 external reviews from external in a11y specializing companies and also customers raised a11y issues. The goal is to work on closing the gap to the various a11y standards like WCAG21. and BITV2.0.

[JuliaKirschenheuter]

I'm still a bit unsure if we should use native date time picker, because there are some important accessibility issues especially in Firefox =(

There is an official overview of bugs:

https://bugzilla.mozilla.org/buglist.cgi?quicksearch=date+picker https://bugzilla.mozilla.org/buglist.cgi?quicksearch=datetime+local

But i think it is still the best solution we have for now. The next step could be to create our own datetime picker, but this needs much time (desktop, mobile, all accessibility requirements: navigation, shortcuts, zooming, contrasts, labeling) + tests.

@AndyScherzinger, @ChristophWurst should i start to replace all our datetime pickers?

[AndyScherzinger]

@JuliaKirschenheuter since it is still the best option, yes 👍

[AndyScherzinger]

Also did we make sure the native picker is available on all currently supported browsers by Nextcloud?

[JuliaKirschenheuter]

Also did we make sure the native picker is available on all currently supported browsers by Nextcloud?

Yes, https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local#browser_compatibility But as i said before native datetime picker have some accessibility problems / bugs in Firefox.

[PVince81]

I've documented my struggles with the current date picker: https://github.com/nextcloud/calendar/issues/4414

Even if we swap one out, it would be good to keep these in mind so that we don't have the same problems. I found having a "Pick date" button in the footer not intuitive.

[JuliaKirschenheuter]

I'm currently working on correct integration a native datetime picker into ActionInput and there are some places to fix:

• [ ] Adapt styling
• [ ] Focus on elements + focus on calendar
• [ ] Shortcuts (incl. Esc: popover inside of popover)
• [ ] Remove wrong elements
• [ ] Provide native attributes / events: all possible props and events from https://github.com/nextcloud/nextcloud-vue/blob/master/src/components/DatetimePicker/DatetimePicker.vue#L206 have to be moved to native datetime picker
• [ ] Check and adapt datatypes https://github.com/nextcloud/nextcloud-vue/blob/master/src/components/DatetimePicker/DatetimePicker.vue#L184
• [ ] Tests in different places / components

[ChristophWurst]

A draft of the new picker can be found at https://github.com/nextcloud/nextcloud-vue/pull/3063. Early feedback appreciated.

[ChristophWurst]

Is that the case for every browser? Could you please add the limitations to https://github.com/nextcloud/nextcloud-vue/issues/1666#issue-784236372?