Ein freundlicher Leitfaden für Frontend-Datumsauswähler

• Ein Leitfaden, der statt komplexer JavaScript-Datumsauswähler einfache und barrierearme Eingabemethoden vorschlägt
• Mit nativen Browser-Eingabeelementen (date, time, datetime-local) erhält man automatisch Unterstützung für Barrierefreiheit, Performance und Internationalisierung
• Komplexe UIs lassen sich mit getrennten Eingabefeldern, maskierter Eingabe oder Radio-Button-Gruppen vereinfachen
• Auch in Frameworks wie React können die nativen HTML-Eingabeelemente unverändert verwendet werden; das Styling ist zwar eingeschränkt, dafür bleibt die vertraute System-UI für Nutzer erhalten
• Alle Datumsauswähler haben Barrierefreiheitsprobleme, daher sind eine einfache Eingabestruktur und Tests mit echten Nutzern der Schlüssel zu erfolgreichem Formulardesign

---

Braucht man JavaScript-Datumsauswähler wirklich?

• In den meisten Fällen sind separate JavaScript-Datumsauswähler überflüssig
  • Komplexe UIs führen zu Fehlern und Formularabbrüchen
  • Es gibt einfachere Möglichkeiten zur Datumseingabe als Kalender-Widgets
• Dieser Leitfaden soll Alternativen für benutzerfreundliche Oberflächen aufzeigen

Native Datums- und Uhrzeiteingaben im Browser

• Alle modernen Browser unterstützen die nativen Eingabetypen date, time und datetime-local
  • date dient zur Datumsauswahl, time zur Eingabe von Stunde und Minute, datetime-local kombiniert beides
• Native Eingaben lassen sich mit einer einzigen Codezeile umsetzen, und der Browser übernimmt Barrierefreiheit, Performance und Internationalisierung
  • Unterstützung für Tastatureingabe, Bereitstellung einer nativen Kalender-UI
  • Nicht perfekt, aber in den meisten Fällen stabiler als JavaScript-Bibliotheken
• Einige Barrierefreiheitsprobleme bestehen jedoch weiterhin

Getrennte Eingaben und Auswahlelemente

• Statt eines einzelnen Datumsauswählers verbessert eine getrennte Eingabe für Jahr, Monat und Tag oft die Nutzbarkeit
  • Als Beispiel wird die date-input-Komponente von GOV.UK genannt
• Wenn nur ein begrenzter Bereich gültiger Daten möglich ist, eignet sich ein select-Element
  • Verhindert Eingabefehler, reduziert Interaktionen
  • Bei numerischer Monatsdarstellung auf Fehlinterpretationen durch Screenreader achten
• Bei festen Zeitintervallen, etwa bei Reisebuchungen (z. B. alle 15 Minuten), sind relative Datumsangaben wie „heute“ oder „morgen“ hilfreich

Maskierte Eingabe und Validierung

• Maskierte Eingabefelder sind eine Alternative, um ein Datumsformat ohne Kalender vorzugeben
  • Clientseitige Validierung und Formatierung sind per JavaScript möglich
  • Beispiel: Fehlermeldung wie „Geben Sie einen gültigen Tag im Februar ein (1–28)“
  • Datumsformate lassen sich mit der Intl API automatisch formatieren
• Wenn Eingabewerte per JavaScript aktualisiert werden, kann jedoch die Undo-/Redo-Funktion beeinträchtigt werden
• Mehrere Eingaben lassen sich mit CSS visuell so kombinieren, dass sie wie ein einziges Feld wirken

Bereichsauswahl und begrenzte Optionen

• Bereichs-Datumsauswähler mit zwei Kalendern sind schwer zu bedienen und ohne Zeigegerät unkomfortabel
  • Stattdessen lässt sich die Oberfläche mit zwei Eingabefeldern vereinfachen
• Wenn nur auswählbare Daten benötigt werden, kann eine Radio-Button-Gruppe die bessere Lösung sein
  • Statt komplexer UI besteht der Ablauf aus einfachen, schrittweisen Aufgaben
  • Mehrstufige Formulare lassen sich mit JavaScript zu einer Interaktion auf einer einzigen Seite erweitern

Freie Eingabe und Vorschläge

• Wenn kein exaktes Datum oder keine exakte Uhrzeit benötigt wird, ist ein normales Texteingabefeld nützlich
• Mit dem Element datalist lassen sich Eingabevorschläge bereitstellen
  • Funktioniert auch zusammen mit den Eingabetypen date und time

Häufig gestellte Fragen

Bei Verwendung von JavaScript-Frameworks

• Alle wichtigen Frameworks können native HTML-Elemente verwenden
  • Es ist nicht nötig, dafür eigene Custom Components zu bauen
  • Über das Attribut value ist bidirektionales State-Binding möglich

Styling nativer Datumsauswähler

• Nur ein Teil des input-Elements lässt sich stylen, der Rest nicht
  • Das ist ein Vorteil, weil so die vertraute System-UI für Nutzer erhalten bleibt
  • Das Design unterscheidet sich je nach Betriebssystem, Eingabemethode und Browser
  • Zusätzliche Vereinheitlichung des Designs ist nicht nötig

Umgang mit Stakeholdern, die JavaScript-Datumsauswähler verlangen

• Das Ziel ist eine erfolgreiche Formularübermittlung, und komplexe UIs erhöhen die Fehlerquote
  • Alle Datumsauswähler haben Probleme mit der Barrierefreiheit
  • Kombinationen nativer Eingaben sind benutzerfreundlicher
  • Nicht validierte JavaScript-UIs können gegen Vorschriften wie den European Accessibility Act (EAA) verstoßen
  • Einfachheit ist der Schlüssel zum Erfolg

Tests und Gewährleistung der Barrierefreiheit

• Ein Verständnis von Barrierefreiheitsrichtlinien wie WCAG ist unverzichtbar
  • Durch Nutzung von Webstandards lassen sich Fehler in Custom UIs vermeiden
• Mit den Accessibility-Funktionen in den Entwicklerwerkzeugen der Browser lassen sich Fehler erkennen
  • Es gibt jedoch kein perfektes Tool; Tests mit echten Nutzern sind die einzige verlässliche Prüfmethode
• Vom Einsatz von Accessibility Overlays wird dringend abgeraten, da sie Probleme sogar verschlimmern können

Referenzmaterial zur Barrierefreiheit

• 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

Antwort auf die Frage nach einer Empfehlung für JavaScript-Datumsauswähler

• Es gibt keine universelle Lösung; alle Datumsauswähler haben Grenzen
• Dieser Leitfaden soll dabei helfen, Anforderungen selbst zu bewerten
• Empfohlen wird, das Ziel mit einer möglichst einfachen Methode zu erreichen
• Ein Datumsauswähler ist nicht zwingend erforderlich

Fazit

• Tests mit echten Nutzern und das Sammeln von Feedback sind unverzichtbar
• Dieser Leitfaden ist in Arbeit, Feedback ist willkommen

[GN⁺]

Hacker-News-Kommentar

• Vor einigen Jahren habe ich eine mobile App für Patienten eines regionalen Krankenhauses entwickelt. Unter den Nutzern waren viele ältere Menschen, und es hagelte Beschwerden, dass der systemeigene Date-Picker des OS viel zu unkomfortabel sei
  Es gab tatsächlich Aussagen wie: „Ich kann mein Geburtsjahr nicht einstellen“ oder „Ich musste 720-mal auf den Pfeil für den Vormonat tippen, um zu meinem Geburtstag zu kommen“
  Sowohl unter iOS als auch Android wirkte das Jahr damals wie eine bloße Überschrift und wurde nicht als anklickbares Element erkannt
  Ich hatte das Gefühl, dass ästhetikgetriebenes Flat Design die UX ruiniert. Ich halte es für problematisch, dass die UI von Betriebssystemen eher von Designern als von UX-Experten wie Don Norman bestimmt wird
  Am Ende verschwanden die Beschwerden, nachdem wir auf Textfeld-Dropdown-Textfeld (Tag-Monat-Jahr) umgestellt hatten
  • Auch die Forschung des Gov.uk-Designteams kam zum gleichen Schluss.
    Drei Textfelder (Tag, Monat, Jahr) bieten demnach die beste Nutzererfahrung.
    Es gibt auch einen Pattern Guide für die Umsetzung
  • Ich erinnere mich auch daran, beim ersten Benutzen dieses Eingabefelds über 100-mal getippt und dann gedacht zu haben: „Irgendwas stimmt hier nicht“, woraufhin ich danach gesucht habe. Ein echter UX-Albtraum
  • Die Bedienung war so unintuitiv, dass man spontan reagierte mit: „Das Jahr ist anklickbar??“
  • Ich habe mich in diesem Kalender auch einmal lange herumgequält, weil ich nicht wusste, wie man das Jahr wechselt
  • Ich frage mich aber, warum man für die Eingabe eines Geburtsdatums unbedingt einen Kalender-Picker verwendet hat
• Wenn der Termin feststeht, etwa bei einer Reisebuchung, können relative Datumsangaben wie „heute“ oder „morgen“ praktisch sein
  Wenn man aber rund um Mitternacht einen Flug bucht, ist unklar, ob sich „heute“ auf meine Zeitzone, die Serverzeit oder GMT bezieht
  • Relative Datumsangaben wie „heute“ oder „morgen“ wirken zwar wie eine gute Idee, ihre Umsetzung ist aber die Hölle.
    Es gibt zu viele Ausnahmen: Zeitzonen, Sommerzeit, Monatsende (31. Januar → nächster Monat?), direkt nach Mitternacht usw.
    Bevor man so eine Funktion einbaut, sollte man wirklich sehr vorsichtig sein
  • Der Nahverkehr in Montreal verwendete früher eine 28-Stunden-Uhr. Nach Mitternacht wurden Busse dann etwa als 27:30 angezeigt, was sehr verwirrend war
  • Ich mag es nicht, dass Computer „heute“ anhand von Mitternacht definieren.
    Wenn man nach 0 Uhr noch arbeitet, passt die Bezeichnung „morgen“ nicht mehr zum eigenen Zeitempfinden.
    Gemeint ist in Wirklichkeit „nach heute Morgen“, aber das System erkennt es als nächsten Tag
  • Aber ob „heute“ oder „12. November“ – bei unterschiedlichen Zeitzonen entsteht dasselbe Problem
• Nach über 20 Jahren Erfahrung mit Datepickern bin ich überzeugt: Am besten ist einfach input type="text" mit einem Formathinweis
  Dann muss man sich nicht mit Browser-, Accessibility- und Locale-Problemen herumschlagen
  Custom Components sind wirklich das Tor zur Hölle. Aus unnötigem Styling landet man plötzlich in zehn Rabbit Holes
  • Für bekannte Daten wie Geburtstage ist das in Ordnung, aber wenn man bei einer Flugsuche ungefähr „einen Freitag Anfang April“ sucht, braucht man einen Kalender.
    Man muss das Datum dann visuell erkunden
  • Egal welchen Formathinweis man angibt: Ob „3-9-1980“ für den Nutzer der 9. März oder der 3. September ist, lässt sich nicht zuverlässig erkennen
  • Das ist ein schlechter Rat. ISO 8601 mag für vergangene Zeitpunkte okay sein, passt aber nicht für zukünftige Buchungen oder grenzüberschreitende Termine.
    Datumsprobleme sind wirklich komplex und erfordern einen anwendungsfallspezifischen Ansatz
  • Trotzdem ist es meiner Meinung nach viel besser als ein Kalender, bei dem man auf Mobilgeräten kein Jahr auswählen kann
• Über Internationalisierung zu sprechen und dann nur westliche Datumsformate zu unterstützen, ist lächerlich
  Wenn man ein Krankenhausinformationssystem für Nepal baut, muss man sowohl den nepalesischen Kalender als auch den gregorianischen unterstützen. Der nepalesische Kalender ist sehr komplex
  Äthiopien verwendet einen Kalender mit 13 Monaten, wobei der letzte Monat nur 5 bis 6 Tage hat
  Falls jemand gute Referenzen für einen wirklich internationalisierten Date Picker kennt, würde ich sie gern sehen
• Der Kontext der Datumseingabe sollte bestimmen, welchen Picker man verwendet
  Für eine Abendreservierung ist ein Kalender etwa nützlich, um die Verfügbarkeit am Wochenende zu sehen, während sich ein Geburtstag effizienter als Zahlen eingeben lässt
• Wenn wie bei der Eingabe von Kreditkartendaten der Zahlenfluss wichtig ist,
  dann zerstört ein Ablauf wie „Monatsname wählen → Dropdown → Jahr wählen“ den Rhythmus
  Einfach nur Zahlen einzugeben fühlt sich viel natürlicher an. Auf Mobilgeräten ist es noch lästiger, weil die Tastatur ständig auf- und zugeht
• Einen Date Picker zu sehen, in den man direkt per Tastatur eingeben kann, war erfrischend
  Es ist seltsam, statt der Standard-UI einen Custom Picker zu erzwingen.
  Besonders schlimm war es, auf Android im Web einen iOS-artigen Wheel-Scroller-Zeitpicker nachzuahmen
• Als Däne finde ich den Namen „Pikaday“ lustig. „pik“ ist im Dänischen ein umgangssprachlicher Begriff für Penis
  • Das führte zu Witzen wie: „Sind Pokémon dann auch in Dänemark beliebt?“
• Date-, Time- und DateTime-Picker reichen nicht aus
  Man braucht auch Monats-, Wochen- und benutzerdefinierte Bereichsauswähler. Native Form-Elemente sind viel zu eingeschränkt
  • Ich frage mich, ob bei <input type="week"> oder <input type="month"> außer der Firefox-Unterstützung noch etwas fehlt
  • Ich hätte gern einen KI-Zeitpicker mit der Macht des griechischen Gottes Chronos
• Zur Einordnung: Der Kontext dieser Diskussion steht in einem Artikel über Pikaday
  • Ich erinnere mich, früher auch einmal eine Datepicker-Bibliothek namens Pikaday verwendet zu haben