Datepicker barrierefrei: Native vs. Custom und ARIA Grid Pattern

Die Datumsauswahl gehört zu den komplexesten Interaktionsmustern im Web – und zu den am häufigsten fehlerhaft umgesetzten. Ein Kalender-Widget mit Monatsansicht, Navigation zwischen Monaten und Jahren sowie Auswahl einzelner Tage erfordert durchdachte Tastaturnavigation und umfangreiche ARIA-Auszeichnung. Viele beliebte Datepicker-Bibliotheken sind nicht barrierefrei, und selbst native Browser-Datepicker haben Einschränkungen. Für barrierefreie Formulare müssen Sie entweder einen nativen Input mit Fallback oder einen sorgfältig implementierten Custom-Datepicker nach dem W3C APG Pattern einsetzen.

Native input[type="date"] – Vor- und Nachteile

Der native HTML-Datepicker `` ist die einfachste Lösung und bietet in modernen Browsern grundlegende Barrierefreiheit: Screenreader erkennen die Rolle, Tastaturnavigation ist möglich, und die Darstellung passt sich an das Betriebssystem an. Vorteile: Keine JavaScript-Abhängigkeit, mobile Geräte zeigen native Picker-UIs (Scroll-Wheels auf iOS, Kalender auf Android), und die Barrierefreiheit wird vom Browser gewährleistet. Nachteile: Inkonsistente Darstellung zwischen Browsern, eingeschränkte Styling-Möglichkeiten, kein einheitliches Datumsformat (abhängig von der Spracheinstellung des Browsers), und keine Möglichkeit, bestimmte Datumsbereiche visuell hervorzuheben. In Firefox ist der native Datepicker erst seit Version 93 verfügbar. Safari auf macOS bietet erst seit Version 14.1 einen nativen Picker. Empfehlung: Wenn Ihr Anwendungsfall keine spezielle Kalenderdarstellung erfordert, verwenden Sie den nativen Input – er ist die barrierefreieste Lösung. Kombinieren Sie ihn mit einem sichtbaren Label, einem Hinweis zum erwarteten Format (z.B. „TT.MM.JJJJ") und Validierung.

ARIA Grid Pattern für Custom-Datepicker

Wenn ein Custom-Datepicker nötig ist, folgen Sie dem W3C APG Dialog Date Picker Pattern. Die Kalenderansicht wird als `role="grid"` ausgezeichnet, jede Woche als `role="row"`, jeder Tag als `role="gridcell"`. Der aktuelle Tag erhält `aria-selected="true"`, das heutige Datum kann mit `aria-current="date"` markiert werden. Tage außerhalb des wählbaren Bereichs werden mit `aria-disabled="true"` versehen. Die Monats- und Jahresnavigation sitzt in einer Toolbar über dem Grid. Der gesamte Datepicker öffnet sich idealerweise als Dialog (`role="dialog"`) mit `aria-label="Datum auswählen"`. Der Monat und das Jahr über dem Grid sollten als Live-Region funktionieren, damit Screenreader den Monatswechsel ankündigen. Wochentags-Header verwenden `` mit dem vollen Wochentag als `title` oder ausgeschriebene Wochentage mit CSS-Abkürzung. Der aktuell fokussierte Tag im Grid wird über eine Roving-Tabindex-Strategie gesteuert: Nur der fokussierte Tag hat `tabindex="0"`, alle anderen `tabindex="-1"`.

Tastaturnavigation im Kalender-Grid

Die Tastaturnavigation im Datepicker muss intuitiv und effizient sein. Im Kalender-Grid gelten folgende Konventionen nach dem W3C APG Pattern: Pfeiltasten Links/Rechts navigieren tageweise, Pfeiltasten Hoch/Runter wochenweise. Pos1 (Home) springt zum Wochenanfang, Ende (End) zum Wochenende. Bild hoch (Page Up) wechselt zum Vormonat, Bild runter (Page Down) zum nächsten Monat. Shift+Page Up/Down wechselt jahresweise. Enter oder Leertaste wählt das fokussierte Datum aus. Escape schließt den Dialog und kehrt zum Eingabefeld zurück. Tab navigiert zwischen den Steuerungselementen des Datepickers (Vormonat, Nächster Monat, Grid) – nicht zwischen den einzelnen Tagen. Die Pfeiltasten-Navigation im Grid muss am Monatsende automatisch in den nächsten Monat übergehen. Der Fokus muss visuell klar erkennbar sein – verwenden Sie einen deutlichen Fokusring auf der fokussierten Tageszelle mit mindestens 3:1 Kontrast.

Texteingabe als barrierefreie Ergänzung

Der wichtigste Barrierefreiheits-Tipp für Datepicker: Bieten Sie immer eine direkte Texteingabe als Alternative an. Nicht jeder Nutzer kann oder will einen Kalender bedienen – eine einfache Texteingabe mit dem Format „TT.MM.JJJJ" ist für viele Nutzer schneller und einfacher. Das Eingabefeld sollte das erwartete Format als Placeholder oder sichtbaren Hinweis anzeigen. Validieren Sie flexibel: Akzeptieren Sie verschiedene Trennzeichen (Punkt, Schrägstrich, Bindestrich) und führen Sie eine Format-Korrektur durch. Zeigen Sie Validierungsfehler inline an – „Bitte geben Sie ein gültiges Datum im Format TT.MM.JJJJ ein" mit `aria-invalid="true"` und einer verknüpften Fehlermeldung über `aria-describedby`. Der Kalender-Button neben dem Eingabefeld muss `aria-label="Kalender öffnen"` tragen und darf die Texteingabe nicht verhindern oder überschreiben. Bei Datumsbereichen (von-bis) verwenden Sie zwei separate Eingabefelder mit klaren Labels statt eines einzelnen Range-Pickers, da Range-Picker für Screenreader besonders schwer zu bedienen sind. Vorausgefüllte Datumswerte sollten editierbar sein.

Verbreitete Datepicker-Bibliotheken und ihre Barrierefreiheit

Die Barrierefreiheit populärer Datepicker-Bibliotheken variiert erheblich. Duet Date Picker wurde explizit für Barrierefreiheit entwickelt und folgt dem W3C APG Pattern. React-Datepicker ist weit verbreitet, hat aber bekannte Accessibility-Probleme bei der Tastaturnavigation. Flatpickr bietet grundlegende Tastaturnavigation, aber unzureichende ARIA-Auszeichnung. Pikaday ist veraltet und hat erhebliche Barrierefreiheitsmängel. Material UI DatePicker in neueren Versionen bietet solide Barrierefreiheit, erfordert aber korrekte Konfiguration. Empfehlung: Evaluieren Sie jede Bibliothek vor dem Einsatz mit einem Screenreader und Tastatur-Only-Test. Prüfen Sie, ob die Bibliothek das ARIA Grid Pattern korrekt implementiert, ob Monatswechsel angekündigt werden und ob die Tastaturnavigation dem W3C-Standard folgt. Im Zweifel ist ein nativer `input[type="date"]` mit Fallback-Texteingabe barrierefreier als eine schlecht implementierte Custom-Lösung.