react-datepicker is not accessible

[afercia]

Looks like react-datepicker, currently used for the "publish" date, has several accessibility issues.

Just to mention a few:

• not operable with a keyboard
• empty and not focusable prev/next month links
• day names not in relationship with the day numbers
• arguable values for the day aria-labels, e.g. day-15
• missing labels for the hour/minutes fields

I was also able to break it completely just editing the hour/mins fields using a keyboard:

I'd strongly recommend that every external component/library included in Gutenberg should be picked up taking into consideration also its accessibility support.

Not sure react-datepicker can be easily patched and made decently accessible. It would likely require a lot of work. Not sure if other, more accessible, react date-pickers exist. Not sure if using a date-picker is a good idea in the first place 🙁 Date pickers are always tricky.

One option could be considering a completely different UI, without a date-picker. Happy to evaluate other, more accessible, tools if any, but I'm afraid react-datepicker in its current state doesn't meet the quality standards we'd like to see in WordPress and it's a blocker for accessibility.

/cc @jasmussen and @joedolson (as he's an expert about calendars)

[afercia]

Also to mention: AM/PM: not all countries in the world use them.

[joedolson]

AM/PM would definitely get a lot of pushback and require a localized UI for alternate date/time formats.

I don't have a great solution for datepickers - they are truly difficult to make predictable. One solution I've favored is to allow manual string entry of dates and times, so that the datepicker is an optional UI; but even as an optional UI I would need it to be accessible; I'd just be less concerned about the complexity of the interaction patterns from the keyboard.

[aduth]

Is there any use of date pickers elsewhere in the admin (I've assumed not), or an audit of available solutions and their accessibility?

In another of my own projects, I've integrated Flatpickr with React successfully, and know it is at least keyboard operable and opens in response to receiving focus, but on a cursory glance lacks some labeling.

Another option is to create a homegrown solution built with accessibility in mind.

[joedolson]

I can't recall running across a datepicker anywhere. The jQuery datepicker is something that's in the set of scripts bundled with WordPress by default, but I'm not aware of a core usage of it. I'm not sure of the current state of accessibility in that script, but it wasn't satisfactory when I last assessed it. That was over 2 years ago, however.

I've used Pickadate myself, but it's lacking any stable project maintainer at the moment, so probably not viable.

Here's the only information I know about accessible date pickers.

[afercia]

The jQuery UI datepicker was recently properly localized, see https://core.trac.wordpress.org/changeset/37908. RTL support is also a concern. I'm not aware of any core usage, best persons to ask to: @ocean90 and @swissspidy

[youknowriad]

AM/PM: not all countries in the world use them.

It's only activated depending on the time format defined in the general settings

[swissspidy]

The jQuery UI datepicker is currently not used in core. It‘s only localized for plugins using it.

[afercia]

Related discussions on core Trac:

Add jQuery UI's datepicker() where applicable
https://core.trac.wordpress.org/ticket/7665
(main discussion about jQuery UI's datepicker)

Use JS Calendar control for date picking
https://core.trac.wordpress.org/ticket/11942
(closed as duplicate but helpful to understand why at that time jQuery UI was not used)

Edit published date of post - inputs with no labels
https://core.trac.wordpress.org/ticket/25461
(more related to a11y)

Also to consider:

"Now" button for current date in update post published date and time
https://core.trac.wordpress.org/ticket/14364

Publish Date DatePicker
https://wordpress.org/plugins/publish-date-datepicker/
Plugin that adds the date picker to the UI

[afercia]

Marking with the high priority label to indicate it's an a11y priority. At the very least, there should be an alternative way to enter a date using only a keyboard.

[aduth]

Couple options to consider:

• The react-dates component maintained by Airbnb claims by its description to be accessible, and offers options for a familiar date-picking experience to what we have currently
  • Unsure how easy it would be to integrate a time picker into this
• Maybe just <input type="date"> ?
  • Similarly, time entry would need to be a separate field

[afercia]

The react-dates component maintained by Airbnb claims by its description to be accessible

Maybe it's accessible, but it's announcing me the wrong month and days 😬 Maybe it's just a configuration issue. Hopefully. Not the best start, though.

I've run just a very quick, preliminar, test. I've navigated to a previous month (also, notice the color contrast on previous months is far from being accessible) but the wrong month/days are announced also on the initial view:

[jwold]

@afercia I'm curious if either if these datepickers would qualify as accessible:

• Whatsock Date Picker (link)
• Medium.com's date picker (the input field appears to be accessible, but the dropdown calendar is not) (screenshot)

[aduth]

@jwold The latter of those two appears to be the browser-default <input type="date"> (specifically, Chrome's).

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

[afercia]

Sorry for the very late reply. The Whatsock Date Picker one, after an initial test, seems to work pretty well with keyboard and screen readers.

[jwold]

Thanks for the followup! Glad to hear that about the Whatsock Data Picker.

[bph]

Even for those just using a mouse it's not clear how to actually get out of the date picker. What is the action that makes it disappear after successfully picking a date: Is it the date? No. Is it the time? No. Is it the pm/am? No.

The only action that makes the date picker disappear and let's me continue with my work, is clicking outside the datepicker.

[grahamarmfield]

+1 for the idea of not forcing people to use a date picker. Even if it were possible to find one that is accessible, it's a bit of an overhead for sighted keyboard users, and screen reader users.

Can we not use something similar to the publish date in the existing edit pages - a dropdown, plus text boxes, or something similar. Interacting with that would be a lot easier.

[aduth]

a dropdown, plus text boxes, or something similar. Interacting with that would be a lot easier.

This may be subjective. I've personally found the classic editor's date inputs to be cumbersome to use contrasted with other date pickers I've used (web or otherwise).

[grahamarmfield]

How about making it an either/or option? So that people can use a date picker if they want to, but don't have to.

[aduth]

How about making it an either/or option? So that people can use a date picker if they want to, but don't have to.

Seems to fall against the "Decisions, not Options" mantra.

It hasn't been raised but not addressed as of yet: How does <input type="date"> fare for accessibility and usability? That it's browser-dependent is a bit concerning, though it is native. We'd still need a separate field for time.

[aldavigdis]

I've pushed the changes I've made — and to quote the ARIA description box regarding keyboard navigation:

• Use Shift + Left Arrow or Shift + Right Arrow to navigate between weekdays.
• Shift + Up or Down Arrow to navigate between weeks.
• Up and Down Arrow navigate between time intervals.
• Page Up and Page Down naviagte between months. End and Home navigate between years.
• Press enter to select the highlighted date and time.

Ergo, the user now needs to hold down shift to navigate within the calendar, as navigating horizontally would break the expected behaviour of input boxes. Pressing up and down directly navigates within the time picker instead now (which is a new feature that was a bit tricky to implement).

The changeset is at aldavigdis/react-datepicker@768dcea, but do expect me to do a force push a couple of times today as there are some broken tests and typoes — and I haven't run eslint yet.

[aldavigdis]

So, I'm keeping the PgUp/PgDn and End/Home functionality, sans the shift key. It could be replaced with more complex modifier key combinations, but I guess people with less than four arms/tentales may be at a disatvantage there.

[afercia]

@aldavigdis thanks very much for diving into this, very appreciated.

Worth considering the date picker used in Gutenberg is set up as the "inline version" example, see https://reactdatepicker.com/#example-36 that means there's no input field. Even if we change the configuration to add the input field, then the keydown event (which is attached to the input field...) would kick in producing the conflicts you mentioned above. Allowing the left and right arrow keys to operate normally is a first step but then we should also allow other native, standard, key strokes that normally work within input fields, like home and end (e.g. Cmd + left/right on a mac), partial selection (e.g. Shift+Alt+left/right on a mac) etc. I guess that would be a bit complicated, as the root issue here is react-datepicker is inherently flawed as it alters native interaction with the input field.

Regardless, even if we're successful in improving a bit keyboard interaction, there are many other accessibility issues, especially when assistive technologies come into play. For example, the keydown event works with screen readers on Windows because, as soon as they encounter the input field, they switch to "forms mode" and stop intercepting key strokes. However, the calendar semantics is far from ideal and basically nothing useful is announced to screen reader users. Similar problems would be faced by speech recognition software users as well, as some UI controls are completely unlabelled. Even if the controls were labelled, their name should be visually apparent in some way to allow users to properly voice a command.

Overall, react-datepicker should be largely refactored to get to a minimum, decent, accessibility level and I'm not sure what the final result would be anyway.

Some screenshots after testing on Windows, with both the NVDA and JAWS screen readers:

• the previous and next buttons are unlabelled and announced just as "button"
• tabbing skips the whole calendar and jumps to the time fields
• the time fields are unlabelled, only their value is announced
• the AM/PM buttons could benefit from some more meaningful text

• using arrow keys with a screen reader allows to explore the calendar content
• the day names are just a 2 letters abbreviation, so screen readers don't get they're days (I 3-letters abbreviations would work better, e.g. Mon, Tue, Wed, etc.); right now, the day names are announced all together like it was a unique word, something like soo-mo-too-wee-t-aitch-ef-ar-sa

• the days in the calendar are announced as list because they use the ARIA roles listbox and option, which replicates the semantics of a <select> element
• unfortunately, the list is perceived by both NVDA and JAWS as an empty list, as the options are expected to be first child of the listbox element, so nothing is announced
• the days use an aria-label attribute, e.g. aria-label="day-1" I'd argue that's not so beneficial but, regardless, nothing is announced because of the previous issue

• even on the official demo, where the input field and arrows navigation through the days work, nothing is read out: screen readers announced just "blank" when a day is highlighted as DOM focus is on the input field and there's really no reason why they should announce the days (unless the whole calendar gets refactored as sort of an ARIA combobox)

I'd still tend to think the best option to make the publish date UI usable by everyone would be using a simple input field with a suggested date format (the format should change based on the user locale). This input field should be completely separated by the one used by react-datepicker so as to keep intact native interaction. Then, the time input fields could follow and after them, for users who prefer to use the date picker and are able to use it, a button could reveal the date-picker interface. I'd totally agree on trying to find a way to completely hide the "picker" UI from assistive technologies.

Besides the a11y issues, I've noticed a couple of functional issues, /Cc @mtias @aduth etc. 🙂

• WordPress has a start_of_week option in the general settings, changing that I don't see any change in the datepicker UI: the first column is always "Sunday". At a quick first glance, seems to me react-datepicker bases this on the locale instead of a specific setting
• changing user locale, just some parts of the UI get translated, not sure how the translations work on react-datepicker (see screenshot below). The day columns are always in English, not to mention the aria-labels (day and week) are not translatable because part of the string is in English and hardcoded:

aria-label={`day-${getDate(this.props.day)}`}
aria-label={`week-${this.props.weekNumber}`}

Please let me know if I should open separate issues.

[aldavigdis]

Worth considering the date picker used in Gutenberg is set up as the "inline version" example, see https://reactdatepicker.com/#example-36 that means there's no input field.

This is something I want to tackle in Gutenberg itself. Thanks a lot for bringing this to my attention, as this will be the next step in solving this ticket.

One solution may be to simply trigger the visibility of an actual <input> element when this <a> element is clicked. But as noted, that needs to happen within Gutenberg itself, not in React-Datepicker.

Allowing the left and right arrow keys to operate normally is a first step but then we should also allow other native, standard, key strokes that normally work within input fields, like home and end (e.g. Cmd + left/right on a mac), partial selection (e.g. Shift+Alt+left/right on a mac) etc.

I decided to utilise shift as a modifier key for navigating the calendar. This includes the functionality of Home, End, PageUp and PageDown. Alt and CMD/ctrl are often tied to OS-level functionality when used with arrow keys.

However, the calendar semantics is far from ideal and basically nothing useful is announced to screen reader users.

I added relevant WAI-ARIA tags and I do hope that will solve some of the issues you are describing here. This includes aria-live for the input field, to announce changes. If an input field is not used by Gutenberg, then that tag could be added to implement that functionality.

As my approach to polyfills is to move them away from the screenreader users and to allow for form elements to be filled manually, I have also added aria-hidden to the calendar popper, which takes the datepicker itself out of the screenreader context. (Oh, wait — that brings up a new problem, if there is no actual input field in use, but I may have a solution.)

the previous and next buttons are unlabelled and announced just as "button"

I added content to those buttons, which can be set using the navigationNextText and navigationPreviousText. The default value is Next month and Previous month. I have also improved the contrast those buttons had with the white background.

tabbing skips the whole calendar and jumps to the time fields

In the current version of React-Datepicker, the time is displayed using a list on the right-hand side of the calendar. My approach here is to allow users to tab out of the text field and into the next one. Keyboard navigation will also work with the time selector, so it may cover the issue.

the day names are just a 2 letters abbreviation

I have attempted to fix this by creating <abbr> tags with the full date name as the title. After going over this, I may want to add text nodes here with nothing but a space in them to simulate separation as the calendar is rendered using a collection of <div> elements, instead of being a <table>.

A fundamental (and a really annoying) problem with React-Datepicker is the fact that the calendars are not treated as tabular data. The date pickers I've worked on in the past have generally used <table> elements for the calendar itself, with a <thead> with <th> elements as the list of weekdays.

Regardless, as the date picker is no longer visible to screen readers in the current PR, this may be redunant. I still want to explore the option to make the visibility optional, but this requires snaking through a chain of React components. I may add this to a separate PR to React-Datepicker.

Besides the a11y issues, I've noticed a couple of functional issues […]

Sounds like something that should be added as a separate issue ticket. Perhaps reffering this ticket would be a good idea too, so I could work on it after this one (given the capacity of course).

---

Furthermore, I know there was some dicussion about this on Slack, but unfortunatly, I wasn't there, with the reason being I need to migrate to a new WordPress.org user before joining there again, so I can keep a consitent username and apperiance on all communication channels.

[aldavigdis]

I'll dive into the Gutenberg codebase by tomorrow. Will also install a proper screenreader on a Windows partition to explore more things.

[afercia]

@aldavigdis thanks so much.

I added relevant WAI-ARIA tags and I do hope that will solve some of the issues you are describing here. This includes aria-live for the input field, to announce changes.

Maybe I'm missing something but if we hide the whole date picker from assistive technologies then why to use aria-live on the input field? Ideally the input field should behave in a native way, its value would be read out when tabbing into it (content gets selected automatically ) or when typing, character by character.

In the current version of React-Datepicker, the time is displayed using a list on the right-hand side of the calendar. My approach here is to allow users to tab out of the text field and into the next one. Keyboard navigation will also work with the time selector, so it may cover the issue.

Yep, I've seen the list on the right, however in Gutenberg the time fields are implemented differently:

A fundamental (and a really annoying) problem with React-Datepicker is the fact that the calendars are not treated as tabular data.

Yeah... there's no programmatic relationship between days and numbers, however as you said this may be pointless if we hide the whole calendar from assistive technologies.

Thanks again, looking forward to see the improvements.

[aldavigdis]

this may be pointless if we hide the whole calendar from assistive technologies.

I like to hope this is just the beginning of further improvement of the library. My contract is expiring really soon and after I realised converting the calendars to being laid out as tables would be the most appropriate way of making the date picker itself "sustainable", I also realised it would be a very time consuming process as well.

I'll be examining the implementation in Gutenberg more closely today and once I've finally made a pull request on here, I would like to bring my attention to the HTML semantics of React-Datepicker insha'Allah.

[grahamarmfield]

Replying to @aldavigdis.

Whilst using the tag with title on the day names to indicate an abbreviation should be a good answer, the reality is that screen reader support for is patchy. I did a (less than) scientific survey for this blog post: https://openinclusion.com/blog/presenting-abbreviations-acronyms-for-screen-reader-users/

You also talk about the desirability of having each month marked up as a table. I think that's right, but having elements as column headers is going a bit extra. We'd need to test how that worked...

[grahamarmfield]

My comment rendered slightly less easy to understand by HTML being stripped out - apologies.

The missing word is abbr - both times.

[aldavigdis]

I am honestly starting to think that implementing drop-down menus instead of an athetiscally pleasing date picker is the best way to get this right.

[grahamarmfield]

@aldavigdis said:

I am honestly starting to think that implementing drop-down menus instead of an athetiscally pleasing date picker is the best way to get this right.

Perhaps I'm biased after accessibility auditing so many sites, and seeing people trying to use them, but I'm having problems with seeing date pickers as pleasing in any way.

Seriously though, having 3 dropdowns or text boxes for date, and 2 for time is going to be a lot easier a) to implement and b) to use for many people.

The current editor defaults to publish immediately, and only shows dropdowns and text boxes if I wish to edit that. Then the values default to 'now'. There's an OK button which then 'fixes' the publish date/time.

Can we not use the same model in Gutenberg?

[aldavigdis]

We are on the same page here @grahamarmfield.

Perhaps I'm biased after accessibility auditing so many sites, and seeing people trying to use them, but I'm having problems with seeing date pickers as pleasing in any way.

You are absolutely correct here.

Having dug very deep into this, I am getting to the conclusion that date pickers, while perhaps asthetically pleasing are not very useful, unless they provide additional functionality. The WAI working group has even removed any references to date pickers from their current version of the WAI-ARIA Best Practices document.

Unfortunatly, a lot of other information I have gathered uses the outdated version as a primary reference.

While date pickers may provide visual cues, I can conclude they should only be used as a seccondary option, after proper forms and input fields.

Seriously though, having 3 dropdowns or text boxes for date, and 2 for time is going to be a lot easier a) to implement and b) to use for many people.

This is what I have concluded too. Having input fields with proper labels, just as in the classic WordPress editor should be good enough.

The current editor defaults to publish immediately, and only shows dropdowns and text boxes if I wish to edit that. Then the values default to 'now'. There's an OK button which then 'fixes' the publish date/time.

My mistake was to assume the main issue was with how the date picker widget itslef operated internally. In other words, assuming that the main issue was with the React-Datepicker library, but not how it was implemented in Gutenberg and Calypso.

In essence, what I'd like to do is to use form fields by default. I am okay with displaying a date picker along with that as a visual indicator, but keeping it outside of the screenreader context and tab index.

What I have done with React-Datepicker is really only a stop-gap measure.

I did a write-up on this, which is available as a blog post at https://aldavigdis.wordpress.com/2018/06/24/we-need-to-talk-about-the-accessibility-of-date-pickers/.

I will see if I can keep on working on this into this week. But it also means I need to ballance this with some contract work.

[aldavigdis]

Dear all — a pull request has been submitted based on this issue ticket: #7621

[tofumatt]

Oh, the new date-picker is much more accessible. I'm closing this as we aren't using react-datepicker. Closed by #7621, which I thought closed this in the text but just referenced it. 🤷‍♂️