WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Datepicker questions - are they useful?

for

From: Birkir R. Gunnarsson
Date: Nov 3, 2015 6:34PM

Beth

The closest we have to a guide on how keybord navigation within
datepickers should work is the ARIA Authoring Practices Guide:
http://www.w3.org/TR/wai-aria-practices-1.1/#datepicker
This guide is not normative (meaning not all keyboard interaction has
to follow this exact model), and the task force (that includes myself
as well as Bryan) are working on ideas and improvements.

I thought you might find this useful.
I will take a second look at the Deque datepicker with Voiceover. It
used to work fine (including the focus management when user selects a
date from the calendar widget) when we tested it but that was with
Voiceover 8 (I think 8.1).
This is the other challenge we face.
Assistive technologies keep changing.
Fortunately most of the time it is for the better, but sometimes they
change the way they interpret web or application content. When those
updates are combined with upgrades to the browsers which deliver the
webpage content to them, makes making complex widgets accessible a
moving target.
So I think we should all keep trying. That is what myself, Bryan (who
taught me a lot of what I know actually), and others keep trying to
come up with ever so slightly different implementations to see what
works best, and to realize where there are problems.
We try to communicate those problems to browser and the assistive
technology vendors, and improve standards and recommendations if that
helps make complex content universally accessible.
We cannot achieve a 100% accessible datepicker currently on all
combinations of assistive technologies and browsers.
But I think we should put the best and most accessible widgets we can
make out there. When we do that, people will want to use them with
their adaptive hardware or software, those people will hopefully
report those problems, which creates a demand and discussion to get
them fixed.
Offer a text input field as a more accessible fallback solution, even
when it isn't perfect.
That way you try to deliver the best of both worlds to the user.






On 11/3/15, Bryan Garaventa < <EMAIL REMOVED> > wrote:
> One thing that is important to keep in mind, is that there is no such thing
> as 100% accessibility. No matter what you do, there is always going to be a
> percentage of people who have difficulty with whatever it is. The reason
> being that there is no way to predict all types and variations of
> disabilities for all people at the same time, and all such have different
> ways and technologies for accessing these technologies. Also, there are many
> who have such disabilities who don't have access to these technologies at
> all, and nothing will allow them to access these features without them.
>
> So it's a mistake to not recommend something because it is not 100%
> accessible to all people equally.
>
> That being said, we as developers can raise the bar as high as possible, and
> staple it there, so that others can learn from and build new and better
> technologies from such benchmarks in the future.
>
> This is the concept that I used to build the WhatSock date picker, so that
> others might learn from and benefit from the research that went into its
> construction, and use it if they desire.
>
> As technologies change, better solutions are likely to evolve as ATs improve
> and API mappings become better synchronized with browsers and so on, so all
> of these technologies will evolve with them as time goes on. It's doubtful
> however that such simple constructs as the one I've been referencing will
> just stop working though, since it uses the most basic of concepts to
> comprise it's functionality. Even so, specs change and sometimes events are
> deprecated, and widgets need to be updated accordingly. The trick for
> managing this is to modularize components like this so they can be easily
> updated and just plugged back into the application without disrupting
> functionality.
>
> Luckily styling and content display is easy to change using CSS, so it's
> also important to understand the difference between the functional
> accessibility of an interactive widget versus how it looks, which are very
> different. E.G If something simply doesn't look right, it can easily be
> changed. If something is programmed inaccessibly however, it is often much
> harder to fix no matter what it looks like.
>
> Please do me a favor and test the WhatSock date picker when you have time
> and let me know which accessibility issues you encounter. I can usually fix
> them very quickly when discovered. Also, for any control like this, the type
> of device will often affect its usability, which can't be avoided. For
> example you can view something on a monitor or tablet with ease, but try to
> do the same on a 2 inch wide iPod screen and it will likely be impossible to
> interact with. We haven't figured out a foolproof way of dealing with all
> devices equally as yet, but this should get easier as time goes on and
> responsive design techniques improve.
>
> All the best,
> Bryan
>
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf
> Of MEJ - Beth Sullivan
> Sent: Tuesday, November 03, 2015 9:56 AM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Cc: <EMAIL REMOVED>
> Subject: Re: [WebAIM] Datepicker questions - are they useful?
>
> 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%20Da
>>>> ta%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.
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
>>>> Behalf Of Birkir R. Gunnarsson
>>>> Sent: Monday, November 02, 2015 9:17 AM
>>>> To: WebAIM Discussion List < <EMAIL REMOVED> >
>>>> Subject: Re: [WebAIM] Datepicker questions - are they useful?
>>>>
>>>> Re the Deque University datepicker:
>>>> The original idea was to use grid and we expect that would ensure
>>>> screen readers going into forms mode.
>>>> But at the time we tested it, we did not get the behavior we expected.
>>>> To force forms mode we added the application role.
>>>> We may need to look at this again, since I think the grid role alone
>>>> is sufficient now.
>>>>
>>>>
>>>>
>>>> On 11/2/15, Bryan Garaventa < <EMAIL REMOVED> > wrote:
>>>>
>>>>> A date picker is very useful, especially when it's important to
>>>>> know the day of the week or month involved, or when planning months
>>>>> or years in the future. This is especially the case with travel sites.
>>>>>
>>>>> There is another implementation you are welcome to test at
>>>>> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%2
>>>>> 0Da te%20Picker%20(Basic)/demo.htm Which supports disabled date
>>>>> ranges, comment notation, date format changing, localization
>>>>> support within any language, calendar changing for European
>>>>> calendar layout differences, full control over styling across
>>>>> various devices, and so on.
>>>>>
>>>>> The module works as powered by jQuery within the archive at
>>>>> https://github.com/accdc/tsg
>>>>>
>>>>> Or powered by Dojo at
>>>>> https://github.com/accdc/tsg-dojo
>>>>>
>>>>> Or powered by MooTools at
>>>>> https://github.com/accdc/tsg-mootools
>>>>>
>>>>> Sincerely,
>>>>> Bryan Garaventa
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
>>>>> Behalf Of Mary Elizabeth Sullivan
>>>>> Sent: Monday, November 02, 2015 4:57 AM
>>>>> To: WebAIM Discussion List < <EMAIL REMOVED> >
>>>>> Subject: [WebAIM] Datepicker questions - are they useful?
>>>>>
>>>>> Hello,
>>>>>
>>>>> I have a question about datepickers for the group.
>>>>>
>>>>> We are looking to create a recommended pattern for a style guide.
>>>>> This style guide will influence desktop, responsive and mobile
>>>>> native applications.
>>>>>
>>>>> Generally we know we want
>>>>>
>>>>> <label ...>
>>>>> <format instructions>
>>>>> <input text box>
>>>>> <date picker validation>
>>>>>
>>>>> We obviously will also have to keep error handling in mind. My
>>>>> questions to everyone are:
>>>>> - do screen reader users enjoy accessible datepickers or do they
>>>>> prefer a text box?
>>>>> - do keyboard only or zoomtext users enjoy accessible datepickers
>>>>> or do they prefer a text box?
>>>>> - same question for dragon users
>>>>>
>>>>> - also for responsive and mobile web, do people like the input
>>>>> typeÚte with mobile assistive technologies like VoiceOver and
>>>>> talkback? Switch control? Or is the textbox preferred?
>>>>>
>>>>> - is a sequence of drop downs better?
>>>>>
>>>>> Lately I've been trying to find a one size fits all option and I
>>>>> really haven't found one. It begs the question, what is the most
>>>>> fluid way for people to use a date picker. What is the user impact?
>>>>> Are calendar date pickers helpful or do they make a simple process
>>>>> more difficult?
>>>>>
>>>>> Thank you,
>>>>>
>>>>> Beth
>>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>> >>>>> >>>>> archives at http://webaim.org/discussion/archives
>>>>> >>>>>
>>>>> >>>>> >>>>> archives at http://webaim.org/discussion/archives
>>>>> >>>>>
>>>>>
>>>>
>>>> --
>>>> Work hard. Have fun. Make history.
>>>> >>>> >>>> archives at http://webaim.org/discussion/archives
>>>> >>>>
>>>> >>>> >>>> archives at http://webaim.org/discussion/archives
>>>> >>>>
>>>>
>>>
>>>
>>
>> --
>> Charles McCathie Nevile - web standards - CTO Office, Yandex
>> <EMAIL REMOVED> - - - Find more at http://yandex.com
>>
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
> > > http://webaim.org/discussion/archives
> >
> > > > >


--
Work hard. Have fun. Make history.