WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Datepicker questions - are they useful?

for

From: Whitney Quesenbery
Date: Nov 7, 2015 8:57AM

Dropping back a bit from the technical questions, there is not one simple
rule for how to collect dates in a form or interface.

The UK GDS has done some excellent work untangling this, thinking about
differences in how we might want to edit dates based on context -- and most
importantly, what we know about the date in question.

Their Design Pattern for Dates
<https://www.gov.uk/service-manual/user-centred-design/resources/patterns/dates.html>
discusses

- Memorable dates
- Copied dates
- Approximate dates
- Relative dates
- Calendar controls
- Formatting dates
- Validating dates

There is also a good article on asking for a date of birth (common need in
many govt forms). I value it for the reports of usability work on this
topic and how it shaped the design they now recommend.
https://designnotes.blog.gov.uk/2013/12/05/asking-for-a-date-of-birth/

One usability/accessibility problem in the article has been corrected in
the article, with the labels now outside of the form, where they belong.

It also points out that the reading (and visual) order should put any
instructions BEFORE they are needed, not AFTER - no matter how tempting it
might be.


On Fri, Nov 6, 2015 at 1:50 PM Bryan Garaventa < <EMAIL REMOVED> >
wrote:

> Thanks, those are all helpful. Luckily these are fairly simple to
> implement within any web UI.
>
> Regarding the format, mm/dd/yyy or dd/mm/yyy, I agree it is confusing at
> times. This can be helped using supplementary description text or a
> placeholder at times.
>
> Also, this can be addressed programmatically for some sites that span
> multiple countries. For example, the date format string for the WhatSock
> date picker simply uses a callback function when a date is selected, then
> the developer can use whatever parsing logic and string format they wish to
> populate the field, or even control the values of three individual select
> elements such as Day, Month, and Year, so this flexibility is easily
> achieved.
>
> Typically I recommend both, the ability to manually enter the desired
> date, and an accessible date picker, because having both will ensure the
> greatest value for all user types.
>
> > If you do the datepicker don't forget to style it so I can see it (one
> of the examples had a visual focus indicator of
> > dark grey on black seemingly)
>
> Probably my fault, I'm blind so this can slip past me at times. The source
> code is easily changed however for anybody who wishes to employ different
> styling and content.
>
> All the best,
> Bryan
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Kevin Prince
> Sent: Thursday, November 05, 2015 8:09 PM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Datepicker questions - are they useful?
>
> Just looking at this from a user perspective (sighted, mouse available)
>
> My first thought is that a date picker is useful where there is both a
> specific day and validation required. My preference is to type directly (eg
> a birth date) in ddmmyy format or have 3 dropdowns (but please date first,
> it's so confusing when the month is first for most of the world :)) So
> there are a couple of context-based thoughts as to when to use which:
> 1. If you want my birthday, wedding day etc just let me type it and tell
> me clearly what format (preferably handle the format behind the scenes and
> accept yy or yyyy and mm or MMM).
> 2. If you are really stuck on a format give me 3 labelled dropdowns but I
> insist you let me use first character navigation.
> 3. If it's something where validating the day and date (eg =booking a xyz
> ) then go for the accessible datepicker. In 1 and 2 you can offer the
> datepicker as an alternative too of course.
>
> If you do the datepicker don't forget to style it so I can see it (one of
> the examples had a visual focus indicator of dark grey on black seemingly)
>
> Thanks for this thread and the two examples though - I had literally just
> been asked to go find what was available and looked in the Webaim list to
> kill some time while I found the energy.
>
> Kev
> Access1in5
> 0212220638
> 039290692
> Independent Accessibility and IT Consultancy.
>
>
>
> > On 6/11/2015, at 03:07, _mallory < <EMAIL REMOVED> > wrote:
> >
> > On Wed, Nov 04, 2015 at 10:01:17AM -0800, Bryan Garaventa wrote:
> >> That would be helpful if possible in some cases, but usually date
> pickers are meant to go two ways, first opening the calendar from the web
> page which is probably doable in some cases like this, but also the other
> way where the date selected needs to be sent back to the web page in a way
> that can be processed. Also there may be disabled date ranges or additional
> info that needs to be conveyed within the calendar to the user at the same
> time that may not be possible to do on a software/app based calendar since
> it would only apply to the site where the date picker was originally
> located. Currently it's not possible for a standard web page to send and
> receive information like this by accessing apps on the device OS like this,
> because it also introduces security vulnerabilities. E.G If a malicious
> site were for example to access your calendar and read all of your events
> it could also save and record them, which would be a breach of your privacy.
> >
> > Yeah, it would have to be one-way metadata from the site to the
> > calendar app to counter security problems, and the selection of
> > date(s) would need to be considered an input back to the page,
> > something I think the calendar would/should be able to control.
> >
> >>
> >> There has indeed been discussion for making native date pickers that
> work in browsers, but date pickers that actually display interactive
> calendars are still a ways off. First all of the browser implementers need
> to agree on how something should be displayed and what it should do, and
> how it should work, and how it should map, and how it should render, and
> how it should be configurable, and so on. To my knowledge nobody has tried
> to spec something like this out as yet. Perhaps some of the browser guys on
> this list may know of something in this regard.
> >
> > fingers crossed.
> > _m
> > > > > > archives at http://webaim.org/discussion/archives
> > >
> > > at http://webaim.org/discussion/archives
> >
> > > > >