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.


-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of _mallory
Sent: Wednesday, November 04, 2015 1:10 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Datepicker questions - are they useful?

On Tue, Nov 03, 2015 at 11:23:16AM -0800, Bryan Garaventa wrote:
> ...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.

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

I'm trying to think of another example where clicking something on a web page would change context, but the only one I can think of is clicking on another file type and the browser or OS knowing whether it should open for example Adobe Reader rather than a PDF in a new tab.

Has there been any discussion in this direction? Especially if it were something a user could set up on their own device (whether to allow a web-page datepicker vs using a built-in one), this could make it mostly a non-issue whether the datepicker works exactly the same cross-device-- it would instead work however the user was used to working anyway.

_mallory