Criteria for accessible datepickers
- Don’t force people to use the datepicker. Make it possible to write directly in the input field as well. And make sure the required format is specified in the label.
- Make it possible to navigate with a keyboard (here is where most fail). For example by tabbing to the calendar and using arrow keys to pick the right date.
- Don’t hide the calendar button from screen readers. We’ve met a few clients who considered setting aria-hidden=”true”, forcing screen reader users to input directly in the text field. But that’s not a great idea. Some screen reader users use a combination of sight and screen reader, so hiding the calendar button and calendar view for screen readers will harm their user experience. Make the actual datepicker accessible instead.
- Make sure that the buttons and icons in the calendar view have proper labels so that they get correctly read by screen readers. For example, the dates of the month should not just be “1”, “2″ etc. They should be read “1 January, Thursday” or something similar. You can use aria-label for this.
Examples of accessible datepickers
Here are a few accessible datepickers that fullfil the criteria above that you can get inspired by:
WebAxe have some more examples in their article Accessible Date Pickers (webaxe.org).
Get notified when we write new stuff
About once a week we write an article about accessibility or usability, that’s just as awesome as this one (#HumbleBrag)!
Or simply drop your email below!