WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: jQuery Datepicker - expected kb behavior?

for

From: Isabel Holdsworth
Date: Oct 29, 2018 10:10AM


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 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 REMOVED> > On Behalf Of Abby
> Kingman
> Sent: Monday, October 29, 2018 11:05 AM
> To: <EMAIL 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
> > > > > >