E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 12 (In chronological order)

From: Jennifer Sutton
Date: Thu, Sep 26 2013 2:05PM
Subject: Accessible jQuery UI DatePicker
No previous message | Next message →

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

From: Bryan Garaventa
Date: Mon, Sep 30 2013 1:07AM
Subject: Re: Accessible jQuery UI DatePicker
← Previous message | Next message →

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 ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS 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
>
> > >

From: Alastair Campbell
Date: Mon, Sep 30 2013 3:37AM
Subject: Re: Accessible jQuery UI DatePicker
← Previous message | Next message →

The article is interesting and I'm sure the techniques presented are useful
in some scenarios. However, given that the focus is never moved into the
date-picker, I struggling to see how useful it is to announce changes to
it? If it is, the issue Bryan outlined then become an issue.

When we've used a date-picker (jQuery UI or otherwise) the effort/reward
ratio of making it keyboard accessible seemed very low.

As a keyboard user, the effort of tabbing around the date-picker
(especially with multiple years available) was a big hassle. It required
many key-presses to complete a simple task. It is somewhat easier if you
have a screen reader and can use table-based navigation, but still a hassle
compared to typing in the date.

Therefore we took the approach of allowing keyboard entry on the input and
making very clear the format required. I.e. treating it as though there
were no date-picker, and applying good validation to the input. E.g.
<label for="date">Date (yyyy-mm-dd)</label><input...

From a general usability point of view the date-picker is useful if you are
using the mouse and the date you want is in the default set shown (e.g.
this month). Otherwise most people are going to find typing the date in as
easy as using date-picker, although some people will prefer to use the
mouse anyway.

But overall, if you treat it as a non-required enhancement, that seems to
be the most effective approach.

Is that what other people have done for this?

-Alastair

From: Bryan Garaventa
Date: Mon, Sep 30 2013 8:49AM
Subject: Re: Accessible jQuery UI DatePicker
← Previous message | Next message →

I understand your frustration when you say "As a keyboard user, the effort
of tabbing around the date-picker (especially with multiple years available)
was a big hassle."

Out of curiosity, did you encounter the same level of difficulty at
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Date%20Picker%20(Basic)/demo.htm
The keystrokes being:
Press the Left and Right arrow keys to navigate the row by week day.
Press the Home and End keys to jump to the beginning or end of the current
row.
Press the Up and Down arrow keys to navigate between weeks on the same week
day.
Press the PageDown and PageUp keys to navigate backwards or forwards by
month.
Press Alt+PageDown and Alt+PageUp to navigate backwards or forwards by year.
Press the Enter key to activate the selected date.
Press Escape to close the calendar without making a selection.

Back to the jQuery UI date picker, if the only way to overcome in-built
accessibility issues is to recommend that people just type the date in
manually, then it defeats the purpose of an accessible date picker.

Often the value of a date picker, is to make it easy to identify which dates
fall on a certain day of the week, which is valuable weeks, months, or years
down the road, such as when making travel plans for instance.

It's not a good accessibility solution to simply state that disabled people
should just figure it out on their own.



----- Original Message -----
From: "Alastair Campbell" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Monday, September 30, 2013 2:37 AM
Subject: Re: [WebAIM] Accessible jQuery UI DatePicker


> The article is interesting and I'm sure the techniques presented are
> useful
> in some scenarios. However, given that the focus is never moved into the
> date-picker, I struggling to see how useful it is to announce changes to
> it? If it is, the issue Bryan outlined then become an issue.
>
> When we've used a date-picker (jQuery UI or otherwise) the effort/reward
> ratio of making it keyboard accessible seemed very low.
>
> As a keyboard user, the effort of tabbing around the date-picker
> (especially with multiple years available) was a big hassle. It required
> many key-presses to complete a simple task. It is somewhat easier if you
> have a screen reader and can use table-based navigation, but still a
> hassle
> compared to typing in the date.
>
> Therefore we took the approach of allowing keyboard entry on the input and
> making very clear the format required. I.e. treating it as though there
> were no date-picker, and applying good validation to the input. E.g.
> <label for="date">Date (yyyy-mm-dd)</label><input...
>
> From a general usability point of view the date-picker is useful if you
> are
> using the mouse and the date you want is in the default set shown (e.g.
> this month). Otherwise most people are going to find typing the date in as
> easy as using date-picker, although some people will prefer to use the
> mouse anyway.
>
> But overall, if you treat it as a non-required enhancement, that seems to
> be the most effective approach.
>
> Is that what other people have done for this?
>
> -Alastair
> > >

From: Scott González
Date: Mon, Sep 30 2013 8:59AM
Subject: Re: Accessible jQuery UI DatePicker
← Previous message | Next message →

FYI: The jQuery UI Datepicker widget is currently being rewritten from
scratch and will have better accessibility after the rewrite.


On Thu, Sep 26, 2013 at 4:05 PM, Jennifer Sutton < = EMAIL ADDRESS REMOVED = >wrote:

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

From: Jennifer Sutton
Date: Mon, Sep 30 2013 9:36AM
Subject: Re: Accessible jQuery UI DatePicker
← Previous message | Next message →

Scott et al:

That's great. I hope some of Bryan's experience/comments will be
taken into account so as to be sure to include screen reader users,
those who may use only the keyboard, voice input users, etc.

I'm glad I posted this link so we could have this timely discussion,
prior to the jQuery gathering Deque is convening.

Jennifer

From: Alastair Campbell
Date: Mon, Sep 30 2013 10:00AM
Subject: Re: Accessible jQuery UI DatePicker
← Previous message | Next message →

Bryan Garaventa wrote:

> Out of curiosity, did you encounter the same level of difficulty at
>
> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Date%20Picker%20(Basic)/demo.htm


I hadn't tried that, it looks much more robust in terms of keyboard
commands, although at the moment there appears to be a bug where it
disappears on keyup? I don't think it's my setup, I tried it in
Chrome/FF/IE10.

It would be a good one to usability-test in situ, I wonder if people would
understand how to use it without instructions? Not that there is anything
wrong with the choices, but just that people will not have come across an
accessible date-picker before (1st-mover disadvantage!)



> Back to the jQuery UI date picker, if the only way to overcome in-built
> accessibility issues is to recommend that people just type the date in
> manually, then it defeats the purpose of an accessible date picker.
>

Agreed, but I wouldn't pitch it as an accessible date-picker, but an
accessible date form-control. I.e. the date-picker is a usability
enhancement that doesn't get in the way. (Worth noting that one of the
options in the jQuery UI version is to disable keyboard entry into the
form-field, which is definitely in-accessible!)


It's not a good accessibility solution to simply state that disabled people
> should just figure it out on their own.


In some cases, booking holidays comes to mind. But not all cases, e.g. date
of birth. That could involved pressing many, many buttons depending on how
old you are! Compared to typing in a date you know very well.

There seems to be two steps here:
1. Don't block people from typing in the date.
2. If useful, make the date-picker itself accessible.

Glad to hear the jQuery UI one is getting a re-write.

-Alastair

From: Bryan Garaventa
Date: Mon, Sep 30 2013 11:27AM
Subject: Re: Accessible jQuery UI DatePicker
← Previous message | Next message →

Thanks, that's great to know. Hopefully the article originally referenced
can be updated to reflect that this is occurring to prevent confusion.

----- Original Message -----
From: "Scott González" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Monday, September 30, 2013 7:59 AM
Subject: Re: [WebAIM] Accessible jQuery UI DatePicker


> FYI: The jQuery UI Datepicker widget is currently being rewritten from
> scratch and will have better accessibility after the rewrite.
>
>
> On Thu, Sep 26, 2013 at 4:05 PM, Jennifer Sutton
> < = EMAIL ADDRESS REMOVED = >wrote:
>
>> 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
>>
>> >> >> >>
> > >

From: Bryan Garaventa
Date: Mon, Sep 30 2013 11:33AM
Subject: Re: Accessible jQuery UI DatePicker
← Previous message | Next message →

Thanks for the heads up about the bug, does this happen on a particular
keystroke? I'm not able to reproduce it.

When you tab out of the calendar it disappears and sets focus back to the
triggering element. Is this what you are referring to?

I set it to do this so that, when keyboard users tab out of the calendar,
having focus move to the next active element in the tab order is typically
behind the overlay, making it unclear where visual focus is. So, by having
the calendar disappear when you press Tab, it makes it clear where focus is
at all times visually.

----- Original Message -----
From: "Alastair Campbell" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Monday, September 30, 2013 9:00 AM
Subject: Re: [WebAIM] Accessible jQuery UI DatePicker


> Bryan Garaventa wrote:
>
>> Out of curiosity, did you encounter the same level of difficulty at
>>
>> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Date%20Picker%20(Basic)/demo.htm
>
>
> I hadn't tried that, it looks much more robust in terms of keyboard
> commands, although at the moment there appears to be a bug where it
> disappears on keyup? I don't think it's my setup, I tried it in
> Chrome/FF/IE10.
>
> It would be a good one to usability-test in situ, I wonder if people would
> understand how to use it without instructions? Not that there is anything
> wrong with the choices, but just that people will not have come across an
> accessible date-picker before (1st-mover disadvantage!)
>
>
>
>> Back to the jQuery UI date picker, if the only way to overcome in-built
>> accessibility issues is to recommend that people just type the date in
>> manually, then it defeats the purpose of an accessible date picker.
>>
>
> Agreed, but I wouldn't pitch it as an accessible date-picker, but an
> accessible date form-control. I.e. the date-picker is a usability
> enhancement that doesn't get in the way. (Worth noting that one of the
> options in the jQuery UI version is to disable keyboard entry into the
> form-field, which is definitely in-accessible!)
>
>
> It's not a good accessibility solution to simply state that disabled
> people
>> should just figure it out on their own.
>
>
> In some cases, booking holidays comes to mind. But not all cases, e.g.
> date
> of birth. That could involved pressing many, many buttons depending on how
> old you are! Compared to typing in a date you know very well.
>
> There seems to be two steps here:
> 1. Don't block people from typing in the date.
> 2. If useful, make the date-picker itself accessible.
>
> Glad to hear the jQuery UI one is getting a re-write.
>
> -Alastair
> > >

From: Scott González
Date: Mon, Sep 30 2013 11:55AM
Subject: Re: Accessible jQuery UI DatePicker
← Previous message | Next message →

On Mon, Sep 30, 2013 at 11:36 AM, Jennifer Sutton < = EMAIL ADDRESS REMOVED = >wrote:

> I hope some of Bryan's experience/comments will be
> taken into account so as to be sure to include screen reader users,
> those who may use only the keyboard, voice input users, etc.


We have piles of comments from Bryan that we plan to incorporate in jQuery
UI, related to datepicker and other widgets :-)

From: David Farough
Date: Mon, Sep 30 2013 12:33PM
Subject: Re: Accessible jQuery UI DatePicker
← Previous message | Next message →

Hi Brian:
I have noticed a couple of issues which I will outline below.

1. Using Internet explorer 8 and Firefox 23, pressing enter on the
calendar button sometimes causes the calendar to quickly appear and then
disappear. I have caused this to occur both with and without Jaws 14
running. I have also noticed that when this happens, the text field
will then contain the value of the current date. It appears that the
current date in the calendar may also be picking up the enter key at
the same time as the calendar button. Does this make sense to you?
This does not seem to happen when the Jaws autoforms mode is turned on.
and turning autoforms mode off causes this to occur regularly. I can
reproduce this quite easily if Jaws is not running.

2. using chrome, after activating the calendar, if I arrow from one
date to another Jaws seems to exit applications mode and continuing to
press arrows causes the virtual cursor functionality to occur instead.

David Farough
Application Accessibility Coordinator/coordonateur de l'accessibilité
Information Technology Services Directorate /
Direction des services d'information technologiques
Public Service Commission / Commission de la fonction publique
Email / Courriel: = EMAIL ADDRESS REMOVED =
Tel. / Tél: (613) 992-2779

>
This e-mail message is intended for the named recipient(s) and may
contain information that is privileged, confidential and/or exempt from
disclosure under applicable law. Unauthorized disclosure, copying or
re-transmission is prohibited. If you are not a named recipient or not
authorized by the named recipient(s), or if you have received this
e-mail in error, then please notify the sender immediately and delete
the message and any copies.
>
Ce courriel est destiné exclusivement au destinataire mentionné en titre
et peut contenir de l'information privilégiée, confidentielle ou
soustraite à la communication aux termes des lois applicables. Toute
divulgation non autorisée, toute reproduction ou réacheminement est
interdit. Si vous n'êtes pas le destinataire de ce courriel, ou n'êtes
pas autorisé par le destinataire visé, ou encore, si vous l'avez reçu
par erreur, veuillez le mentionner immédiatement à l'expéditeur et
supprimer le courriel et les copies.

From: Bryan Garaventa
Date: Mon, Sep 30 2013 1:04PM
Subject: Re: Accessible jQuery UI DatePicker
← Previous message | No next message

Thanks, I've already fixed the bug actually.

If running a local copy of the lib, the modified module code is at
Uncompressed:
http://whatsock.com/tsg/2%20Accessible%20Component%20Modules/calendar_generator.js
Compressed:
http://whatsock.com/tsg/2%20Accessible%20Component%20Modules/calendar_generator.min.js

As usual, this module code will work equally within the Standalone, jQuery,
and Dojo versions of the API.

The live site has been updated as well, so the original link can be used to
test it. I've just verified it using IE8/10 and FF on Win XP / Win7.

Regarding Chrome, this is a known issue, and has to do with JAWS not
properly supporting Applications Mode when role=application or role=dialog
is used on a container element within that browser, and unfortunately can
only be fixed by Freedom Scientific. This is one of those browser support
inconsistencies often encountered.

If anyone notices any other bugs elsewhere, please let me know as soon as
possible, and I'll be happy to fix them.


----- Original Message -----
From: "David Farough" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Monday, September 30, 2013 11:33 AM
Subject: Re: [WebAIM] Accessible jQuery UI DatePicker


> Hi Brian:
> I have noticed a couple of issues which I will outline below.
>
> 1. Using Internet explorer 8 and Firefox 23, pressing enter on the
> calendar button sometimes causes the calendar to quickly appear and then
> disappear. I have caused this to occur both with and without Jaws 14
> running. I have also noticed that when this happens, the text field
> will then contain the value of the current date. It appears that the
> current date in the calendar may also be picking up the enter key at
> the same time as the calendar button. Does this make sense to you?
> This does not seem to happen when the Jaws autoforms mode is turned on.
> and turning autoforms mode off causes this to occur regularly. I can
> reproduce this quite easily if Jaws is not running.
>
> 2. using chrome, after activating the calendar, if I arrow from one
> date to another Jaws seems to exit applications mode and continuing to
> press arrows causes the virtual cursor functionality to occur instead.
>
> David Farough
> Application Accessibility Coordinator/coordonateur de l'accessibilité
> Information Technology Services Directorate /
> Direction des services d'information technologiques
> Public Service Commission / Commission de la fonction publique
> Email / Courriel: = EMAIL ADDRESS REMOVED =
> Tel. / Tél: (613) 992-2779
>
>>
> This e-mail message is intended for the named recipient(s) and may
> contain information that is privileged, confidential and/or exempt from
> disclosure under applicable law. Unauthorized disclosure, copying or
> re-transmission is prohibited. If you are not a named recipient or not
> authorized by the named recipient(s), or if you have received this
> e-mail in error, then please notify the sender immediately and delete
> the message and any copies.
> >
> Ce courriel est destiné exclusivement au destinataire mentionné en titre
> et peut contenir de l'information privilégiée, confidentielle ou
> soustraite à la communication aux termes des lois applicables. Toute
> divulgation non autorisée, toute reproduction ou réacheminement est
> interdit. Si vous n'êtes pas le destinataire de ce courriel, ou n'êtes
> pas autorisé par le destinataire visé, ou encore, si vous l'avez reçu
> par erreur, veuillez le mentionner immédiatement à l'expéditeur et
> supprimer le courriel et les copies.
>
> > > >