Deprecate and remove jQuery UI datepicker

left arrow moves back two days at a time, right arrow does nothing, up and down select every sixth day, etc.

I had to read this multiple times because it sounds so absurd 😂 Sounds like the author A) has a sense of humor, B) hates keyboards 🤷‍♂️

EDIT: is this the demo at http://chemerisuk.github.io/better-dateinput-polyfill/? I wanted to experience this absurdity myself, but … it works fine for me. Still deciding whether this is a relief or a disappointment 🤔

The remaining 9%

Let's dig into that number to see if helps us make a decision:

• On mobile, it's only 3.36% that doesn't have this. 1.48% are Opera Mini users. Based on how Opera Mini executes post-page load JS, it can be argued it would be a better experience to just have textual input fields in that browser: https://en.wikipedia.org/wiki/Opera_Mini#JavaScript_support. Consequently, only 1,88% of global mobile browser users would not get a date picker.
• On desktop, it's 13.34% that doesn't have this. That's … a lot. No version of desktop Safari supports this for example. Not even the upcoming one. It's the last desktop browser that doesn't have any support for this at all. Every other browser has at least partial support for it (which we could then evaluate to see whether it's sufficient or not).

… I think this means it doesn't really help. Except that I think it makes the consequences of choosing to go with the patch in #3 very clear. The consequences would be:

• On mobile, virtually every user would just get to use the built-in datepicker. This would be a UX improvement!
• On desktop, users stuck with old browser versions would experience worse DX. This would get better over time as their computers/browsers are updated. Safari is the exception: there's no sign of progress at https://bugs.webkit.org/show_bug.cgi?id=119175.

I personally think we can defend going with the patch in #3 based on those numbers. But I cannot decide this. Let's ask a Drupal product manager for their perspective.

Updating issue title to match the new proposed scope.

I'm honestly shocked and appalled that accessibility of native datepickers is so incredibly bad 😨 And I did not realize that we only used jQuery UI's datepicker only on browsers that do not support the native datepicker, meaning that 91% of users (who then use a native datepicker) are subjected to this horrible accessibility! 😔

We need to consider the realistic option of dropping the DatePicker design pattern. Some of these widgets that jQuery UI incorporates like the Accordion and Tabs are real design patterns: https://www.w3.org/TR/wai-aria-practices-1.1/#aria_ex - And that's great. However, the calendar pattern is not on there. That's alarming.

We can tell from the features of the calendar that this was not designed inclusively and it was not well tested against assistive technologies.

We know that the calendar has been around for a while and people are familiar with it, and browsers have adopted it, but that's not a good reason to continue using them.

I'm looking around for a solution, but one thing that I come back to is simply having a bit of a smarter form that evaluates information that is being typed in as being the default. Something a little smarter than just PHP's strtotime or JavaScript's Date.parse(). Someone should be able to enter in "Aug 19, 2019" and that might be faster and easier than navigating the widget.

Calendars are always handy, but the default when you click in the box could be the assumption that you are going to type in a date. If it is something like 02-03-19, then maybe you should have a means to pick which of the 3 options you're actually talking about. Is it following ISO 8601's format of 2019-08-19?

But yes, calendars are hard to make accessible. Might be useful to have that just be something that you need to activate by clicking the calendar icon beside the box if you want the widget view, but to not make the widget the default action.

EDIT: From this twitter thread useful to note that picking past dates is apparently a real challenge for usability with most date pickers. Also the UK's Design System opted for a pattern like this https://design-system.service.gov.uk/patterns/dates/ which is also worth considering.

Oh, https://design-system.service.gov.uk/patterns/dates/ looks really good! Thanks for that link, @mgifford!

Looks like that was added in an edit to #17. @bnjmnm, what are your thoughts about that approach?

Okay, so let's get clarity on the current status and next steps.

1. https://design-system.service.gov.uk/patterns/dates/ reduces datepicker use, but does not eliminate it. Hence we still need a datepicker other than jQuery UI's.
2. #18 contains a prototype based on the OpenAjax Alliance datepicker. It's a rough prototype, in that it doesn't yet make Drupal use it anywhere.
3. As far as I understand, every other candidate datepicker has been ruled out (see #15 + #16).

What do you recommend as the next step, @bnjmnm? It sounds like we need to continue to develop #18. How big of an effort is that?

Oh … I said I hadn't noticed any Drupal integration because I saw only one JS file being added, and I wrongly assumed that this was that OpenAjax Alliance Datepicker. But it's apparently a mix of our own code + their code, in a single JS file.

I didn't realize we'd need this much custom code. That's pretty unfortunate, and relatively risky. I think that needs sign-off from a JS maintainer. (Tagging Needs subsystem maintainer review.) Because like you point out, this will require quite a lot of JS test coverage. Choosing this path means choosing to maintain this for ourselves forever, or at least for the entire Drupal 9 cycle (tagging Needs release manager review for that).

We are trying to remove jQuery UI's datepicker, which was added in Drupal 8 as a polyfill for browsers that don't support the HTML5 input type="date".
https://www.drupal.org/project/drupal/issues/1835016

It is disappointing that, 7 years later, we can't simply remove the polyfill as suggested in #3.
And it's also discouraging that the native datepickers have their own problems.

I don't think it's within the scope of this issue to provide a better datepicker experience than native.
It would be difficult enough to build or integrate a datepicker polyfill that matches the jQuery UI datepicker for features and is compatible with Drupal translation and - even better if it improves on the localization.

• https://www.drupal.org/project/drupal/issues/2791693
• https://www.drupal.org/project/drupal/issues/2936268

I'm concerned that the poor native datepicker accessibility has derailed this issue, we should be focused on trying to replace the polyfill with something that has feature parity with jQuery UI datepicker. Bonus points if we can make it more accessible or tackle some of the existing datepicker issues at the same time.
If we widen the scope of this issue to also replace all desktop (and mobile?) native datepickers I think it would be unmanageable and unlikely to be completed.

Currently any browser that supports input type="date" gets a native datepicker.
If the native datepicker has a11y issues, that should not be Drupal core's problem to fix.
Alternatively, we could open a follow up feature request that defines a plan for a different input for date fields, if we wanted to build something more custom like suggested in #17, something like this prototype "smart" text field.

•     +++ b/core/misc/date.js
      @@ -4,35 +4,710 @@
      +        $input.attr('type', 'text');
      

  Regardless of how quickly or how well browsers are implementing the HTML5 spec, it would be a step back in my opinion to disable native datepickers, especially on mobile.

•     +++ b/core/misc/date.es6.js
      @@ -20,39 +20,926 @@
      +      if (Modernizr.touchevents && Modernizr.inputtypes.date === true) {
      

  And to override all the desktop browsers.

we have not tested the accessibility of native datepickers on mobile devices. If they have problems like their desktop counterparts, the custom datepicker will need to accommodate mobile users as well.

I would argue that just getting to the baseline of what mobile native datepickers do now (touch events, voice over, localization) would be a huge effort, let alone improving on them, or fixing the very specific a11y shortcomings.

Currently any browser that does not support the input type="date" sees a jQuery UI datepicker. I think that should be the scope of this issue- replacing that datepicker for those browsers.

I am really impressed with the start @bnjmnm made in #18, not only does it work and look decent, but it simplifies localization.

Take a look at core/modules/locale/locale.datepicker.es6.js to see how the jQuery UI datepicker needs to be modified to allow for string translation.

I didn't realize we'd need this much custom code. That's pretty unfortunate, and relatively risky.

I found another datepicker that also is based on the OpenAjax Alliance,
https://github.com/eureka2/ab-datepicker

It also has built in locales including not just translation but date formats. It might be good to start from a project that has more hours already put into it, but if we use any other library we will still need to write custom code like the locale.datepicker js above for Drupal.t() and any other changes or integrations we need.

I was very against the idea of "rolling our own" datepicker calendar until I saw #18.
It might be simpler to write our own versus taking an existing library and working with its API- as long as we limited the scope and don't need to fully replicate the features of jQuery UI datepicker.

• I explained in #4 how only 9% of sites need a polyfill, meaning that jQuery UI's datepicker is currently used only by 9% of users.

  @bnjmnm observed every native datepicker to have terrible accessibility. @bnjmnm then argued that we should take this opportunity to not just keep an accessible datepicker for the 9% of polyfill users, but 100% of users since the native datepickers are so terrible.

  I can follow that reasoning if there was a clearly great, low-effort, low-risk datepicker readily available. But per #23/#24 … that is not the case. 😭

• That's why I'm glad to see @zrpnr write

  I don't think it's within the scope of this issue to provide a better datepicker experience than native. […] I'm concerned that the poor native datepicker accessibility has derailed this issue […]

  I agree. Again, if it would've been low-risk, I would've been fine with it. But we're under a lot of time pressure, and the goal is to "remove jQuery UI risk and not regress", not "remove jQuery UI risk and improve". Let's not forget we're not doing this with the explicit goal to reduce the risk of Drupal 9's external dependencies!

• I was very against the idea of "rolling our own" datepicker calendar until I saw #18.
  It might be simpler to write our own versus taking an existing library and working with its API- as long as we limited the scope and don't need to fully replicate the features of jQuery UI datepicker.

  🤔 I'm confused now. It seems the direction of #25 at the start is very different than at the end :D

  It sounds like you had concerns (similar to what I wrote in my previous bullet) and then you just got convinced by @bnjmnm's PoC in #18?

  Are you saying that you believe we should pursue #18?

  Are you saying we should make #18 run everywhere, or only where no native datepicker is available?

It sounds like you had concerns (similar to what I wrote in my previous bullet) and then you just got convinced by @bnjmnm's PoC in #18?

I was surprised (and impressed) that #18 produced a working datepicker, but I wasn't convinced it should be used instead of a native datepicker.

Are you saying that you believe we should pursue #18?

I think #18 might be a simple way to make a Drupal friendly datepicker that doesn't have any dependencies, and which wouldn't require additional processing- for example to make translations work.
Currently the locale module uses the jquery.ui.datepicker API to override strings, but in #18 Drupal.t() is already part of the code.

Are you saying we should make #18 run everywhere, or only where no native datepicker is available?

Sorry for not being more clear- I am opposed to overriding the native datepicker in any browser, desktop or mobile.

I thought #18 could be a promising polyfill replacement. I didn't do a real code review since it was a prototype, but in #25 I pointed out 2 parts that I disagreed with:

• Using javascript to change the "type" of input from date to text, (disabling native datepickers)
• Changing the modernizr check to enable javascript datepicker for all non-touch devices.

the goal is to "remove jQuery UI risk and not regress", not "remove jQuery UI risk and improve".

Well said! I found a lot of the a11y research very interesting but I think any broader change to how Drupal treats date inputs is out of the scope of this issue.

Thanks for the clarifying comment. That all makes sense!

I know @bnjmnm will be back from vacation on Monday. Let's see what he has to say :) Hopefully some JS maintainers will also have left feedback by then.

I support the idea that we only provide the datepicker as a polyfill. It's great if we can find something that is more accessible than native datepickers. There's nothing preventing us from making it the default in a follow-up.

I'm not too excited about maintaining our own datepicker but if that seems like the best solution, and the JavaScript subsystem maintainers agree on that, we probably should go with that. Any thoughts on marking it as internal so that it's not designed to be an API for the contrib? It's only designed to act as a polyfill for core.

It would be great to get feedback from the product managers on what they think about this. Specifically, the part that the datepicker is used just as a polyfill, and that it's only used by 9% of the users. Comment #4 has a good breakdown of what is in that 9%.

I guess my opinion is it's unfortunate that native datepickers have so many accessibility issues, but I don't really see that this is a "bug" for Drupal to fix. We could always add a "feature/enhancement" to add a library with better accessibility, but I wouldn't throw that in the way of releasing Drupal 9, as long as it doesn't create a regression.

So I think that means +1 to using some other datepicker library as a polyfill (which is the status quo?). It would help a lot though if the issue summary were updated prior to asking for PM sign-off with what the actual proposal is here; I'm going by the few most recent comments...

Do we want to provide a polyfill for date inputs to browsers that don't support it natively? This means less than 9% of users globally. Some of these users wouldn't necessarily be able to use the polyfill since 5% out of the 9% are browsers we support. I just want to make it clear, that we are potentially making a significant investment to a fairly small proportion of the user base.

If we choose not to provide date picker polyfill, we could do it gracefully in the sense that we could provide help text that describes how the field is supposed to be filled (similar to what the gov.uk design system has done).

Some of these users wouldn't necessarily be able to use the polyfill since 5% out of the 9% are browsers we support

Ah, I wasn't able to compute this number because I wasn't sure about the current browser support policy. I know that was agreed upon in the last few days, perhaps that allows you to compute this now. In any case: a valuable addition to this issue!

I just want to make it clear, that we are potentially making a significant investment to a fairly small proportion of the user base.

+1 to considering this. That means going with the patch in #3, which is what I argued we should consider a month ago, in #4. But in my case, the number was "9% of users affected", but that turns out to now be "5%". Of course, that's assuming that all users tend to have to enter dates, which is not at all true. The true number of negatively affected users is therefore even less than 5%. Probably less than 1%.

Do we want to provide a polyfill for date inputs to browsers that don't support it natively? [...] I just want to make it clear, that we are potentially making a significant investment to a fairly small proportion of the user base.

I guess to answer that question... what is the user experience of a date/time field for non-HTML5-supporting browsers? It would depend on how passable it is. (Screenshots of Chrome or something vs. _____ would be helpful in making this call.)

If it falls back to 3 text fields labeled "Month / Day / Year" (in some combination) like https://design-system.service.gov.uk/patterns/dates/ does, then that seems passable. If it's a single text field with no guidance as to what format to type in there to meet validation criteria, that's not.

One question in terms of timing:

Since we don't actually replace this with a new library or deprecate anything, this patch could be fine as a 9.x-only patch, leaving Drupal 8 with the existing jQuery UI datepicker up until it goes EOL in November 2021 - however this would mean a different experience between 8.9.x and 9.x.

The advantage would be that whatever the browser statistics are now, they'll likely be more favourable in June 2020 when 9.0.0 actually comes out.

I'm neutral on this, just thinking through it.

Definitely agreed a follow-up to improve accessibility and keep looking at alternatives would be good to do.

#34++ (and what you did was not derailment, but due diligence — I'm pretty sure everybody in this issue is very grateful for it!)

#35: Oh that's interesting! Can you confirm that the following two steps are what you are proposing?

1. only deprecate core/jquery.ui.datepicker today (in 8.8), to be removed in 9.0
2. create a must-have 9.0 issue (with a patch that we create today) that gets committed to 9.0 as soon as the 9.x branch opens — that would remove core/jquery.ui.datepicker and add that help text/those instructions for browsers without native datepickers

For step 2: it could even be RTBC today against the 8.8.x branch and we would be required to keep it green & RTBC until the 9.x branch opens, this would ensure it remains readily available.

@Wim Leers, yes I'm not saying that's the best option here, we might want to commit the change to 8.8.x or 8.9.x too anyway, but it seems like a viable option to consider.

One issue working against that, is that we'd have to skip the deprecation notice for jquery.ui.datepicker in 8.x (because we'd still be using it ourselves), but that seems relatively minor - we know exactly what we're doing and why with that skip.

That all sounds perfectly sensible :)

Can I flag that we still need some screenshots here to understand the UX impact of that suggestion?

Thanks! That's icky, but still usable, so +1 from me on the proposed plan!

Untagging for release manager review.

1. +++ b/core/core.libraries.yml
   @@ -525,17 +527,6 @@ jquery.ui.controlgroup:
   -jquery.ui.datepicker:
   

   🐛 We can't remove this, we can only deprecate it.

2. +++ b/core/misc/date.es6.js
   @@ -10,48 +10,16 @@
   +        $('body' ,context).addClass('drupal-html5-date-input');
   

   🤓 Typo: space before the comma instead of after. :P

3. 🤔 Thanks for the screenshot in #41! Question about it: why not use the placeholder attribute to improve the UX for sighted users?

I would think the placeholder text should be identical to what a user puts in - i.e. the current date and time with no instructions. If we did this then width of the form elements won't be an issue. The description is still there below.

What @catch said :) But #51 already did that, yay!

I could only find nits, so this is now hard-blocked on subsystem maintainer review.

1. +++ b/core/core.libraries.yml
   @@ -535,6 +537,7 @@ jquery.ui.datepicker:
   +  deprecated: The "%library_id%" asset library is deprecated in drupal:8.8.0 and is removed from drupal:9.0.0. See https://www.drupal.org/project/drupal/issues/3072906
   
   +++ b/core/modules/locale/locale.libraries.yml
   @@ -19,6 +19,7 @@ drupal.locale.datepicker:
   +  deprecated: The "%library_id%" asset library is deprecated in drupal:8.8.0 and is removed from drupal:9.0.0. See https://www.drupal.org/project/drupal/issues/3072906
   

   🐛 This will need to point to the change record, not this issue.

   (It'd have been a nit before, but now it's a bug, since this is the only thing I could find that would block a commit.)

2. +++ b/core/includes/theme.inc
   @@ -560,6 +560,27 @@ function template_preprocess_datetime_form(&$variables) {
   +  // This will be hidden on JS enabled browsers that have a native datepicker.
   

   🤓 Übernit: s/JS enabled/JavaScript-enabled/

3. +++ b/core/tests/Drupal/KernelTests/Core/Datetime/DatetimeElementFormTest.php
   @@ -58,8 +58,8 @@ public function buildForm(array $form, FormStateInterface $form_state) {
   -      '#date_date_format' => ['Y-m-d'],
   -      '#date_time_format' => ['H:i:s'],
   +      '#date_date_format' => 'Y-m-d',
   +      '#date_time_format' => 'H:i:s',
          '#date_date_element' => 'HTML Date',
          '#date_time_element' => 'HTML Time',
          '#date_increment' => 1,
   @@ -69,8 +69,8 @@ public function buildForm(array $form, FormStateInterface $form_state) {
   
   @@ -69,8 +69,8 @@ public function buildForm(array $form, FormStateInterface $form_state) {
        // Element without specifying the default value.
        $form['simple_datetime_element'] = [
          '#type' => 'datetime',
   -      '#date_date_format' => ['Y-m-d'],
   -      '#date_time_format' => ['H:i:s'],
   +      '#date_date_format' => 'Y-m-d',
   +      '#date_time_format' => 'H:i:s',
   

   🤔 Why these changes?

Actually, a change record is missing, and the issue summary could use an update. It should include before vs after screenshots to make it easier for a core committer to assess.

I pinged datetime module maintainers to get their input on this: https://twitter.com/wimleers/status/1173990619217371138.

(Even though this is technically not part of that module, that module is most strongly affected.)

I was having a related conversation with my UX/UI lead the other day about this. To be really honest, I really question whether there is a true need for a JQuery UI style datepicker in core.

Calendar pickers are nice when you need to pick out a date, such as next Thursday.

Text-based inputs are great when you know exactly what date you want to enter. JS can improve the experience (the inputs on Ancestry.com are probably the best I have used).

I am on board with removing this from core and leaving it to contrib to give users options to fit their need (rather than us guessing). The timepicker issue has lingered forever now; there are so many use cases that it is hard to have something generic enough that is still usable.

Re-read the whole thread and the patch again. +1 to the solution. This may also solve #2791693: Remove sample date from date field error message and title attribute at the same time.

#57: Oooh, that's great and very encouraging! Thanks for making that connection! 🙏

1. +++ b/core/includes/theme.inc
   @@ -560,6 +560,28 @@ function template_preprocess_datetime_form(&$variables) {
   +    $date_format = is_array($element['#date_date_format']) ? $element['#date_date_format'][0] : date($element['#date_date_format']);
   ...
   +      $time_format = is_array($element['#date_time_format']) ? $element['#date_time_format'][0] : date($element['#date_time_format']);
   

   Would be great to hear from UX experts whether it's better to show the current date in the format, instead of using an explanation of the actual date format yyyy-mm-dd. I didn't realize that the date was the current date until I looked at the code. 😅 Also, I'm wondering how does it work in edge cases such as 2019/10/10 12:12:12.

2. +++ b/core/includes/theme.inc
   @@ -560,6 +560,28 @@ function template_preprocess_datetime_form(&$variables) {
   +      $format_help .= t(', enter the time using the format @time_format', ['@time_format' => $time_format]);
   

   Starting a translatable string with a comma might be confusing to translators. I'm also wondering if this causes issues in some edge cases. I tried to see but it doesn't seem like we have any examples of this in core. Maybe these could be rewritten to be individual sentences? We might want to seek for an opinion from someone who is more experienced with string translations.

3. +++ b/core/includes/theme.inc
   @@ -560,6 +560,28 @@ function template_preprocess_datetime_form(&$variables) {
   +        'class' => ['field--type-datetime__no-native-datepicker-help'],
   

   field--type-datetime class is specific to Classy. We should rename this to something more generic. Something like unsupported-native-datepicker-help could be fine.

4. +++ b/core/includes/theme.inc
   --- /dev/null
   +++ b/core/misc/date.css
   

   🧐Nit: Let's add file documentation with specific mention to what we are trying to do here.

5. +++ b/core/misc/date.css
   @@ -0,0 +1,7 @@
   +.container-inline .field--type-datetime__no-native-datepicker-help {
   ...
   +.drupal-html5-date-input .container-inline .field--type-datetime__no-native-datepicker-help {
   

   Is there a particular reason to include .container-inline in the selector? It seems like this doesn't work with Claro for example because of this.

6. +++ /dev/null
   --- /dev/null
   +++ b/core/themes/stable/css/core/date.css
   

   👍 +1 to adding this to Stable.

The current solution (for browsers without native datepicker support):

However, this could be very confusing depending on what the date and time are:

We could instead use another format of demonstrating the date and time format:

I think the yy-mm-dd hh:mm:ss suggestion is OK - it's easy to translate from that to a date. Although hh::mm::ss does not indicate 12 or 24 hour clock (well it does because there's nowhere to put am or pm, but it's only implicit).

Another option would be using a static (or static-ish) date like 25th January 2019 17:30:00 (2019-01-25 17:30:00) which is always unambiguous - could just make it current year.

Another option would be using a static (or static-ish) date like 25th January 2019 17:30:00 (2019-01-25 17:30:00) which is always unambiguous - could just make it current year.

I like that suggestion!

_{But at this point we're just bikeshedding 👨‍🎨🎨}

re: #54

I'm totally onboard with removing this.

My UX lead (she's not on D.O.) suggested the yyyy-mm-dd hh:mm:ss (or similar) as the placeholder text, and tweaking the description to include both the format and an example date/time with more explicit instructions on the hour part b/c Americans, potentially with localization to handle the American issue.

For #61 + #62 + #65.

This was talked on the UX call yesterday. Recording can be found on YouTube. The proposed solution is similar to #65. Here's a visualization of that created by @rainbreaw:

We should move rendering the description text from backend to the frontend to make sure that users without JavaScript won't see the description text, and that it won't get called out by screen readers. This could be confusing if the user is using a browser that supports input type="date" without JavaScript.

This is surprisingly complicated! From what I understood from the video posted in #68 there are several situations this should improve:

1. Browsers that support input[type="date"] with JavaScript enabled
2. Browsers that support input[type="date"] with JavaScript disabled
3. No date support with JavaScript enabled
4. No date support with JavaScript disabled

The placeholder text will only appear for 3, 4.

My UX lead (she's not on D.O.) suggested the yyyy-mm-dd hh:mm:ss (or similar) as the placeholder text

This sounds right to me and I think it is what the consensus from the UX meeting landed on as well, except with all caps.
Another reason in support of this is that the placeholder text is read by screen readers and is more helpful than an arbitrary date.

The help text will appear for 2, 3, 4.
@andrewmacpherson pointed out in the UX meeting that setting the description text to display: none; wouldn't prevent screen readers from following the aria-describedby,
Or another way to look at it, is the help text was not read if there is no matching aria-describedby.

This patch adds that attribute and removes it with javascript when the drupal-html5-date-input class is added to hide the help text.

We should move rendering the description text from backend to the frontend to make sure that users without JavaScript won't see the description text, and that it won't get called out by screen readers.

This would be a small improvement for 1, but it would be a poorer experience for 4. It seems like the help text should still exist on the page for browsers that require the user to actually type in the date correctly.
With 1,2 (I tested in Chrome) it's not possible to type the date incorrectly anyway because of the UI the browser adds.
On MacOS with US date formatting in both Chrome and Safari, voice-over read a date the same regardless of formatting,
for example 2019-09-26 was read as "September 26 2019"

I found that Chrome (with and without JavaScript) has additional read-aloud instructions for each "step" of the formatted date.

Month, Day and Year each had their own separate instructions.

This patch updates the help text and placeholder text for date and time, adds the aria-describeby attribute and hides with js.

When a date only (no time) has description text, the input itself gets an aria-describedby="edit-field-fieldname-0-value--description" and the div.description has that id.
When a date (with time) has description text, the fieldset has an aria-describedby="edit-field-fieldname-0--description"

This failing test is just checking for the aria-attribute on the date only field, but in the patch I'd changed both their ids slightly, not taking into account the help text. Should the description in the wireframe in #68 be the same element as the help text, override it, or be a separate element?

And should there be separate aria-describedby for each input with date and time or just on the fieldset like it is currently?

This would be a small improvement for 1, but it would be a poorer experience for 4. It seems like the help text should still exist on the page for browsers that require the user to actually type in the date correctly.

The reason we agreed on the proposed approach was that the experience is already broken on these browsers. Therefore we wouldn't regress the experience for anyone. Another factor was that we agreed that a wrong description text is just as confusing as a missing description text. Since the vast majority of browsers support input type="date", we should optimize for that.

And should there be separate aria-describedby for each input with date and time or just on the fieldset like it is currently?

There should be separate aria-describedby for each input.

Since the vast majority of browsers support input type="date", we should optimize for that.

This makes sense, thanks for clarifying.

I'm not sure how to proceed with this however, since I realized the proposed change in #68 conflicts with the current "help" text -which is user editable on the field config page.

Currently, if help/description text is added in the UI on the field config page

• date+time field will have an aria-describedby attribute on the fieldset wrapper, not the inputs.
• date only field will have an aria-describedby attribute on its input.

Should the new help text be a default for a date field? Then it could be edited or removed by a site builder.
Or should the aria-describedby point to a different element than the default help/description text? If so, should the user description be disabled/removed ?

What should be done about the existing description element, especially on the date+time where there could be potentially 3 aria-describedby attributes?

@lauriii and @zrpnr, thank you for talking through this with me on a call. It was helpful to make sure I'm not suggesting an approach that is more problematic than what is currently happening.

Here is the solution we discussed:

• Allow the user to customize the help text for the fieldset, and use that as the aria-describedby for the fieldset as a whole
• Use good basic default help text on the individual inputs that is used as aria-describedby; separate date and time (you can use spans) so that the screen reader only reads the relevant part of the help text for each field
• If the user chooses to add customized help text to the fields, then start the aria-describedby with the customized text, and then append the basic defaults to the end of the user customized text so that both are read
• Use the YYYY:MM:DD hh:mm:ss version instead of a default date, since using a default date might be more confusing
• (optional) Add IDs to the default help text so that a more advanced site builder who knows what they are doing can choose to remove it

Additionally: we discussed adjusting the standard (depreciated behavior) to match this behavior for screen readers as a followup. Just making a note of this here for now since it is unclear if that is something we want to do or not. Further review of the standard behavior should probably be done first.

Thanks for unblocking this @rainbreaw, there were a lot of tradeoffs but this seems like a better solution now.

I rewrote the patch to add the help text with js vs hiding it, now the extra element is removed from the render array.
The text and comes from theme.inc so that it can be translated and no date formatting is needed in js.
I used data attributes to make targeting these elements and getting the information easier, and Drupal.theme functions so that the help text markup can be overridden.

• The user editable help text is still editable.
• For date+time, the descriptions are wrapped in separate spans so that they have a matching id for each input which gets an aria-describedby. The fieldset aria-describedby is unchanged.
• if there is user added help text these messages are appended in the same element, if not, that element is created first.
• Using YYYY-MM-DD for the date placeholder and hh:mm:ss for the time placeholder
• The help text is created with Drupal.theme so the markup can be overridden, or styled with the existing class name.

1. +++ b/core/includes/theme.inc
   @@ -566,35 +567,19 @@
   +    $variables['attributes']['data-drupal-field-elements'] = 'date' . ($element['#date_time_element'] === 'none' ? '' : '-time');
   
   +++ b/core/misc/date.es6.js
   @@ -17,33 +17,109 @@
   +      const dataFieldElements = 'data-drupal-field-elements';
   

   🤔 This data- attribute sounds very generic. It isn't specific to datetime fields at all. Is that intentional?

2. +++ b/core/misc/date.es6.js
   @@ -17,33 +17,109 @@
   +      const dataDatepicker = 'data-no-native-datepicker-help';
   ...
   +            // Set attribute to prevent element from selection on next run.
   +            dateTime.setAttribute(dataDatepicker, 'date-time');
   ...
   +            // Set attribute to prevent element from selection on next run.
   +            dateTime.setAttribute(dataDatepicker, 'date');
   

   🤓 Would dataDatepickerHelp not be a clearer variable name?

   🤔🤔🤔 Oh wait, this says "NO … help"! And subsequent code then sets this attribute. To prevent it from being processed again. So this is basically a reimplementation of https://plugins.jquery.com/once/. If I'm reading that correctly, I think this could use much clearer naming.

3. +++ b/core/misc/date.es6.js
   @@ -17,33 +17,109 @@
   +            const dateInput = dateTime.querySelector('input[type="date"]');
   +            const timeInput = dateTime.querySelector('input[type="time"');
   +            const help = Drupal.theme.dateTimeHelp({
   +              dateId: `${dateInput.id}--description`,
   +              dateDesc: dateInput.dataset.help,
   +              timeId: `${timeInput.id}--description`,
   +              timeDesc: timeInput.dataset.help,
   +            });
   +
   +            [dateInput, timeInput].forEach(input => {
   +              input.setAttribute(
   +                'aria-describedby',
   +                `${input.id}--description`,
   +              );
   +            });
   

   🤩 Love the elegance!

4. +++ b/core/misc/date.es6.js
   @@ -17,33 +17,109 @@
   +            // Date only input will be describedby description directly.
   

   🤓 Übernits:

   1. s/Date only input/Date-only input/
   2. s/describedby/described by/

And subsequent code then sets this attribute. To prevent it from being processed again.

#78 1., 2. That's correct, I was just using this attribute to prevent the element from being selected again after being processed, that data attribute is part of the selector as dataDatepicker in

+++ b/core/misc/date.es6.js
@@ -10,49 +10,116 @@
+      const getDateSelector = elements =>
+        [
+          `[${dataFieldElements}="${elements}"]`,
+          `:not([${dataDatepicker}="${elements}"])`,
+        ].join('');

The :not( ...) ignores it the next time this script runs.

I was trying to avoid any jQuery but maybe once() would be clearer here!

#79: I'm not advocating for using jQuery.once(), I'm advocating for applying naming similar to that, which would make it much easier to understand :) Something like "processed" in the variable name would make it much easier to understand :)

#80 That is good feedback, I changed the variable (and attribute) name and also added a docblock for the selector function to explain the purpose.

#78.3 Thank you!
#78.4 Fixed this comment, I was so used to writing aria-describedby that it didn't look wrong to me :)

Thanks, @zrpnr!

1. +++ b/core/misc/date.es6.js
   @@ -15,13 +15,23 @@
   +      const dataDatepickerProcessed = 'data-no-native-datepicker-is-processed';
   

   🤓 Bikeshedding now, but … wouldn't data-datepicker-is-processed be clearer?

2. +++ b/core/misc/date.es6.js
   @@ -66,7 +76,7 @@
                // Set attribute to prevent element from selection on next run.
   

   🤓 Would "from selection on next run." → "from being processed again." be clearer?

3. I added the Needs subsystem maintainer review and Needs release manager review tags in #24, with this reasoning:
   

   I didn't realize we'd need this much custom code. That's pretty unfortunate, and relatively risky. I think that needs sign-off from a JS maintainer. (Tagging Needs subsystem maintainer review.) Because like you point out, this will require quite a lot of JS test coverage. Choosing this path means choosing to maintain this for ourselves forever, or at least for the entire Drupal 9 cycle (tagging Needs release manager review for that).

   That was based on the patch in #18, which was nearly 60 KB, added an external JS library, plus lots of custom code. The current patch is less than a third of that.

   About 25% of the current patch is just the ES5-compiled code of the ES6 source!

   Based on this much simpler, far less risky approach, removing those issue tags.

4. This also has the needs accessibility review tag. Similar story there: we set out with a much … grander approach than the one we ended up settling on between #25 and #34. That reduces the criticality of accessibility review.

   Nevertheless, it's still very important. Fortunately, @rainbreaw did a deep dive in #76 after @lauriii and @zrpnr walked her through their proposal. They agreed on improvements to the patch. Those were implemented in #77.

   So, removing that issue tag too 🥳

5. Plus, the current approach has +1 from datetime module maintainers @mpdonadio in #55 and @jhedstrom in #64. 👍

I think this is close to ready, but it's too late here for me to flip the RTBC switch. There are some silly nits (points 1 + 2), but those would be fine to be ignore. Ideally, this would get reviewed by at least one other person. I'll take another closer look at this on Monday. But we're certainly getting very close :)

😅

#82 1, 2: I'm happy to address this feedback, I agree that these changes make the intent clearer.

The current patch is less than a third of that.

It's also significant I think, that this patch reduces page size for browsers that support input type="date" because the jQuery UI datepicker js and css are still downloaded even though they are not used. (4kb css, 2.4kb locale.datepicker.js and 35.9 of jQuery UI datepicker).

With this patch, those are gone and although it adds 1.9kb to date.js (1.5kb --> 3.4kb) and 662b for date.css - it's still a big net positive.

Good point! Adding a tag to clearly signal that :)

• I manually tested this in a browser with a native datepicker (Chrome) and one without (Safari):
  
• In the one without, I also tested with a screen reader (Voice Over + Safari). Helpful feedback is indeed provided when tabbing into the <input type=date> and <input type=time. Note that this already got accessibility sign-off in #76.
• We also have sign-off for the approach from the subsystem maintainers in #57 (@mpdonadio) and #64 (@jhedstrom).
• The markup generated by the PHP and by the no-datepicker-JS logic is sensible.

Final review:

1. +++ b/core/includes/theme.inc
   @@ -560,6 +561,27 @@ function template_preprocess_datetime_form(&$variables) {
   +    $variables['attributes']['data-drupal-field-elements'] = 'date' . ($element['#date_time_element'] === 'none' ? '' : '-time');
   
   +++ b/core/misc/date.es6.js
   @@ -10,49 +10,126 @@
   +          dateTime => {
   ...
   +   *   The date input aria-describedby value.
   

   🤓 Nit: should probably be renamed from dateTime to just date.

2. +++ b/core/misc/date.es6.js
   @@ -10,49 +10,126 @@
   +      /**
   +       * Returns a CSS selector for a date field to process.
   +       * The dataDatepickerProcessed attribute prevents a field from being
   +       * selected and processed more than once.
   

   🤓 Übernit: the first line in the docs should have a blank line after it.

3. +++ b/core/misc/date.es6.js
   @@ -10,49 +10,126 @@
   +       * @return {string}
   +       *   A CSS Selector.
   

   🤓 Übernit: there should be a blank line before the @return doc.

4. +++ b/core/misc/date.es6.js
   @@ -10,49 +10,126 @@
   +   * @param timeId
   

   🤓 Übernit: missing type docs.

Fixed all nits.

I tested this on Voice Over with all different variations and I think we have implemented this according to the instructions from @rainbreaw. Good job! 👏

1. +++ b/core/misc/date.css
   @@ -0,0 +1,15 @@
   +/*
   + * div added to selector to gain specificity over inline container styles
   + * @see core/modules/system/css/components/container-inline.module.css
   + */
   +div.unsupported-native-datepicker-help {
   +  display: block;
   +}
   +.drupal-html5-date-input div.unsupported-native-datepicker-help {
   +  display: none;
   +}
   

   Let's duplicate the class instead of using the div for increasing specificity. This would become .unsupported-native-datepicker-help.unsupported-native-datepicker-help as a result.

2. +++ b/core/misc/date.es6.js
   @@ -10,49 +10,128 @@
   +        if (!(description && description.classList.contains('description'))) {
   

   This is not a reliable way to determine if the description element exists. We should inject class that we can reliably use for determining whether this element exists. Additionally, we might want to move this to a static function as we did in messages so that it can be overridden by themes if that's needed.

3. +++ b/core/misc/date.es6.js
   @@ -10,49 +10,128 @@
   +          description = document.createElement('div');
   +          description.classList.add('description');
   +          if (id) {
   +            description.setAttribute('id', id);
              }
   ...
   +          element.parentNode.insertBefore(description, element.nextSibling);
   +        }
   +
   +        description.insertAdjacentHTML('beforeend', help);
   

   Let's move to generating this to a theme function so it can be overridden.

   Edit: We might want to consider making this a static function instead as well to not make it an explicit API.

This is a big improvement @bnjmnm, the fix for not relying on the "description" selector led to a quality refactor and removal of some unnecessary code.

#90.1 Removing the unnecessary css reduces the page size even more, also glad to see you entirely removed the locale test which is no longer used.
#90.2 This adds reliability in case of the help text being altered with a different class name.
#90.3 The new function still isn't a theme function but because it is recreating a div to match what Drupal outputs in the datetime wrapper description I think it's ok to not allow it to be overridden here.

It's also important to let it maintain the id it would have to match the fieldset aria-describedby, which wouldn't be present in a date only field.

The new help text elements are still generated with a theme function, so they can be completely overridden.

+++ b/core/misc/date.es6.js
@@ -36,31 +36,14 @@
-      if (Modernizr.inputtypes.date === true) {
-        document.body.classList.add('drupal-html5-date-input');
-      } else {
+      // If the browser does not support a native datepicker, add date
+      // formatting instructions on date/time fields.
+      if (Modernizr.inputtypes.date === false) {

Switching this statement makes the purpose much more clear and removes the unnecessary body class.

+++ b/core/misc/date.es6.js
@@ -36,31 +36,14 @@
-            const timeInput = dateTime.querySelector('input[type="time"');
+            const timeInput = dateTime.querySelector('input[type="time"]');

😅 Glad you caught this!

I manually tested again in Chrome and Safari on a mac, using a date only and a date+time field, with and without added help text.

Everything works the same, nothing is added in chrome and the help text and voice over works correctly in Safari.

This was RTBC'd in #86 and this latest patch addresses all the feedback in #89.

I have some concerns about this issue, please bear with me while I write them up, and check a few things.

Thanks @andrewmacpherson for reviewing this!

@andrewmacpherson, have you had any further chance to review this? It's important to deprecate this library for security reasons if it's at all possible, and our deadline to do so is Nov. 1. So we would like to know soon if there's something that needs to be fixed with the patch. Thanks in advance!

I guess this likely constitutes a follow-up, but would be nice if the default non-datepicker format was customizible, for example dd/mm/yyyy rather than yyyy-mm-dd, in the real world (non-devs) the former is more their cup of tea.

Short version

The change in this patch is OK, with the conditional help text. I don't see any reason why this shouldn't go ahead. I have one suggestion to improve the patch, see below. Unblocking this now :-)

However it doesn't really come close to addressing the huge problems of the HTML date input, and the datepickers provided by the browsers. The decision to persist with these, and the assumption that any JS library would only be a fallback, is very misguided in my view. There are some ideas about follow-ups, but these don't have a clear direction, so I make my suggestions below.

Sorry I took so long for this - I've been deep in the rabbit hole. Date input accessibility is a convoluted topic, and wanted to make sure my knowledge was up to date.

The conditional help text proposed here is useful. It's kind-of a separate issue from getting rid of jQuery UI datepicker, though. The help text would be useful for any input which you can type an arbitrary text into, regardless of whether there is a pop-up datepicker provided. It's just the awkward conflict between Drupal locale and browser locale that means we have to make it conditional on the Modernizr check, right?

Some observations about the current issue summary

1%-5% of Drupal users use jQuery UI's datepicker.

This is a red herring. Browser usage among assistive tech users is notably different from the population as a whole:

• IE (10.9%) and Firefox (27.4%) usage on Windows is much higher among screen reader users (source: WebAIM Screen Reader User Survey #8).
• That also seems to be the case with users with mobility impairments too: IE 32.6%, Firefox 26.1%. (Source: WebAIM Survey of Users with Motor Disabilities; note this survey has a small sample size). Many Dragon users fall into the mobility impairments category.
• Firefox is popular among keyboard-only users. It has caret-browsing built in, which helps to select and copy text; safer default focus styles; and it still provides a traditional application menu (file, edit, etc.) where the menu accelerator keys are underlined. (Anecdotal, based on some things keyboard-only users have shown me.)

preferred over new datepicker, because there are not options which do not result in a significantly diminished accessibility

Using the UA datepickers over the jQuery UI datepicker results in a significantly diminished accessibility too. It's the most accessible datepicker we've found to date. When D8.0 was released, IE and Firefox got the jQuery datepicker. When Firefox 57 came out, around D8.4, it stopped using jQuery UI datepicker. So in that sense, Drupal 8 has arguably been getting less accessible as a result of the way we've been using Modernizr. The Modernizr test is based on whether the input accepts a parenthesis character; it doesn't take accessibility into account (in fairness, it can't really test much there).

Introducing a replacement datepicker would result in broken screenreader and/or keyboard navigation (depending on the browser being used).

The UA native datepickers are already a broken screenreader experience, particularly on mobile. We're at fault for preferring them over HTML text inputs.

A text field for entering the date, on the other hand, can be made accessible quite easily.

HTML text inputs are a level playing field. Anyone can enter text, using the default text editing methods of their device/OS, including assistive tech.

Using the HTML date input makes things easier for some sighted touch/pointer users, but introduces significant difficulties for nearly everyone else. We're creating inequality by doing so, which is hard to reconcile with our principles and values: Build software that everyone can use.

You can actually have a text input in combination with a datepicker, including the jQuery UI datepicker.

• The Deque and the OpenAjax demos use a HTML text input, with a button next to it to activate the pop-up datepicker if you want it.
• The way Drupal uses jQuery UI datepicker differs from the way the Deque demo uses it. Ours appears when the HTML date input gets focus, and doesn't have a separate button to invoke it.

Note however, that with the patch here you don't actually have a HTML text input in IE11. It's still a HTML date field, despite poor UA support and the fact that it failed the Modernizr check. Dragon users are still at a severe disadvantage because it isn't recognised as a text input. (This was explained in Graham Arnfield's test report, linked in #25 here.)

From the comments

#25, @zrpnr:

was very against the idea of "rolling our own" datepicker calendar until I saw #18. It might be simpler to write our own versus taking an existing library and working with its API- as long as we limited the scope and don't need to fully replicate the features of jQuery UI datepicker

I think this is very sensible. Many libraries try to be the one-stop solution, and are overloaded with options. We probably don't need all the options.

#50, @catch:

I would think the placeholder text should be identical to what a user puts in - i.e. the current date and time with no instructions.

A well-known problem with this is that users mistake the placeholder for an actual value, and think it's already been filled in, so they don't attempt to change it. A default value is OK (e.g. node creation time) but a placeholder can cause confusion.

#25 & #30: These comments contain a big assumption about our responsibility...

#25, @zrpnr:

If the native datepicker has a11y issues, that should not be Drupal core's problem to fix.

#30, @webchick:

it's unfortunate that native datepickers have so many accessibility issues, but I don't really see that this is a "bug" for Drupal to fix.

WCAG expressly says otherwise:

• Guideline 4.1 says "Maximize compatibility with current [...] user agents, including assistive technologies".
• The section on conformance also emphasizes that only "accessibility-supported" ways of using technologies are relied upon. (This is WCAG jargon, which means that browser, OS, and assistive tech all implement support for it.)
• On Android/Chrome/Talkback, the HTML date and time inputs don't convey their current value until after you open the picker. On balance, I'd say that ought to be regarded as a failing the intent of success criterion 4.1.2 "Name, role, value" at level A, even though it passes a strict reading of the WCAG text.
• Success Criterion 2.5.6 "Concurrent Input Mechanisms" says content does not restrict input methods. Some of the known problems with native datepickers are relevant here, especially Dragon not being able to focus a date field directly, or having to use emulated keypresses instead of proper dictation. This is at level AAA, mind.

If we persist in preferring the user-agent datepickers, considering the range and severity of the known accessibility problems, then I don't think we can reasonably say that we're following WCAG, or our community values. This is a huge deal.

Manual testing

Comment #25 mentions Graham Arnfield's report, which is recent (this year). I replicated most of Graham's findings, except for the Dragon Naturally Speaking tests. I couldn't get Dragon to work inside a Virtualbox VM.

On Windows, Dragon is a very common choice for speech control. Indeed, it's been the only practical and affordable choice for going on two decades. Graham says Dragon users cannot activate HTML5 date inputs, because they aren't recognised as text inputs, despite looking like them. He notes that you can focus a date field by emulating keypresses with Dragon, but he fails to dictate anything into the date input field. In his assessment this is a substantial blocker.

I managed to find a video from the CSUN 2017 accessibility conference, in which someone demonstrates successfully using a HTML date input with Dragon. First, they demonstrate Dragon with Chrome. Whilst they eventually managed to enter a date, they had to jump through some considerable hoops, with a significant extra cognitive load. It involved emulating keypresses, and figuring out how much to increment a number. Key quote: "Now your forms are forcing me do math!". Next they demonstrate that it is possible to enter arbitrary text into a HTML date input in IE, transferring it from Dragon's dication box feature. It actually worked well, and it seems odd that Graham Arnfield didn't note this in his report. This CSUN '17 video reassures me a little bit; the HTML date input is very problematic for Dragon users, but it isn't a complete game-over blocker for some power users.

Aside: in this CSUN `17 demo the speaker also advocates the date parsing approach to enhance text entry.

I tried operating date fields using the Microsoft Speech Recognition built into Windows 10. With Edge 17, dictating numbers for the day/month/year worked well. On Firefox I succeeded at entering months and years, but failed to enter a year in the intended millenium. I couldn't get it to work on Chrome or IE. I surmise this may be due to it using the UI Automation API (Windows' newer accessibility API), for which Edge is the leading implementation so far. I haven't tested it with the Chromium-based Edge. The Microsoft Speech Recognition + Edge looks promising, but I'm not very familiar with all it's capabilities yet.

Review of patch #90

When the Modernizr test returns false for date input support, we add the help text so users can type the correct format. That's helpful.

However, it's still an <input type="date"> element, despite poor browser support. It accepts arbitrary text, but Dragon Naturally Speaking doesn't recognize it as a text input. As noted in Graham Arnfield's report, Dragon users need to use keyboard or mouse emulation to focus it.

When the Modernizr test returns false, can we also change the HTML input type from type="date" to type="text", so that Dragon users can focus it more easily? Likewise for the time input. I know it still works when you change the input type from text to password, and vice versa, so I'm hoping it's the same for the date and time fields.

Where next?

@xjm - You mentioned (in Slack thread, about a month ago) that if there wasn't a suitable replacement for any of the jQuery UI components, then retaining it until we have a replacement was an option. Can you confirm this? I think we are clearly in that situation. Deprecation just means announcing that it won't be available in the future, but that's separate from stopping usign it now.

I think we should consider what @catch says in #35-37, and do this just for D9. We could still backport it to D8 LTS at a later date, if needs be.

There are various mentions of addressing accessibility in follow-ups, but we still need a clear direction for those. Here are my suggestions.

1. Stop using HTML date and time inputs. As things stand currently, they just aren't fit for purpose.
   • Replace them with HTML text inputs, to provide equal access on all platforms. There is a growing consensus in the wider a11y community to treat this as the best practice baseline.
   • They don't count as "accessibility supported" technologies for WCAG conformance. If we persist in preferring them despite the known problems, that's at odds with WCAG guideline 4.1 (maximise compatibility with current user agents and assistive technology).
   • We should do this regardless of whether we have found a suitable replacement datepicker.
   • I assume this breaks the BC policy, so do it in D9.0
2. Continue working to find a more accessible datepicker. Provide a button adjacent to the HTML text input, so invoking the datepicker is optional (i.e. text entry would still work). The prototype that @bnjmnm made following the OpenAjax demo sounds encouraging (I haven't tested it yet).
3. Investigate the smart-parsing approach, as a possible enhancement to improve text entry. This is something that is gaining popularity as an idea in the a11y community, but so far I'm not aware of any off-the-peg library or framework that provides it. The demo from Adrian Roselli is a good starting point. If it works out, we'll have a fancy leading edge accessibility approach. I'm curious whether there could be any localization issues.

Points 2 and 3 here aren't mutually exclusive. They could both be used at once, or treated as Form API and/or FieldWidget options. They could be developed in experimental modules, like the approach to replacing the jQueryUI autocomplete.

@andrewmacpherson thanks for doing that review, this is really useful.

I think we should consider what @catch says in #35-37, and do this just for D9. We could still backport it to D8 LTS at a later date, if needs be.

So if we do this, the 8.x version of the patch would be just adding the deprecation to the library definition, and adding the deprecation to the list of suppressed deprecations. This means 9.x and 8.x diverge, but no more than 8.7 and 8.8 will diverge with a full backport of the complete patch here. Seems like a good approach to me.

@xjm - You mentioned (in Slack thread, about a month ago) that if there wasn't a suitable replacement for any of the jQuery UI components, then retaining it until we have a replacement was an option. Can you confirm this? I think we are clearly in that situation. Deprecation just means announcing that it won't be available in the future, but that's separate from stopping usign it now.

That issue is #3087685: Remove deprecated jQuery UI components and fork remaining source code into core which forks components for Drupal 9 that we don't think we can replace in time. While it's an option here, it's a desperate option IMO and I would prefer to go ahead with this patch (in 9.x only based on your comments) then have the follow-ups to improve on the 9.x status quo. This has no bearing on continuing to use components in 8.x (especially with this issue, but we're also trying to make autocomplete replacement optional in 8.x via an experimental module).

1. Stop using HTML date and time inputs. As things stand currently, they just aren't fit for purpose.
Replace them with HTML text inputs, to provide equal access on all platforms. There is a growing consensus in the wider a11y community to treat this as the best practice baseline.
They don't count as "accessibility supported" technologies for WCAG conformance. If we persist in preferring them despite the known problems, that's at odds with WCAG guideline 4.1 (maximise compatibility with current user agents and assistive technology).
We should do this regardless of whether we have found a suitable replacement datepicker.
I assume this breaks the BC policy, so do it in D9.0
2. Continue working to find a more accessible datepicker. Provide a button adjacent to the HTML text input, so invoking the datepicker is optional (i.e. text entry would still work). The prototype that @bnjmnm made following the OpenAjax demo sounds encouraging (I haven't tested it yet).
3. Investigate the smart-parsing approach, as a possible enhancement to improve text entry.
Points 2 and 3 here aren't mutually exclusive.

These are all definitely worth looking at and we should open follow-ups for each, and a meta to link them together, and the 2 + 3 approach could be really nice.

#99

Note however, that with the patch here you don't actually have a HTML text input in IE11. It's still a HTML date field

It's correct that the input is still type="date" but IE11, Safari and other browsers that do not support type="date" will fallback to using a text input.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date

#99

When the Modernizr test returns false, can we also change the HTML input type from type="date" to type="text", so that Dragon users can focus it more easily? Likewise for the time input

I'm not able to test Dragon either so I can't confirm that this will help but it seems like a good suggestion.
The patch in #102 sets an input type="date" to type="text" for browsers that do not support date.
Tested in both Safari and IE11 with no change in behavior and if this will improve focus in Dragon it is a +1 from me.

Related, do we need to update Drupal's list of supported browsers to include screenreaders, and other assistive software like Dragon?
It would be helpful to have a known list to test against.

This CSUN '17 video reassures me a little bit; the HTML date input is very problematic for Dragon users, but it isn't a complete game-over blocker for some power users.

Watching this I could understand the frustration with dictation, however just making dication easier with a plain text field may not actually help- the dictated date could fail validation since it might not match the format the input expects.

#99

Using the UA datepickers over the jQuery UI datepicker results in a significantly diminished accessibility too. It's the most accessible datepicker we've found to date.

The UA native datepickers are already a broken screenreader experience, particularly on mobile. We're at fault for preferring them over HTML text inputs.

The implication here is that browser provided datepickers are much worse than the jQuery UI datepicker, or even a plain text field.
I'm not sure that is true, for example in Chrome: the datepicker calendar can be opened with a keyboard (option down arrow on mac) and fully navigated with keyboard, while the jQueryUI datepicker cannot be focused at all that I could tell.
It does respond to some key commands like page up/page down while the input is focused but I wasn't able to "pick" a date with it.

The way Drupal uses jQuery UI datepicker differs from the way the Deque demo uses it.

This is an important distinction, Deque used the jQuery UI datepicker as a "starting point" and then heavily modified it.
see: https://dequeuniversity.com/library/aria/date-pickers/sf-date-picker

Additionally, the OSX screenreader reads each "part" of the date in Chrome. For example when selecting just the month. It's not even necessary to open the calendar widget.
I've only tested iphone with voiceover, but the same applies- the datepicker UI only works because of the date attribute.
This was also the experience with the Dragon user in the CSUN video. while incrementing across each part of the date was cumbersome it eventually produced a valid input, unlike a plain text field which doesn't enforce formatting.

The formatting issue was also pointed out in #98. A plain text field does nothing for localization- a big reason we added the additional placeholders and help text.

1. Stop using HTML date and time inputs. As things stand currently, they just aren't fit for purpose.

I think whatever shortcomings browser UI for date inputs has it would be a massive step backwards to replace date and time input types entirely.
I'd support opening a Drupal 9 follow-up to continue that discussion.

#100

So if we do this, the 8.x version of the patch would be just adding the deprecation to the library definition, and adding the deprecation to the list of suppressed deprecations. This means 9.x and 8.x diverge, but no more than 8.7 and 8.8 will diverge with a full backport of the complete patch here. Seems like a good approach to me.

This is certainly an option, to just mark core/jquery.ui.datepicker deprecated, then move this work to a new D9 issue.

I'm in favor of this patch as it is for Drupal 8 since it removes the jQuery UI datepicker usage entirely. I mentioned in #84 this a performance improvement for all the browsers which never use it at all.
For browsers that don't support date inputs this patch also has improvements including placeholder text and additional aria-descriptions which were not in place before.

But- I would be happy to see this patch split up if it means getting the deprecation committed.

This is certainly an option, to just mark core/jquery.ui.datepicker deprecated, then move this work to a new D9 issue.

I was suggesting committing the whole patch to 9.x, but only the deprecation to 8.x - on the basis that we definitely don't want to support jQuery UI datepicker in 9.x and that @andrewmacpherson thinks the patch as it is is fine, just more to do in general.

I created a D9 issue #3090244: Deprecate jQuery UI datepicker in Drupal 8
postponed on this issue.

I was suggesting committing the whole patch to 9.x, but only the deprecation to 8.x

This patch for 8.9.x now has only the deprecation and the deprecation warning suppression.

I think that makes sense, I updated that new issue #3090244: Deprecate jQuery UI datepicker in Drupal 8
and changed the title for this issue and marked it postponed. I'll post the patch from #105 there.

To get this issue focused here again I closed #3090244: Deprecate jQuery UI datepicker in Drupal 8 as a duplicate.

The patch in #90 was RTBC for 8.x, and some additional accessibility improvements were added in #102 per @andrewmacpherson suggestion in #99.

3090244 #9

What I thought should happen was that we'd commit the 9.0.x patch to 9.x first, then the deprecation to 8.9.x/8.x immediately afterwards in the same issue (a smaller version of the 9.x patch which doesn't actually remove the library either).

If I'm understanding @catch correctly what we need now is a version of 102 for 9.x which includes all the same changes, except removes the deprecated files and mentions of datepicker.

This patch is identical to the one in #102 except rolled against 9.0.x and removes:

• core/jquery.ui.datepicker from core.libraries.yml
• datepicker files from core/assets/vendor/jquery.ui, including the i18n folder
• references to datepicker in jquery.ui, seven and claro css
• deprecated locale.datepicker asset library and files
• comments in core/lib/Drupal/Core/Datetime/Element/Datetime.php and core/lib/Drupal/Core/Render/Element/Date.php

Re-reading the previous posts, I think I may have misunderstood how the 8.x patch should look, and that instead of #102 it should be more like #105, with just the deprecation messages and the warning suppression.

In #105 I missed the locale.datepicker asset library in locale.libraries.yml.
This patch fixes that omission and also points the deprecation message to the change record instead of this issue.

could you re-upload the 8.x and 9.x patches so they are in the same comment, and change the filenames so it's clear which version they're intended for?

Happy to, I agree this issue is getting confusing!

Patch in #108is meant for Drupal 9.x, renamed to d9-datepicker-remove.patch
Patch in #109 is meant for Drupal 8.x, renamed to d8-datepicker-deprecate.patch

Patch in #109 and the copy in #111 failed because of the deprecation warning- I updated the url in the deprecation only but not in getSkippedDeprecations.

Just to clarify I would have committed #102 and #105 as-is, with the actual removal happening in a follow-up, but #112 with the removal in 9.x and #113 with the deprecation seems good too.

The reason I got so confused on the other issue is that we need to have the replacement (i.e. the UX improvements in #112) before we deprecate in 8.x, otherwise 8.x is deprecating 'optimistically'.

To maintain the discussion for improving things further, I think a new issue, but with a long issue summary referencing comments here, would probably be clearest.

Moving to RTBC, a +1 would be useful here so I can also commit it (but given this was RTBC for a long time and the changes since are small could probably commit it later anyway).

Cool, the patches indeed seem to be split out as desired: the 9.0.x patch removes the library entirely, and the 8.X.x patch notifies people of the deprecation.

Committed and pushed d9-datepicker-remove.patch to 9.0.x; Committed and pushed d8-datepicker-deprecate-113.patch to 8.9.x and 8.8.x. Whew!! Thanks for everyone's hard work here!

#100 - I'll open follow-ups for improving accessibility of date and time inputs. I expected "stop using HTML date and time inputs" would be controversial. I don't think we have any other choice, if we're serious about WCAG.

#102 - Thanks, that small change should be a big help for Dragon.

#103:

It's correct that the input is still type="date" but IE11, Safari and other browsers that do not support type="date" will fallback to using a text input.

The combination of IE11 and Dragon is clearly doing something with date inputs, per Graham Arnfield's testing notes, and the CSUN '17 demo video. Whether it's IE11 or Dragon at fault doesn't really matter.

Related, do we need to update Drupal's list of supported browsers to include screenreaders, and other assistive software like Dragon?
It would be helpful to have a known list to test against.

I started writing a response about that, but it was getting a bit long. I've put it in #3093171: Should there be an official list of assistive technology supported by Drupal core?, rather than bury it here at the end of a fixed issue. Short answer: I don't think it's practical; it's a very different situation to browser support.

publish the cr