E-mail List Archives
Thread: jQuery Datepicker - expected kb behavior?
Number of posts in this thread: 17 (In chronological order)
From: Tomlins Diane
Date: Thu, Oct 11 2018 10:22AM
Subject: jQuery Datepicker - expected kb behavior?
No previous message | Next message →
Our developers want to use this date picker -- http://jqueryui.com/datepicker/ - it has some accessibility issues, but I found Deque's article on helping to fix that.
One of the things I question is navigating the calendar - in order to move within the calendar, you have to hold down the Ctrl (or Command) + arrow key.
Is this an accepted or typical way for kb or sr users to navigate a date picker like this? The full list of kb interactions is here - http://api.jqueryui.com/datepicker/.
Not helpful if we have to include a list of commands for using the thing.
Thanks!
Diane R Tomlins
HCA IT&S | UXCOE
Accessibility SME
From: glen walker
Date: Thu, Oct 11 2018 10:44AM
Subject: Re: jQuery Datepicker - expected kb behavior?
← Previous message | Next message →
I don't know if ctrl+arrow is the "typical" way to navigate through a
calendar but I've found that if unmodified arrows don't work, then I try
ctrl+arrows.
Of course, with a screen reader running, the unmodified arrow keys will
walk the accessibility tree and not navigate the calendar unless the
calendar goes into forms/application mode, so perhaps that's why some
calendars choose to use ctrl+arrow to navigate.
From: Lily Sedaghat
Date: Thu, Oct 11 2018 12:07PM
Subject: Re: jQuery Datepicker - expected kb behavior?
← Previous message | Next message →
Hi,
Is there a third party date picker available somewhere that is ada compliant out of the box? Or is the jquery date picker the closest to being compliant? Wondering what is best option out there for date pickers?
Thanks,
Lily
Sent from my iPhone
> On Oct 11, 2018, at 12:44 PM, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>
> I don't know if ctrl+arrow is the "typical" way to navigate through a
> calendar but I've found that if unmodified arrows don't work, then I try
> ctrl+arrows.
>
> Of course, with a screen reader running, the unmodified arrow keys will
> walk the accessibility tree and not navigate the calendar unless the
> calendar goes into forms/application mode, so perhaps that's why some
> calendars choose to use ctrl+arrow to navigate.
> > > >
From: Tomlins Diane
Date: Thu, Oct 11 2018 12:21PM
Subject: Re: jQuery Datepicker - expected kb behavior?
← Previous message | Next message →
When I was asked about the date picker last week, I found that the Angular Material date picker was very good. - https://material.angular.io/components/datepicker/overview
I tested it with keyboard and with NVDA and it works really well just as it is on that page.
Diane R Tomlins
HCA IT&S | UXCOE
Accessibility SME
>Is there a third party date picker available somewhere that is ada compliant out of the box? Or is the jquery date picker the closest to being compliant? >Wondering what is best option out there for date pickers?
>Thanks,
>Lily
From: Mohith BP
Date: Fri, Oct 12 2018 12:11AM
Subject: Re: jQuery Datepicker - expected kb behavior?
← Previous message | Next message →
Hi,
Ctrl + arrow key is not generally expected behavior.
Please refer the following link for the accessible date pickers:
http://www.webaxe.org/accessible-date-pickers/
Thanks & Regards,
Mohith B. P.
On 10/11/18, Tomlins Diane < = EMAIL ADDRESS REMOVED = > wrote:
> When I was asked about the date picker last week, I found that the Angular
> Material date picker was very good. -
> https://material.angular.io/components/datepicker/overview
>
> I tested it with keyboard and with NVDA and it works really well just as it
> is on that page.
>
>
> Diane R Tomlins
> HCA IT&S | UXCOE
> Accessibility SME
>
>>Is there a third party date picker available somewhere that is ada
>> compliant out of the box? Or is the jquery date picker the closest to
>> being compliant? >Wondering what is best option out there for date
>> pickers?
>
>>Thanks,
>>Lily
>
> > > > >
From: Tomlins Diane
Date: Fri, Oct 12 2018 8:21AM
Subject: Re: jQuery Datepicker - expected kb behavior?
← Previous message | Next message →
Thank you, that's what I thought. I did find a version yesterday, through WebAxe, that uses just the arrow keys and not the ctrl+ of the raw jQuery UI version. I sent that to the developer so he can get that working.
Diane R Tomlins
HCA IT&S | UXCOE
Accessibility SME
--------------------------------
>Ctrl + arrow key is not generally expected behavior.
>Please refer the following link for the accessible date pickers:
>http://www.webaxe.org/accessible-date-pickers/
>Thanks & Regards,
>Mohith B. P.
From: Jeff Gutsell
Date: Fri, Oct 12 2018 2:30PM
Subject: Re: jQuery Datepicker - expected kb behavior?
← Previous message | Next message →
I am a self-taught scripter, and perhaps I am missing something about using
Control plus arrow keys. A fundamental part of the keyboard accessibility
described by the W3C is using arrow keys to move focus. I don't recall the
W3C ever mentioning the need for the control key.
A :"keydown" event that wants to move focus should include the
preventDefault() method to avoid scrolling the page while the focus is
within the widget. That is how the W3C aria example for popup menus works.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
Of glen walker
Sent: Thursday, October 11, 2018 12:45 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] jQuery Datepicker - expected kb behavior?
I don't know if ctrl+arrow is the "typical" way to navigate through a
calendar but I've found that if unmodified arrows don't work, then I try
ctrl+arrows.
Of course, with a screen reader running, the unmodified arrow keys will
walk the accessibility tree and not navigate the calendar unless the
calendar goes into forms/application mode, so perhaps that's why some
calendars choose to use ctrl+arrow to navigate.
From: JP Jamous
Date: Fri, Oct 12 2018 3:02PM
Subject: Re: jQuery Datepicker - expected kb behavior?
← Previous message | Next message →
Jeff,
You are correct. No need for the CTRL key. Only the arrow keys would
suffice.
Typically, screen readers use the CTRL + left or right to read previous or
next word. The CTRL + Up or Down would be to read previous or next
paragraph.
If CTRL + arrow keys are implemented, they can conflict with screen readers
navigation scripts in a browser, thereby disabling the read word or
paragraph functionality.
--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Jeff
Gutsell
Sent: Friday, October 12, 2018 3:31 PM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] jQuery Datepicker - expected kb behavior?
I am a self-taught scripter, and perhaps I am missing something about using
Control plus arrow keys. A fundamental part of the keyboard accessibility
described by the W3C is using arrow keys to move focus. I don't recall the
W3C ever mentioning the need for the control key.
A :"keydown" event that wants to move focus should include the
preventDefault() method to avoid scrolling the page while the focus is
within the widget. That is how the W3C aria example for popup menus works.
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
Of glen walker
Sent: Thursday, October 11, 2018 12:45 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] jQuery Datepicker - expected kb behavior?
I don't know if ctrl+arrow is the "typical" way to navigate through a
calendar but I've found that if unmodified arrows don't work, then I try
ctrl+arrows.
Of course, with a screen reader running, the unmodified arrow keys will walk
the accessibility tree and not navigate the calendar unless the calendar
goes into forms/application mode, so perhaps that's why some calendars
choose to use ctrl+arrow to navigate.
http://webaim.org/discussion/archives
http://webaim.org/discussion/archives
From: glen walker
Date: Fri, Oct 12 2018 3:02PM
Subject: Re: jQuery Datepicker - expected kb behavior?
← Previous message | Next message →
Jeff, yes, you are correct that there are some design patterns that do use
the unmodified key to move the focus, such as menus, tablist, listbox,
radio group, and accordions, but I have not seen any specific direction
that only unmodified arrow keys may move the focus. Granted, a modified
arrow key might be harder to discover, but that doesn't mean it's not
allowed.
From: glen walker
Date: Fri, Oct 12 2018 3:15PM
Subject: Re: jQuery Datepicker - expected kb behavior?
← Previous message | Next message →
Good points, JP. However, your last point about having a component
implement ctrl+arrow might interfere with a screen reader can also be
applied to a component implementing an unmodified arrow key and having it
interfere with a screen reader user navigating the accessibility tree.
When focus moves into a menu (eg, a real menu with a menu role, not a
navigation menu that is a list of links), then you'll hear the menu role
and have the expectation that the (unmodified) arrow keys will navigate
(and many screen readers will tell you to use the arrow keys). You don't
have any expectations that right arrow will read the next character rather
than move to the next menu item.
With a calendar, since there isn't a native element or aria role, there may
not be the same expectation. Whether the calendar uses a simple arrow or a
modified arrow is kind of up to the developer, since we don't really have
any standards for it (unfortunately). If a simple arrow is used, I would
think you'd hear the screen reader go into forms mode so that you'd know
the arrow keys won't navigate the accessibility tree.
On Fri, Oct 12, 2018 at 3:02 PM JP Jamous < = EMAIL ADDRESS REMOVED = > wrote:
>
> If CTRL + arrow keys are implemented, they can conflict with screen readers
> navigation scripts in a browser, thereby disabling the read word or
> paragraph functionality.
>
>
>
From: Janet Magruder
Date: Fri, Oct 12 2018 6:01PM
Subject: Re: jQuery Datepicker - expected kb behavior?
← Previous message | Next message →
 Janet Magruder1900 LanceyModesto, CA 95355
Cancel this do not email me again!
On Friday, October 12, 2018 2:16 PM, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
Good points, JP. However, your last point about having a component
implement ctrl+arrow might interfere with a screen reader can also be
applied to a component implementing an unmodified arrow key and having it
interfere with a screen reader user navigating the accessibility tree.
When focus moves into a menu (eg, a real menu with a menu role, not a
navigation menu that is a list of links), then you'll hear the menu role
and have the expectation that the (unmodified) arrow keys will navigate
(and many screen readers will tell you to use the arrow keys). You don't
have any expectations that right arrow will read the next character rather
than move to the next menu item.
With a calendar, since there isn't a native element or aria role, there may
not be the same expectation. Whether the calendar uses a simple arrow or a
modified arrow is kind of up to the developer, since we don't really have
any standards for it (unfortunately). If a simple arrow is used, I would
think you'd hear the screen reader go into forms mode so that you'd know
the arrow keys won't navigate the accessibility tree.
On Fri, Oct 12, 2018 at 3:02 PM JP Jamous < = EMAIL ADDRESS REMOVED = > wrote:
>
> If CTRL + arrow keys are implemented, they can conflict with screen readers
> navigation scripts in a browser, thereby disabling the read word or
> paragraph functionality.
>
>
>
From: JP Jamous
Date: Sat, Oct 13 2018 12:16PM
Subject: Re: jQuery Datepicker - expected kb behavior?
← Previous message | Next message →
I may have written it incorrectly, but I was not suggesting the use of arrow
keys. In fact, if I would design a calendar, I would make it look like a
table and definitely provide the proper object type to the screen reader.
The user will know it is a table and to use the CTRL + Alt + arrow keys.
My point was that using CTRL along with the arrow keys would not be
something used in a table, list box or other types of object for the most
part. They are strictly to read previous or next word, or previous or next
paragraph. However, if the user hears "Calendar, table with 7 columns and 5
rows. " Then the user would know that this is a table. CTRL + Alt + arrow
keys would be the best navigation method for this type of object.
In a way, I would dislike going into forms mode to pick a date. I prefer the
table layout, because that would keep the basic calendar layout on any piece
of paper. Simply use the 7 days of the week as column headings and the days
listed underneath them.
I strongly prefer to provide the proper object type and let the screen
reader user pick the navigation mode he or she requires. I focused heavily
on that with my Windows form applications in the past and still carry the
same concept with me to web applications. I definitely frown upon
overwriting the Windows or screen reader shortcut keys.
--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen
walker
Sent: Friday, October 12, 2018 4:15 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] jQuery Datepicker - expected kb behavior?
Good points, JP. However, your last point about having a component
implement ctrl+arrow might interfere with a screen reader can also be
applied to a component implementing an unmodified arrow key and having it
interfere with a screen reader user navigating the accessibility tree.
When focus moves into a menu (eg, a real menu with a menu role, not a
navigation menu that is a list of links), then you'll hear the menu role and
have the expectation that the (unmodified) arrow keys will navigate (and
many screen readers will tell you to use the arrow keys). You don't have
any expectations that right arrow will read the next character rather than
move to the next menu item.
With a calendar, since there isn't a native element or aria role, there may
not be the same expectation. Whether the calendar uses a simple arrow or a
modified arrow is kind of up to the developer, since we don't really have
any standards for it (unfortunately). If a simple arrow is used, I would
think you'd hear the screen reader go into forms mode so that you'd know the
arrow keys won't navigate the accessibility tree.
On Fri, Oct 12, 2018 at 3:02 PM JP Jamous < = EMAIL ADDRESS REMOVED = > wrote:
>
> If CTRL + arrow keys are implemented, they can conflict with screen
> readers navigation scripts in a browser, thereby disabling the read
> word or paragraph functionality.
>
>
>
http://webaim.org/discussion/archives
From: glen walker
Date: Sat, Oct 13 2018 12:29PM
Subject: Re: jQuery Datepicker - expected kb behavior?
← Previous message | Next message →
Yes, I like the calendar/table too, although a table doesn't imply any
interactions. I use ctrl+alt+arrow all the time to navigate through the
cells, but I do that not expecting to select a cell. And that keyboard
interaction is only for screen reader users. A keyboard only user won't
have that key sequence (unless the developer implements it that way).
A grid, on the other hand, does imply some kind of interactions, but that's
typically for editing the contents of a cell and not really for selecting a
cell.
A calendar is basically a big selection list, but laid out in a grid/table
pattern. It normally only allows one or two selections for choosing a
single date or a date range.
The holy grail is to have a keyboard interaction that makes sense for both
the sighted keyboard user and the screen reader user.
Glen
From: Isabel Holdsworth
Date: Mon, Oct 15 2018 6:22AM
Subject: Re: jQuery Datepicker - expected kb behavior?
← Previous message | Next message →
When devs are planning the keyboard functionality for a widget, IMO
they often place too much emphasis on how blind users will interact
with the content, and far too little on the experience it offers to
people who use a keyboard but not a screenreader, some of whom will
find it painful or at least frustrating to have to press the Tab key
many times to interact with the widget, or to move past it.
I think there's a compromise to be struck between ensuring that
components are perceivable to AT, and also operable using a keyboard
or other input method.
When a table or grid contains a lot of focusable elements, such as a
calendar with buttons for selecting the date, or a calculator,
sometimes having a single tab stop for the widget and providing arrow
navigation inside it seems like the best compromise. So, for example,
in a calendar, if the focus starts on the first day of the month,
keyboard users can get to the last day by pressing 5 or 6 arrow keys
rather than hitting the Tab key up to 30 times.
One site I worked on had a scientific calculator containing at a guess
around 75 buttons, which keyboard users had to tab through to get past
the tool. That would have been a great candidate for arrow navigation.
Cheers.
On 13/10/2018, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> Yes, I like the calendar/table too, although a table doesn't imply any
> interactions. I use ctrl+alt+arrow all the time to navigate through the
> cells, but I do that not expecting to select a cell. And that keyboard
> interaction is only for screen reader users. A keyboard only user won't
> have that key sequence (unless the developer implements it that way).
>
> A grid, on the other hand, does imply some kind of interactions, but that's
> typically for editing the contents of a cell and not really for selecting a
> cell.
>
> A calendar is basically a big selection list, but laid out in a grid/table
> pattern. It normally only allows one or two selections for choosing a
> single date or a date range.
>
> The holy grail is to have a keyboard interaction that makes sense for both
> the sighted keyboard user and the screen reader user.
>
> Glen
> > > > >
From: Abby Kingman
Date: Mon, Oct 29 2018 9:05AM
Subject: jQuery Datepicker - expected kb behavior?
← Previous message | Next message →
After reading this thread, it sounds like this is a pattern that might best
be avoided if possible.
I recently read an article (one that is also linked to on the WebAxe site
referred to earlier) that suggests removing the date picker from the
screenreader context and tab index using the aria-hidden role. Here is the
suggested method:
---
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 aria-hidden attribute.
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.
---
Link to the full article: We need to talk about the accessibility of date
pickers
<https://aldavigdis.wordpress.com/2018/06/24/we-need-to-talk-about-the-accessibility-of-date-pickers/>
While there are cases where validation might be necessary I thought this
was an interesting idea.
As a sighted tester it is difficult for me to say with certainty that a
pattern needs to be changed if I am not sure what the user is expecting. In
order to set up a ticket, I need to identify what the desired behavior is.
When it is acceptable to allow direct input, this seems like a workable
approach.
--
Abby Kingman
Last Call Media
From: Jonathan Avila
Date: Mon, Oct 29 2018 9:10AM
Subject: Re: jQuery Datepicker - expected kb behavior?
← Previous message | Next message →
> 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 aria-hidden attribute.
While this may be true, I would add to the list of reasons why it may need to be provided. For example, knowing the day of week or whether the date is the first or last week in a month are also important details to consider.
Jonathan
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Abby Kingman
Sent: Monday, October 29, 2018 11:05 AM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] jQuery Datepicker - expected kb behavior?
After reading this thread, it sounds like this is a pattern that might best be avoided if possible.
I recently read an article (one that is also linked to on the WebAxe site referred to earlier) that suggests removing the date picker from the screenreader context and tab index using the aria-hidden role. Here is the suggested method:
---
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 aria-hidden attribute.
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.
---
Link to the full article: We need to talk about the accessibility of date pickers <https://aldavigdis.wordpress.com/2018/06/24/we-need-to-talk-about-the-accessibility-of-date-pickers/>
While there are cases where validation might be necessary I thought this was an interesting idea.
As a sighted tester it is difficult for me to say with certainty that a pattern needs to be changed if I am not sure what the user is expecting. In order to set up a ticket, I need to identify what the desired behavior is.
When it is acceptable to allow direct input, this seems like a workable approach.
--
Abby Kingman
Last Call Media
From: Isabel Holdsworth
Date: Mon, Oct 29 2018 10:10AM
Subject: Re: jQuery Datepicker - expected kb behavior?
← Previous message | No next message
There is a rationale for providing date pickers, and that rationale
almost certainly extends to screenreader and keyboard users. If you're
following an inclusive design approach, it wouldn't be acceptable to
hide the date picker to save the bother of making it accessible. In
order to ensure that you offer an equivalent experience to all users,
that pesky date picker would need to be made accessible too.
On 29/10/2018, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>> 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 aria-hidden attribute.
>
> While this may be true, I would add to the list of reasons why it may need
> to be provided. For example, knowing the day of week or whether the date is
> the first or last week in a month are also important details to consider.
>
> Jonathan
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Abby
> Kingman
> Sent: Monday, October 29, 2018 11:05 AM
> To: = EMAIL ADDRESS REMOVED =
> Subject: Re: [WebAIM] jQuery Datepicker - expected kb behavior?
>
> After reading this thread, it sounds like this is a pattern that might best
> be avoided if possible.
>
> I recently read an article (one that is also linked to on the WebAxe site
> referred to earlier) that suggests removing the date picker from the
> screenreader context and tab index using the aria-hidden role. Here is the
> suggested method:
> ---
> 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 aria-hidden attribute.
>
> 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.
> ---
> Link to the full article: We need to talk about the accessibility of date
> pickers
> <https://aldavigdis.wordpress.com/2018/06/24/we-need-to-talk-about-the-accessibility-of-date-pickers/>
>
> While there are cases where validation might be necessary I thought this was
> an interesting idea.
>
> As a sighted tester it is difficult for me to say with certainty that a
> pattern needs to be changed if I am not sure what the user is expecting. In
> order to set up a ticket, I need to identify what the desired behavior is.
> When it is acceptable to allow direct input, this seems like a workable
> approach.
>
> --
> Abby Kingman
> Last Call Media
> > > http://webaim.org/discussion/archives
> > > > > >