Accessible jQuery UI DatePicker

Today’s post is from Chris McMeeking, a software developer at Deque.  Prior to working with Deque, Chris ran his own company dedicated to making mobile devices accessible for children with cerebral palsy.  “I’ve always been intrigued by using technology to bridge the gap for those less able. Technology can be part of the solution, as long as we don’t allow it to become a growing part of the problem.”

An accessible datepicker is a very complex topic in the world of accessibility: datepickers have a lot going on.  In accessibility we are always worried about a few main categories: perceivable, operable, understandable, and robust.  In some circumstances we can ignore some of these categories.  There is a certain amount of inherent robustness in an “alt” tag, and links are inherently very operable, for example.  However, with a datepicker, every one of these categories is a consideration, and supporting all of these categories is not trivial.  This is where having a strong starting point like the jQuery UI Datepicker comes in.

How it Works

Before we talk about the accessibility of the datepicker, let’s quickly cover how it differs from other datepickers.

Figure 1

Figure 1 is an instance of the jQuery datepicker.  There are three things I want you to note.  First is the red highlighting around the 20th of September, which simply depicts the current day.  The second is the black box around the 19th.  This portrays the current selection.  Notice, however, that this is NOT the object that has “focus”.  This brings me to my final point: the jQuery Datepicker never gains focus.  The input field to which it is attached maintains focus (see the light blue highlighting in figure 1).  It is this element that the keyboard handler becomes attached.  This element receives keyboard events, which the datepicker then translates into actions on the appropriate dom elements to highlight the various elements.  Other datepickers I have worked with have sent focus into the datepicker, or even on the individual elements of the datepicker.  I believe the decision to keep focus on the input field rather than the datepicker dom elements itself is an excellent decision, and with the proper attachment process, makes creating a truly accessible experience much easier than the alternatives.

Typical Attachment Process

Under the standard use case scenario the jQuery datepicker simply gets attached to some input field like so:

This will attach a datepicker to a field with the ‘datepicker’ id.  Typically this would be a text input field.  The datepicker then becomes visible when this field gains focus.  This scenarios presents two accessibility issues: one minor, and one major.  The first is dynamic content.  Having things happen automatically on focus is problematic.  The second issue touches back to what we discussed a while ago, and that is that the items in the datepicker never receive focus.  As such, attaching them to a simple text field doesn’t do.  We need something more advanced in order to communicate the status of the datepicker to screen readers.

A11y Attachment Process

In order to make the jQuery Datepicker accessible we need to take care of the issues above.  The first issue can be fixed fairly simply by changing the way we attach the datepicker.  Instead of simply attaching it to the text field we can do the following:

The above code will create a button which will launch the datepicker, and associate the input field with the ‘#datepicker’ field, which should still be a text field.  Thus the date picker is launched by interacting with the button labeled by buttonText, next to this field.  This is much more a11y friendly.

In order to fix the second problem we need to think a little outside the box.  Remember, that the jQuery Datepicker does not shift focus to the datepicker dom.  However, we can detect that it is updating.  Attach a listener to the dom elements of the datepicker that look at the day, month, and year values that are currently highlighted.  You can build this message like this for example:

Once you have this message we need to send it to an aria-live region, potentially even the same text field that the datepicker is attached to.  An example html markup for this would be the following:

Add the messages you have built to this region, and screen readers will read them to users as they are shifting around the datepicker.


The jQuery UI Datepicker has done a lot of the work of creating an accessible datepicker for you.  In particular the keyboard handler works very well.  As long as we attach it our web pages correctly and ensure that our html markup has some way of communicating the current date with screen readers, we should have a completely accessible solution.

update selasa

Comments 8 responses

  1. I’m new to JavaScript and JQuery. Could someone post a working example please? That would help me a lot for further work… :-}

  2. i used jquuery forks great in desktop firefox …but the same dosent work fine in samsung tab firefox browser..

  3. On select does not accomplish the same thing though. On Select only fires when you hit enter. We want to fire our event every time the user focuses a new date, so that the screen reader will tell them which date they are on. Only telling a user they have selected a day is not very useful.

  4. It looks like the missing example is something like this: $(‘#liveRegion’).html(message);

  5. I implemented onChangeMonthYear so that it reads when switching months. But what do I use to have it read when switching days? There isn’t onChange or onChangeDay.

Leave a Reply

Your email address will not be published. Required fields are marked *