WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Datepicker questions - are they useful?

for

From: MEJ - Beth Sullivan
Date: Nov 3, 2015 10:56AM

Hello,



as usual I can humbled by the responses I see in peace responses you all
have provided. Thank you dearly.



I'm going to attempt to respond to each of your comments.


_mallory - thank you for the information on date pickers from your
perspective I'd be cuirous to see the information that was posted by Gov.uk
on select fields and there shortcomings. I'm getting from you is that when
you are selecting a date the calendar function is important so you can
understand what day of the week you are choosing as well as getting a
mental model of a calendar grid.


Birkir, from your first email, I understand they can minimize the need for
error handling. The concern I have is that keyboard shortcuts are
inconsistent between date picker to date picker for keyboard users and that
currently there is not a date picker that we can say works with three
different assistive technologies (keyboard, JAWS, voiceover) let alone the
myriad of other assistive technologies that a user might be using with the
date picker. The Deque University date picker is the best I've tested yet
but it falls short in the requirement to call out the date that have been
picked and move focus back to the input field with the most current iOS
Voiceover. For the HTML5 input fields I've had a better success with
voiceover since obtained to iOS nine, although I'm not sure how well that
would work talkback. And if you look at the iOS implementation of the HTML5
date field, it is a series of 3 scroll bars not a calendar date picker.


Nancy, I think I'm in the same spot as you with my concerns. There's
nothing right now that fills all the requirements, not that great people
like Bryan, Birkir, and Deque aren't trying. There are lots that are very
close but I'm not comfortable just yet telling my business partners to use
this kind of mostly accessible date picker. In their perfect world, they
would get rid of the input fields altogether. My team isn't going to let
that happen, but what I'm hoping understand is how much effort are these
date pickers worth and when do we say, okay this is the best we have and
what users will we need understand won't have the same experience for
"this" amount of time, which may be the next big redesign in 5-6 years
after this redesign. Or is it about finding a better solution for everyone.
It seems to me that there are some great advantages for all users, from a
practical perspective I have yet to see one that works in all ways is it
supposed to, especially when we look at native mobile browsers not even
implementing calendar date pickers, but other forms like the iOS date
picker.


Bryan, thank you for your links to a few other date pickers to test as
well. You mentioned the case of travel sites. Here's what really grabs my
attention, now I may be a bit preemptive in assuming these sites would have
properly implemented accessible date pickers since the required date isn't
until mid December 2015 apparently, but the fact of the matter is that they
have yet to at this point. Now I'm in Canada but I am aware of the air
carrier access act the states which requires all flights companies have
believed to have accessible sites. For more information see the Deque link:
http://www.deque.com/air-carrier-access-act-update/ . What I find
interesting is that the industry that has the most need for them don't have
accessible date pickers. It looks to me that in these situations they are
going for the label, (possibly offscreen) format, with input fields
solution, mobile or web.


I want to reiterate that I 100% believe that these date pickers should be
accessible to everyone. But what I getting even from the role=grid great
conversation is that the state of screen readers does not allow for this to
work fully. That with every instance and example there is a caveat.


Love to hear more feedback on this. Is there another / better way?


Thank you,

Beth

On Mon, Nov 2, 2015 at 7:21 PM, Chaals McCathie Nevile <
<EMAIL REMOVED> > wrote:

> On Tue, 03 Nov 2015 07:08:34 +0900, Birkir R. Gunnarsson <
> <EMAIL REMOVED> > wrote:
>
> Thanks for all that info, very true.
>> The difficulty is the concept of interactive vs. browse mode in screen
>> readers and custom keyboard shortcuts implemented by applications.
>> There is no graceful way to communicate to screen readers that the
>> webpage developers implemented a set of keyboard navigation features
>> that could speed up and simplify the interaction.
>>
>
> In principle you should be able to use accesskey to do this - with the
> added bonus that it would work for keyboard users who haven't got a
> screenreader running.
>
> As we know, implementation in browsers is still generally bad - although
> it has improved from the "truly dreadful" it used to be, so there is hope.
>
> More importantly, it is often screen reader users who miss out since their
> shortcuts are generally not overridden any more, but no effort is made to
> reassign the access key.
>
> This is one of the gazillions of use cases that motivate
> https://chaals.github.io/accesskey/index.src.html which I hope is ready
> to propose for wider review now, as a step to getting a decent solution to
> these problems in browsers.
>
> One of the things I tried to do there is make as easy a transition path as
> possible. The result is basically that people who are using piles of
> javascript in an attempt to solve the issue will be able to throw most of
> it away, people who use accesskey already will find it magically being more
> useful, and browsers have a smooth upgrade path without breaking any kind
> of compatibility I can find.
>
> Of course we'll see what happens if we get this on the road…
>
> cheers
>
>
> A lot of beginner to intermediate screen reader users are still not
>> fully aware of the idea of browse mode or key pass through options.
>> Sure, off-screen instructions could be added for the element that
>> receives focus when the datepicker opens, or link them with the
>> calendar pop-up trigger element, but those would probably start to
>> annoy screen reader users who are used to interacting with the
>> webpage.
>> So in creating this example I was caught between forcing the users to
>> discover the behavior by using the application role, and let the
>> screen reader application itself decide on the interaction mode and
>> leave the mode of navigation up to the user by using the grid role.
>> I think the grid roll spec strongly suggests use of application mode
>> (else it would be no different from a table that includes interactive
>> elements), but ultimately I cannot read a definite interpretation from
>> the spec.
>> I only consider grids for content that does not include static
>> elements (unless associated with itneractive elemetns in some way).
>> So I may revisit the example and choose one mode over the other,
>> probably role = grid over application.
>> In general I don´t like the application role, and I avoid it whenever
>> possible, because we should not dictate how specific assistive
>> technologies work, it is up to them to know how to do things in a way
>> that is best for the end user.
>> But sometimes it seems like it would be the best option to ensure that
>> when a lot of work has been put into the user experience, for all
>> users including keyboard only and screen reader users, that work
>> should not go unnoticed.
>> Cheers
>>
>>
>>
>> On 11/2/15, Bryan Garaventa < <EMAIL REMOVED> > wrote:
>>
>>> Actually it's not last time I checked, and may be doing the opposite in
>>> JAWS
>>> when in Virtual Cursor mode.
>>>
>>> E.G, using IE11 with JAWS16 on Win7 at
>>> https://dequeuniversity.com/library/aria/date-pickers/sf-date-picker
>>> simply arrowing to the calendar picker button in VC mode and pressing
>>> Enter
>>> causes the date picker to open, but Applications Mode is not invoked as
>>> expected.
>>>
>>> Regarding role=grid, there are still significant screen reader
>>> differences
>>> between how JAWS and NVDA treat this, which you will notice between IE
>>> and
>>> FF using both, as well as within Chrome. E.G
>>>
>>> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Data%20Grids/ARIA%20Data%20Grid%20(Dynamic)/demo.htm
>>>
>>> One thing to keep in mind with role=grid as well, the use of role=grid is
>>> not supposed to cause a specific behavior to occur according to the ARIA
>>> spec, but role=application is, which is why there is so much confusion
>>> there
>>> even today.
>>>
>>> A Grid is simply meant to convey an interactive Grid construct where
>>> Gridcell nodes can be interacted with, but role=application specifies
>>> that
>>> an AT should pass all keystrokes to the element that has focus, but they
>>> both don't mean the same thing. E.G a Grid is a Composite widget type
>>> (Reference
>>> http://www.w3.org/TR/wai-aria-1.1/#composite )
>>> and may include embedded active elements that may not require
>>> Applications
>>> Mode when focus is set to one of them.
>>>
>>>
>>>
>>>