WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Date-Picker native or Plug-in?

for

Number of posts in this thread: 3 (In chronological order)

From: Sven Jenzer
Date: Wed, Jul 13 2022 2:59AM
Subject: Date-Picker native or Plug-in?
No previous message | Next message →

We are investigating if we can replace outdated plug-in with native date picker on a responsive web site. There are some known bugs, e.g: in Safari browser you can choose 31. Feb. Nevertheless we assume accessibility is good with the ones built into the browser and maintenance is easier. We assume also that users are familiar with it.

Are there any arguments against this step?
What are your experiences?

Best,
Sven Jenzer

From: Patrick H. Lauke
Date: Wed, Jul 13 2022 6:04AM
Subject: Re: Fwd: Date-Picker native or Plug-in?
← Previous message | Next message →

For some reason this reply didn't make it to the list?

P

-------- Forwarded Message --------
Subject: Re: [WebAIM] Date-Picker native or Plug-in?
Date: Wed, 13 Jul 2022 11:12:54 +0100
From: Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
To: = EMAIL ADDRESS REMOVED =

On 13/07/2022 09:59, Sven Jenzer wrote:
> We are investigating if we can replace outdated plug-in with native date picker on a responsive web site. There are some known bugs, e.g: in Safari browser you can choose 31. Feb. Nevertheless we assume accessibility is good with the ones built into the browser and maintenance is easier. We assume also that users are familiar with it.

I would be careful just making an assumption that the browser's built-in
picker will be accessible. Suggest a bit of exploration/testing with all
different browser/AT variations.

(just reminded of how Firefox's native <video> player used to be
completely non-keyboard-operable until not so long ago)

Also, keep in mind that the native date picker input is really limited
in terms of stylability, and in terms of functionality - it can only be
used to select a single date, and without any further information
conveyed in the calendar view. If that's your use case, great. But if
you need to have a picker where certain dates are already highlighted
(because there's, say, an event happening on that date), or where
certain dates are disabled (e.g. because there's no more available slots
on that day), or anything involving selecting a date range with a start
and end date all in the same widget, then you won't be able to use the
native picker.

Lastly...consider your fallback for cases where your users don't have
the latest and greatest version of their browser. Is it acceptable to
fall back to basic text input in those cases? If yes, cool cool.
Otherwise, might need to still resort to plug-in (after doing a
capability check in JS to see if it's needed, and only load the plug-in
solution conditionally).

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Patrick H. Lauke
Date: Wed, Jul 13 2022 4:12AM
Subject: Re: Date-Picker native or Plug-in?
← Previous message | No next message

On 13/07/2022 09:59, Sven Jenzer wrote:
> We are investigating if we can replace outdated plug-in with native date picker on a responsive web site. There are some known bugs, e.g: in Safari browser you can choose 31. Feb. Nevertheless we assume accessibility is good with the ones built into the browser and maintenance is easier. We assume also that users are familiar with it.

I would be careful just making an assumption that the browser's built-in
picker will be accessible. Suggest a bit of exploration/testing with all
different browser/AT variations.

(just reminded of how Firefox's native <video> player used to be
completely non-keyboard-operable until not so long ago)

Also, keep in mind that the native date picker input is really limited
in terms of stylability, and in terms of functionality - it can only be
used to select a single date, and without any further information
conveyed in the calendar view. If that's your use case, great. But if
you need to have a picker where certain dates are already highlighted
(because there's, say, an event happening on that date), or where
certain dates are disabled (e.g. because there's no more available slots
on that day), or anything involving selecting a date range with a start
and end date all in the same widget, then you won't be able to use the
native picker.

Lastly...consider your fallback for cases where your users don't have
the latest and greatest version of their browser. Is it acceptable to
fall back to basic text input in those cases? If yes, cool cool.
Otherwise, might need to still resort to plug-in (after doing a
capability check in JS to see if it's needed, and only load the plug-in
solution conditionally).

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke