Guide pratique des sélecteurs de date côté front-end

• Un guide qui propose des méthodes de saisie simples et accessibles à la place des sélecteurs de date JavaScript complexes
• En utilisant les champs natifs du navigateur (date, time, datetime-local), on bénéficie automatiquement de l’accessibilité, des performances et de la prise en charge de l’internationalisation
• Il est possible de simplifier une UI complexe avec des champs séparés, des champs masqués ou des groupes de boutons radio
• Même avec des frameworks comme React, on peut utiliser directement les champs HTML natifs ; le style est limité, mais cela conserve une UI système familière pour l’utilisateur
• Tous les sélecteurs de date posent des problèmes d’accessibilité ; une structure de saisie simple et des tests avec de vrais utilisateurs sont la clé d’un formulaire réussi

---

A-t-on vraiment besoin d’un sélecteur de date JavaScript ?

• Dans la plupart des cas, un sélecteur de date JavaScript distinct est inutile
  • Une UI complexe provoque des erreurs et des abandons de formulaire
  • Il existe des méthodes de saisie de date plus simples qu’un widget calendrier
• Ce guide vise à présenter des alternatives pour une interface pensée pour l’utilisateur

Champs natifs du navigateur pour la date et l’heure

• Tous les navigateurs modernes prennent en charge les types de champs natifs date, time et datetime-local
  • date sert à choisir une date, time à saisir l’heure et les minutes, datetime-local combine les deux
• Les champs natifs peuvent être mis en place avec une seule ligne de code, et le navigateur gère l’accessibilité, les performances et l’internationalisation
  • Saisie au clavier prise en charge, UI calendrier fournie par défaut
  • Ce n’est pas parfait, mais c’est généralement plus fiable que la plupart des bibliothèques JavaScript
• Cela dit, certains problèmes d’accessibilité subsistent

Champs séparés et éléments de sélection

• Au lieu d’un seul sélecteur de date, séparer année, mois et jour améliore l’utilisabilité
  • Exemple cité : le composant de saisie de date de GOV.UK
• Quand les données valides sont limitées, il est pertinent d’utiliser un élément select
  • Cela évite les erreurs de saisie et réduit les interactions
  • Attention à la mauvaise lecture des mois en chiffres par les lecteurs d’écran
• Pour les créneaux fixes, comme dans la réservation de voyage (par exemple toutes les 15 minutes), il est utile d’employer des dates relatives comme aujourd’hui ou demain

Champs masqués et validation

• Les champs de saisie masqués constituent une alternative qui guide le format de date sans calendrier
  • La validation et le formatage côté client peuvent être gérés en JavaScript
  • Exemple : « Saisissez un jour valide de février (1 à 28) » comme message d’erreur
  • L’API Intl permet de formater automatiquement la date
• En revanche, si JavaScript met à jour la valeur saisie, les fonctions annuler/rétablir peuvent être cassées
• Il est aussi possible, avec CSS, de regrouper visuellement plusieurs champs pour qu’ils ressemblent à un seul

Sélection d’intervalle et options limitées

• Les sélecteurs d’intervalle avec deux calendriers sont difficiles à manipuler et peu pratiques sans pointeur
  • On peut les simplifier avec deux champs de saisie à la place
• Si seules certaines dates doivent être proposées, on peut les remplacer par un groupe de champs radio
  • Au lieu d’une UI complexe, on obtient une suite d’étapes simples
  • Un formulaire multi-étapes peut être étendu en interaction sur une seule page via JavaScript

Saisie libre et suggestions

• Quand une date ou une heure exacte n’est pas nécessaire, un champ texte standard peut être utile
• L’élément datalist permet de fournir des suggestions de saisie
  • Il fonctionne aussi avec les types de champ date et time

Questions fréquentes

En cas d’utilisation d’un framework JavaScript

• Tous les principaux frameworks permettent d’utiliser les éléments HTML natifs
  • Il n’est pas nécessaire d’en faire des composants custom
  • Une liaison d’état bidirectionnelle est possible via l’attribut value

Styliser le sélecteur de date natif

• Seule une partie de l’élément input peut être stylée, le reste ne le peut pas
  • C’est aussi un avantage, car cela conserve une UI système familière pour l’utilisateur
  • Le design varie selon le système d’exploitation, le mode de saisie et le navigateur
  • Une uniformisation visuelle supplémentaire n’est pas nécessaire

Comment répondre aux parties prenantes qui exigent un sélecteur de date JavaScript

• L’objectif est de réussir l’envoi du formulaire, et une UI complexe augmente les erreurs
  • Tous les sélecteurs de date ont des problèmes d’accessibilité
  • Une combinaison de champs natifs est plus conviviale
  • Une UI JavaScript non vérifiée peut contrevenir à des réglementations comme l’European Accessibility Act (EAA)
  • La simplicité est la clé du succès

Tests et garantie d’accessibilité

• Il est indispensable de comprendre les recommandations d’accessibilité comme les WCAG
  • S’appuyer sur les standards du Web permet d’éviter les erreurs des UI custom
• Les fonctions d’accessibilité des outils de développement du navigateur permettent de détecter des erreurs
  • Aucun outil n’est parfait, et les tests avec de vrais utilisateurs sont le seul moyen de validation
• L’usage d’overlays d’accessibilité est fortement déconseillé, car ils peuvent aggraver les problèmes

Références sur l’accessibilité

• Collecting dates in an accessible way — Graham Armfield
• What makes an accessible date picker? — Russ Weakley
• Maybe You Don’t Need a Date Picker — Adrian Roselli
• Date Picker Dialog Example — ARIA Authoring Practices Guide
• Designing The Perfect Date And Time Picker — Vitaly Friedman

Réponse à une demande de recommandation de sélecteur de date JavaScript

• Il n’existe pas de solution universelle : tous les sélecteurs de date ont leurs limites
• Ce guide a pour but d’aider à évaluer soi-même les besoins
• Il recommande d’atteindre l’objectif avec la méthode la plus simple possible
• Un sélecteur de date n’est pas forcément nécessaire

Conclusion

• Tester avec de vrais utilisateurs et recueillir leurs retours est indispensable
• Ce guide est en cours d’évolution et les retours sont bienvenus

[GN⁺]

Commentaire Hacker News

• Il y a quelques années, j’ai créé une appli mobile pour les patients d’un hôpital local. Beaucoup d’utilisateurs étaient âgés, et les plaintes sur le sélecteur de date natif de l’OS affluaient
  du genre « impossible de définir sa date de naissance » ou « j’ai dû appuyer 720 fois sur la flèche du mois précédent pour arriver à mon anniversaire »
  Sur iOS comme sur Android à l’époque, l’année ressemblait juste à un titre, donc elle n’était pas perçue comme un élément cliquable
  J’avais l’impression que le Flat Design, centré sur l’esthétique, ruinait l’UX. Le vrai problème, selon moi, c’est que l’interface des OS était décidée par des designers plutôt que par des experts UX comme Don Norman
  Au final, dès qu’on est passés à un format zone de texte - liste déroulante - zone de texte (jour-mois-année), les plaintes ont disparu
  • Une étude de l’équipe design de Gov.uk est arrivée à la même conclusion.
    Trois zones de texte (jour, mois, année) offrent la meilleure expérience.
    Il existe aussi un guide de patterns pour l’implémentation
  • Je me souviens aussi avoir tapoté plus de 100 fois sur ce champ la première fois avant de me dire « il y a un truc qui cloche » et de chercher sur le web. Un vrai cauchemar UX
  • Le manque d’intuitivité était tel qu’on en arrivait à réagir par un « L’année est cliquable ?? »
  • Moi aussi, il m’est arrivé d’errer longtemps dans ce calendrier faute de comprendre comment changer d’année
  • Et je me demande pourquoi ils ont tenu à utiliser un calendar picker pour la date de naissance
• Quand on réserve un voyage ou un créneau déjà cadré, des expressions de date relatives comme « aujourd’hui » ou « demain » peuvent être pratiques
  Mais si on réserve un vol vers minuit, on ne sait plus si « aujourd’hui » veut dire aujourd’hui dans mon fuseau, côté serveur ou en GMT
  • Des dates relatives comme « aujourd’hui » ou « demain » ont l’air d’une bonne idée, mais leur implémentation est un enfer.
    Entre les fuseaux horaires, l’heure d’été, les fins de mois (31 janvier → mois suivant ?), juste après minuit, il y a trop de cas limites.
    Il faut vraiment réfléchir à deux fois avant d’ajouter ce genre de fonctionnalité
  • Les transports publics de Montréal utilisaient autrefois une horloge sur 28 heures. Après minuit, les bus étaient indiqués comme 27:30, ce qui était extrêmement déroutant
  • Je n’aime pas que l’ordinateur définisse « aujourd’hui » à partir de minuit.
    Quand on travaille après 0 h, le mot « demain » ne correspond plus à la perception réelle.
    En pratique, on veut dire « après ce matin », mais le système comprend déjà le jour suivant
  • Mais que ce soit « aujourd’hui » ou « 12 novembre », si le fuseau change, le même problème se pose
• Après plus de 20 ans à gérer des datepickers, mon expérience est qu’il vaut mieux simplement utiliser input type="text" avec une indication de format
  Ça évite les galères liées aux navigateurs, à l’accessibilité et aux locales
  Les composants custom, c’est vraiment ouvrir les portes de l’enfer. On veut faire joli et on finit dans dix terriers de lapin
  • Pour une date déjà connue comme un anniversaire, ça va, mais pour chercher un vol vers « un vendredi début avril », il faut un calendrier.
    Parce qu’il faut explorer visuellement les dates
  • Quel que soit le format affiché en aide, on ne peut pas faire confiance à « 3-9-1980 » : pour l’utilisateur, ça peut être le 9 mars ou le 3 septembre
  • C’est un mauvais conseil. ISO 8601 convient pour des dates passées, mais pas pour des réservations futures ni des plannings transfrontaliers.
    Les questions de date sont vraiment complexes, il faut une approche selon le cas d’usage
  • Cela dit, c’est quand même bien mieux qu’un calendrier mobile où on ne peut pas sélectionner l’année
• Parler d’internationalisation tout en ne prenant en charge que les formats de date occidentaux, c’est assez comique
  Si on construisait un système hospitalier pour le Népal, il faudrait prendre en charge le calendrier népalais et le calendrier grégorien. Le calendrier népalais est très complexe
  L’Éthiopie utilise un calendrier à 13 mois, dont le dernier ne dure que 5 à 6 jours
  Si quelqu’un connaît une bonne ressource sur un date picker internationalisé digne de ce nom, je suis preneur
• Le contexte de saisie de la date doit déterminer le type de picker à utiliser
  Par exemple, pour réserver un dîner, un calendrier est utile pour visualiser les disponibilités du week-end, alors que pour une date de naissance, une saisie numérique rapide est plus efficace
• Quand le flux de saisie numérique est important, comme pour les informations de carte bancaire,
  des étapes du type « choisir le nom du mois → liste déroulante → choisir l’année » cassent le rythme
  Une simple saisie au clavier est bien plus naturelle. Sur mobile, c’est encore pire parce que le clavier s’ouvre et se ferme en permanence
• Voir un date picker dans lequel on peut taper directement au clavier, c’est rafraîchissant
  Forcer un picker custom à la place de l’interface native, c’est étrange.
  Surtout quand on imite sur le web le sélecteur d’heure à molette façon iOS sur Android : ça, c’est le pire
• En tant que Danois, le nom « Pikaday » me fait rire. « pik » est un argot pour le sexe masculin en danois
  • Au point qu’on faisait la blague : « Donc Pokémon est populaire au Danemark aussi ? »
• Les pickers Date, Time et DateTime ne suffisent pas
  Il faut aussi des sélecteurs au mois, à la semaine et à plage personnalisée. Les éléments de formulaire natifs sont trop limités
  • Je me demande s’il manque autre chose à <input type="week"> ou <input type="month">, à part le support Firefox
  • J’aimerais bien avoir un picker temporel IA puisant dans le pouvoir de Chronos, dieu grec
• Pour référence, le contexte de cette discussion se trouve dans ce billet sur Pikaday
  • Je me souviens avoir utilisé autrefois une bibliothèque de datepicker appelée Pikaday