Date picker field improvements

[PVince81]

• add placeholder when empty

• add date picker icon inside the field

• how about accessibility ? @marcus-herrmann

[PVince81]

[marcus-herrmann]

Date Pickers and accessibility, classic topic.

Current implementation

The current implementation is inaccessible:

• It is not usable with keyboard only
• It has no focus management, focus is not sent into the container that appears to be a modal, nor sending it back to the trigger on close
• the date picker "modal" is not a real one (see Dialog box improvements web#2263 (comment))
• the date picker is unusable with screen readers and voice control software (like Dragon Speech)
• opening the "modal" on the focus event is an unexpected change of context, therefore could be considered as a violation of WCAG 3.2.2)

Web accessibility expert Adrian Roselli has a great article on the whole topic (bordering UX, maybe relevant for @wuenschedesign), unfortuately there is something wrong with the embedded Codepen.

In-depth article

Takeaways from the article:

• Datepickers can be used for indicating a precise date or a time span. Different use cases, different accessibility concerns. Can we be sure that the date picker in Owncloud will be only for precise dates and not spans of time?
• JS Datepickers, even them who claim to be accessible, are not
• Adrian did 20 years of user research on this topic and noted high amounts of frustration with users of assistive technologies (e.g. Screen readers, Voice Control software)
• People don't want to learn an interface, but enter the data, "get stuff done"
• Even W3C's Web Accessibility Initiative does not dare to recommend a best practice
• Even the browser's native datepickers, <input type=date>, are flawed and inaccessible (!)
• Validate client-side, quickly and obviously, and of course, on the server side as well.

So what to do

A way out of this dilemma could be mentioned in the article's comments. My interpretation of it, and it is actually not that far away from the screenshot in this ticket:

• Supplying a text field (type="text"!)
• Putting a button adjacent to the field that triggers a date picker
• Adding sr-only instructions to the text field (via aria-describedby– I could demonstrate if you are interested) regarding what date input format is requested
• Making sure that the date picker is at least keyboard accessible.
• Like suggested in this ticket by @PVince81, supply further visible instructions with placeholder attribute

If you are interested I could look into how big e-commerce/travel websites solve this (at least the ones that a known for good accessibility, like Expedia)

[PVince81]

If you are interested I could look into how big e-commerce/travel websites solve this (at least the ones that a known for good accessibility, like Expedia)

Sounds like a plan.

So it sounds like we might need to swap the date picker components.

How about detecting screen reader scenarios and swapping the date picker with a simple text field ? Or can we make the date picker field invisible to screen reader and have another "visually hidden" field that is considered present for screen readers ?

Is detecting screen readers and switching rendering mode an anti-pattern ?

[marcus-herrmann]

Is detecting screen readers and switching rendering mode an anti-pattern?

If you take this literaly – it is, at least ethically.

But hiding a (sr-)broken experience from screen readers if we could supply an equivalent experience could work, but I have to do more research on that.

One strategy could be (single date, no timespan selection here):

• Hide the datepicker-triggering button with aria-hidden="true"(which is, in some regards, the opposite of visually hidden)
• But then describe what form and format of input you expect (like described above, witharia-describedby).

But to re-iterate: This would only deal with screen readers. We have have to take other things in consideration:

• How the date picker overlay would work with Speech recognition software (Dragon, Apple's Voice Control)
• That it's keyboard accessible for keyboard-only or switch input users
• That it can be enlargened visually by zooms of all sorts without breaking (this concern actually is valid for the whole Phoenix interface)

I don't properly suggest this strategy yet because it is a) an assumption and b) I haven't yet researched the side effects on other forms of assitive technology/accessibility. I would extend my research with that.

[PVince81]

So far I'd say the date picker is only here as a convenience. In general all we want is that the user inputs some date, but typing a date can be cumbersome due to the different formats.

This is where I'm wondering whether such software should have a way to provide their own method for inputting dates. Not sure if it's their responsibility.
This then brought me to the "input type='date'" element https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date which seems to be a way for browsers to display a date picker and even supports limiting ranges (the latter is needed by OC in some scenarios).

Is there anything related to "input type='date'" for accessibility tools ?

So far it sounds like more research is needed. Maybe as you suggested, have a look how some popular accessible websites are solving it.

[marcus-herrmann]

Like mentioned above, <input type="date"> is frustratingly not generally accessible for voice users (long read) (rather - the user agent vendor's implementations aren't. But same effect).

Edit: There is no technical way to detect voice control software.

[marcus-herrmann]

Research

Solutions in the wild that are considered accessible by some

Expedia

Homepage, https://www.expedia.com/

• When the "Check in" or "Check out" text input is focused, the date picker overlay is opened and the accessible name of the text input changes from its label ("Check-In", supplied by the <label>) to a rather verbose text, provided by aria label attribute, which is only applied when its focused: "Check-in Check-in expanded. Enter a date in mm/dd/yyyy format or choose one from the table below. Showing Oct 2019 Nov 2019". I'm not quite sure why they did not use aria-describedby the same way. Maybe after user testing the devs came to the conclusion that aria-label is a more robust way than aria-describedby.
• If you are wondering why there's repetition at the beginning, "Check-in Check-in expanded. Enter a date in mm/dd/yyyy format or choose one from the table below. Showing Oct 2019 Nov 2019", I'm certain it's because of WCAG 2.5.3, "Label in name" (explainer)
• Date picker uses the concept of the disclosure widget and it is activated/expanded on focus of "Check in", "Check out" text inputs (since it's no modal and no change of context, an activation on focus is okay here)
• The markup of the date picker consists (mostly) of a data/date table where inaccessible dates (the ones in the past) are visually perceivable, but greyed out, and non-interactive. This is ensured with the disabled attribute on the single days, which are buttons. In addition to that, inactive days are completly hidden to screen reader users, with aria-hidden="true"). So what a screen reader user perceives is one or two tables consisting of only available, selectable, reachable dates. Furthermore, the weekday indicator (S M T W T F) is perceived with full weekday names, supplied by using visually hidden elements. In addition the table is captioned and marked up properly with <thead>, <tbody>, etc.

Google Calendar

Can be reached from every view, https://calendar.google.com/

• Triggers the date picker overlay on focus and on click without a specific trigger button.
• Date picker uses the concept of the disclosure widget
• The markup of the date picker consists (mostly) of a grid widget with role=grid. In this construct, single gridcells can be selected. The selected state is communitcated with aria-selected. In this grid, the only possible keyboard interaction is using the arrow up/down keys to go to the next or previous day respectively. By design, there aren't any inactive dates

Booking.com

Homepage, https://www.booking.com

• Booking.com works with two different concepts - a kind of disclosure widget when it comes to mouse, touch and voice activation users, and a native select inputs for keyboard users and screen reader users.
• As soon as the user focuses into "the area" where, regarding DOM tree and visually speaking the disclosure widget/date picker overlay is, the hidden first select gets visible on focus. Once the first select has a proper value, the next select will become visible. It is a bit hard to explain, please watch the video
• Therefore the complete disclosure widget construct (triggering element and the disclosed container) is hidden from screen readers using aria-hidden="true"
• As a keyboard user your focus "will get stuck" in the chain of selects and they won't ever reach the contents of the date picker
• Normally I would strongly advice against using a non semantic and non focusable element like a <span>, as booking does here as a (disclosure) button. But at first glance that seems to be okay here, because:
  • Keyboard users won't every reach the button. Instead the first native select will get focused and by that, visible
  • It has aria-hidden="true" and is hidden to screen readers
• Interestingly, the "months" tables in the datepicker overlay are pretty accessible for screen reader and keyboard users. The thing is that in this construct they can't (but needn't) be reached with SR or keyboard. I assume is a reusable component that needs to be accessible in isolation

airbnb.com

Homepage, https://airbnb.com

• The Date input is an actual input, not a overlay-triggering button
• Date overlay opens on focus, closes on blur
• The date overlay uses the the disclosure widget pattern - overlay comes next after the input in DOM. Therefore, no focus management necessary: The overlays interactive elements are inserted in to the taborder when the date overlay is open, removed, when it is closed
• Date overlay has a role="application" which signals to some screen readers that their usual keystrokes (jumping to links, headlines,...) will not work in this widget - and that these SR will change into "application mode" (if existent in their software)
• This application widget consists of buttons:
  • Two to go to the next and previous month
  • Up to 31 single ones (table cells turned buttons with the help of role="button" on them for dates, the ones in the past marked as disabled with aria-disabled="true". The disabled ones have also "Not available" as part of their accessible name
• The date widget consists furthermore of a table (I guess for visual representation), that loses its semantic meaning since role="presentation" is applied
• Keyboard only users can operate the table cells ("date buttons") via their arrow keys on the keyboard which is to my understanding the keyboard usage pattern of ARIA role="grid" (without any actually attribution of said role)

[marcus-herrmann]

My recommendation would be right now to try to implement a solution inspired by booking.com's date picker. Provinding select input options prevent unclear date inputs (that could happen with a freetext input, even with a good placeholder example). Also, it would make validation easier since the system could offer only selectable dates. This would make a (select based) input a valid input (at least on the client side). But we have to make sure that the whole date picker widget for mouse, touch, voice input users is hidden for screen readers (aria-hidden="true").

Same goes for the "visual" date picker. Only offering selectable dates (present or future) will lead to valid inputs (still - at least on the client side. But I guess a server side validation of these dates in already in place).

Bear in mind that this recommendation is based on the research above but needs to be tested with real users and real assistive technology.

[marcus-herrmann]

I somehow got a notification email one hour ago as if this issue was created for the first time. Now I'm uncertain whether you need help/a statement; or if it's just connected to the transfer @pascalwengerter did.

[pascalwengerter]

@marcus-herrmann connected to the transfer (GH treats this as a newly opened one), thanks for being reactive but nothing to be done here for now ;)