WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible jQuery UI DatePicker

for

From: Bryan Garaventa
Date: Sep 30, 2013 1:07AM

Does this article reflect the current jQuery UI, or improvements that are
supposed to be implemented down the road?

If it reflects the current widget library, then this article is somewhat
misleading.

For example, the article says:

$('#datepicker').datepicker({
showOn: 'button',
buttonText: 'Launch Date Picker'
});

"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."

If this process reflects the same implementation at
http://jqueryui.com/datepicker/#icon-trigger
You will notice that the icon is not keyboard accessible, and doesn't have
any textual equivalents for screen reader users.

Also, the article says:

"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."
"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."
"Add the messages you have built to this region, and screen readers will
read them to users as they are shifting around the datepicker."

So basically, the idea is to activate the icon from the keyboard which will
then set focus to the edit field as the calendar opens. Then, while focus is
on the edit field, you should control the calendar date you want using the
keyboard, then select the date you want in the field.

Besides presenting significant announcement issues for screen reader users
as indicated in the article, this also presents significant keyboard
accessibility issues such as for those using voice navigation software.

For example, the only way to control a calendar while the edit field has
focus, is to set key event handlers on the field to capture keystrokes such
as the arrow keys, pageup and pagedown, home/end, alt+pageup/pagedown, and
so on, which may already be part of the scripting; it's hard for me to tell.

If you are capturing the arrow keys however, and you have need to edit the
content of the field, you won't be able to do so.

Also, simply sending the text to a live region to announce the current date
will result in the screen reader announcing "edit" for every keystroke
associated with that field when attempting to change the calendar date.

The conclusion of the article states:

"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."

If it is necessary for developers to build custome accessibility solutions
within a UI widget as provided out of the box simply to ensure
accessibility, then it can't actually be called an accessible date picker.




----- Original Message -----
From: "Jennifer Sutton" < <EMAIL REMOVED> >
To: "WebAIM Discussion List" < <EMAIL REMOVED> >
Sent: Thursday, September 26, 2013 1:05 PM
Subject: [WebAIM] Accessible jQuery UI DatePicker


>I thought I'd pass along this link for those who may be interested in
> building and testing this date picker.
>
> Accessible jQuery UI DatePicker
> <http://www.deque.com/accessible-jquery-ui-datepicker>;http://www.deque.com/accessible-jquery-ui-datepicker
>
>
>
> I wonder if it would work for those who use Dragon Naturally
> Speaking, or other similar software.
>
> I worry that some of the work with JQuery could become so screen
> reader-centric that other disabilities may not be addressed.
> But I'm confident that those who will be involved in the upcoming
> event will consider all access needs, as much as possible.
>
> Best,
> Jennifer
>
> > >