We need to talk about the accessibility of date pickers

This is my report as I am finishing my one-month trial period here at Automattic.

As my project for this month, I was handed a ticket to fix accessibility issues with the date picker used in Gutenberg. This is an issue that creeps over to other projects, namely Calypso.

Fixing accessibility issues that have already made it to a product requires careful coordination and planning, perhaps more than the capacity of a couple of weeks working part-time would allow for; including the focus shifting, so that’s why I am writing this blog post.

We can compare this to building an office tower before adding lifts and wheelchair ramps, which could have been accounted for right at the design phase.

What has already been achieved?

Right now, I have a pending pull request for the React-Datepicker project. This is the datepicker component used in the current master branch of Gutenberg. The PR does cover some issues regarding the default implementation of React-Datepicker:

Keyboard navigation has been improved. Now, the user needs to hold down the shift key while using the arrow keys as well as PgDn, PgUp, End and Home to navigate the calendar. This prevents the component from hijacking expected behaviour.

An aria-live tag is now used to update screenreader users about an updated date and time value in the associated input box. This however does not affect how React-Datepicker is implemented in Gutenberg.

There are also additional WAI-ARIA tags used for associating headings and to indicate roles of certain elements.

What has not been fixed however is one if the fundamental accessibility issues with React-Datepicker — namely how the calendar dates are arranged as a series of div elements instead of something like a table. This results in an awkward navigation experience when using an inline datepicker for those using screenreaders and others that may depend on any other kinds of assistive devices.

What has to be noted too is that a pending pull request does not ensure that the changes make it upstream to the official build of React-Datepicker.

How are date pickers implemented in Gutenberg and Calypso?

Screenshot showing the date picker
This is how the date picker is displayed in Calypso. The difference between this and how it is displayed in Gutenberg is not big enough to justify another screenshot. As can be seen, the workflow depends on selecting a date from an inline calendar and the user is not offered to use form fields as a default option.

Looking at the development branch of Gutenberg on one hand, and then Calypso running on WordPress.com on the other, we are using react-day-picker in Calypso, which has been replaced by React-Datepicker in Gutenberg without a clear advantage to either implementation.

As the ticket was associated with Gutenberg only, I did not check Calypso immedietly to see the difference until after discussing the issues I was facing with other team members.

In the editor, the date pickers are located in the sidebar, under the Status section in both Calypso and Gutenberg on one hand and then as a sub-widget of the “Publish…” button in Calypso’s header section.

In both cases, the date pickers are implemented in inline form along with a custom time picker — both inside a custom popover widget.

What needs to be done?

Coordinate between Calypso and Gutenberg

There needs to be an aggreement about which date picker component is to be used in both Calypso and Gutenberg. I would be happy if we would keep react-day-picker accross both project and migrate away from React-Datepicker, even if some work has gone into improving the accessibility of React-Datepicker.

Consider the date picker an alternative to input fields

A photograph of a hand-drawn UI wireframe for a date picker
An example of how I envision a more accessible date picker in Calypso and Gutenberg. This is a hybrid of how it is implemented in the classic WordPress editor on one hand and Calypso and Gutenberg on the other.

Instead of depending on an inline datepicker, proper input fields and relevant labels should be provided. I envision this to be similar to how things are done in the classic WordPress editor; with a series of inputs each representing an element of the date and time.

This also assists those who require the use of a keyboard or even those who need to publish multiple blog posts quickly without any programming skills. (This may sound illogical, but some people have surprisingly complex workflows.)

Remove the date picker from the screenreader context and tab index

Let’s face it — there are no properly accessible date picker components available, and even if there were, they would be hard to navigate due to the screenreader swtiching from forms mode to virtual or application mode.

As long as the user is able to enter a valid date using a series of input fields, the date picker can be removed from the screenreader context by using the aria-hidden attribute.

Another reason to remove a date picker widget from the screenreader context is that fact that it does not add any other functionality than to ensure the validity of an entered day. (It would be another story if this was a price or availability calendar for example.)

Removing the calendar from the tab index by setting the tabindex attribute to a negative integer (such as -1) as well does the same for those depending on using keyboard navigation.

This, in combination with implementing input fields will essentially remove any screenreader-related issues and most other issues related to accessibility.

Further reading and examples

A lot of the literature about accessible date pickers that can be found online is based on an old version of the W3C‘s WAI-ARIA Best Practices document. The current version of the same document does not indicate anything about datepickers specifically.

React-Datepicker and other such widgets do take a lot from this former recommedation; especially keyboard navigation, but as the recommendation has been withdrawn, it may be a sign of W3C‘s ARIA Working Group considering date pickers to generally be an accessibility hinderance.

More to come

I will follow up on this with separate posts with code examples and probably some wireframes as well.

4 thoughts on “We need to talk about the accessibility of date pickers

  1. Hello,
    As a person who uses assistive technology & as an accessibility consultant I believe that I need to have the same user experience like everyone else. Making the date picker hidden or providing tabindex=-1 is hack & doesn’t provide the person with disability with same user experience. I strongly believe that the date picker must be made accessible & usable to all user groups.

    Liked by 1 person

    1. I agree as long as the date picker component in use is fully accessible, but I would say that most of the ones that are aesthetically pleasing to the eye are not. I think the AirBnB one is the best one so far and that it should be implemented across both Calypso, Gutenberg and other similar projects as a long term solution.

      Thanks for dropping by. I’m subscribing to your blog!

      Liked by 1 person

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.