WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Datepicker questions - are they useful?

for

From: Kevin Prince
Date: Nov 10, 2015 2:42PM


Thanks Whitney - that's really useful

Kev
Access1in5
0212220638
039290692
Independent Accessibility and IT Consultancy.



> On 8/11/2015, at 04:57, Whitney Quesenbery < <EMAIL REMOVED> > wrote:
>
> 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
>> >>
>> >> >> >> >>
> > > >