WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Datepicker questions - are they useful?

for

From: Bryan Garaventa
Date: Nov 4, 2015 11:01AM

> Hm, a lot of mobiles seem to have their own built-in calendar software and can also run downloaded calendar apps. > I wonder if it would make sense for the
> small devices to, when encountering an input typeÚte, switch context to whatever built-in calendar they've got? > It removes control from web page developers
> but assuming the builtin calendar can accept meta-data from the site (like that only certain dates should be > choosable), we know these calendars are specifically
> built for the tiny screens, built to work with their built-in AT (mags and readers), and for touch. It could also let users > see their own calendar stuff
> at the same time (the in-built calendar may show an appointment on a date the user may be choosing for a trip).

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.

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.