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
>
>
>
>