WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible Datepicker & NVDA Support

for

From: Paul J. Adam
Date: May 19, 2016 2:33PM

The first example is missing a role for the date picker elements and missing something to indicate a selected state to the screen reader user.

<td id="cell19-dt" class="day selectable curDay focus" data-value="19" aria-label="Thursday, May 19, 2016" tabindex="0">19</td>

Possibly make it a role=button and aria-pressed=true for the selected button. Right now it's speaking as a "group" to VoiceOver OS X which does not indicate it's an actionable control.

Here's an example of an accessible date picker that also works on mobile, https://dequeuniversity.com/library/aria/date-pickers/sf-date-picker

I'm not sure how you could exclude date picker widgets from Accessibility testing. Because in my view it's not equal access if you have to type the date manually MM/DD/YYYY but a mouse user can easily click the date they want and see if that day is a Friday or Sunday without pulling out their own calendar. I would not consider it progressive enhancement, I would consider it a custom HTML widget that can be developed with keyboard and screen reader accessibility. Everything on the web page must be accessible.

I think some screen reader users may avoid date pickers or think they don't have to be accessible because they may have never seen an accessible date picker actually used in the real world. Accessible date pickers can be created and should be created. I would say if you don't want to make the date picker accessible then don't use the date picker at all :)

Paul J. Adam
Accessibility Evangelist
www.deque.com

> On May 19, 2016, at 12:08 PM, Meacham, Steve - FSA, Kansas City, MO < <EMAIL REMOVED> > wrote:
>
> In my organization, I consider date pickers to be a "progressive enhancement" and don't even assess them for accessibility, so long as the user has the option to use them or ignore them and still specify a date.
>
>