WebAIM - Web Accessibility In Mind

E-mail List Archives

jQuery Datepicker - expected kb behavior?

for

From: Abby Kingman
Date: Oct 29, 2018 9:05AM

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