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.
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?
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
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
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.
- WAI-ARIA Authoring Practices 1.0: This is the outdated version from 2009.
- AccDC: ARIA Date Picker (Basic): This is an example of an accessible date picker using table semantics and keyboard navigation.
- ReactJS Datepicker examples — This is the date picker used in Gutenberg
- react-day-picker Documentation — This is the date picker used in Calypso
More to come
I will follow up on this with separate posts with code examples and probably some wireframes as well.