Ein Friseursalon, eine Physiotherapie-Praxis oder eine Kfz-Werkstatt lebt heute von der Online-Terminvergabe: Wer abends um elf einen Termin sucht, klickt sich durch einen Kalender, wählt einen Tag und bestätigt. Genau an dieser Stelle scheitern viele Websites, ohne dass es jemand bemerkt - denn ein selbstgebauter Datepicker, der sich nur mit der Maus bedienen lässt, schließt alle Menschen aus, die per Tastatur oder Screenreader navigieren. Seit dem 28. Juni 2025 (Bundesfachstelle Barrierefreiheit) verlangt das Barrierefreiheitsstärkungsgesetz für weite Teile des digitalen Verbrauchergeschäfts eine bedienbare Oberfläche, und Buchungsstrecken stehen dabei besonders im Fokus. Wie verbreitet Barrieren sind, zeigt der WebAIM Million Report 2026: Auf 95,9 Prozent (WebAIM Million, 2026) der untersuchten Startseiten fanden sich nachweisbare WCAG-Fehler. Dieser Leitfaden erklärt, warum Kalender-Widgets zu den häufigsten Fehlerquellen zählen und wie eine Terminbuchung aussieht, die sich per Pfeiltaste, mit sauberem Fokus-Management und ausreichender Zielgröße wirklich bedienen lässt - Grundlagen, die wir in jedem WCAG-Audit prüfen.
Das Wichtigste in Kürze
- Die Terminbuchung ist eine Kernfunktion und fällt damit unter die Prüfung der Marktüberwachung - ein Kalender, der sich nicht per Tastatur bedienen lässt, macht die gesamte Buchung unzugänglich.
- Selbstgebaute Datepicker verletzen erfahrungsgemäß mehrere Kriterien zugleich: fehlende Tastaturbedienung (WCAG 2.1.1), unklare Fokusreihenfolge (WCAG 2.4.3) und fehlende Rollen und Namen (WCAG 4.1.2) (W3C).
- Ein zugänglicher Kalender funktioniert wie ein Raster: Die Pfeiltasten bewegen den Fokus von Tag zu Tag, Bild-auf und Bild-ab wechseln den Monat, wie es der WAI-ARIA Authoring Practices Guide beschreibt (W3C).
- Seit WCAG 2.2 gilt eine Zielgröße von mindestens 24 x 24 (W3C) CSS-Pixeln als Erfolgskriterium 2.5.8 - zu kleine Tagesfelder sind damit ein klarer Verstoß.
- Das Fokus-Management entscheidet über die Bedienbarkeit: Öffnet sich der Kalender, muss der Fokus hinein; beim Schließen kehrt er sauber auf das auslösende Feld zurück.
- Die native Alternative ist oft die robusteste Lösung: Ein echtes Datumsfeld erbt Tastaturbedienung und Screenreader-Unterstützung vom Browser - eine belastbare Rückfallebene für die barrierefreie Webentwicklung.
Warum die Terminbuchung zur Pflicht wird
Das Barrierefreiheitsstärkungsgesetz setzt die europäische Richtlinie in deutsches Recht um und erfasst seit dem 28. Juni 2025 (Bundesfachstelle Barrierefreiheit) unter anderem Dienstleistungen im elektronischen Geschäftsverkehr. Eine Online-Terminbuchung ist genau das: der digitale Zugang zu einer Dienstleistung. Wenn der erste Schritt dieses Zugangs - die Auswahl eines Tages im Kalender - nicht bedienbar ist, bleibt die gesamte Leistung verschlossen. Der technische Prüfmaßstab dahinter ist die harmonisierte europäische Norm EN 301 549, die wiederum auf die Erfolgskriterien der WCAG verweist. Wer die Anforderungen kennen will, findet die Grundlagen in den BFSG-Anforderungen aufbereitet.
Neu ist 2026 nicht das Gesetz selbst, sondern die Durchsetzung: Die Marktüberwachungsbehörden der Länder prüfen inzwischen stichprobenartig und auf Beschwerde, ob Kernfunktionen tatsächlich zugänglich sind. Eine Buchungsstrecke ist eine solche Kernfunktion. Wie eine Prüfung konkret abläuft, welche Nachweise verlangt werden und welche Fristen gelten, beschreibt der Beitrag zur BFSG-Marktüberwachung und dem Prüfablauf. Für Betriebe mit Online-Terminvergabe verschiebt sich damit die Frage von "ob" zu "wie schnell": Ein fragiler Eigenbau ist nicht nur ein Ausschlusskriterium für einen Teil der Kundschaft, sondern auch ein konkretes Risiko in einer Prüfung.
Eine Barriere im Kalender blockiert die ganze Buchung
Wo selbstgebaute Datepicker scheitern
Teams bauen Kalender-Widgets oft selbst, weil sie das Design bis ins Detail kontrollieren wollen oder weil eine fertige Komponente nicht zum Markenauftritt passt. Das ist legitim - problematisch wird es, wenn dabei das nachgebaut wird, was ein Nutzer sieht, aber nicht das, was assistive Technik braucht. Ein Tag ist dann ein anklickbares div statt eines button, der Dialog ist ein absolut positioniertes Overlay ohne Rolle, und die Bedienung ist ausschließlich auf Mausklicks ausgelegt. Für sehende Maus-Nutzer sieht alles korrekt aus; für Tastatur- und Screenreader-Nutzer existiert die Funktion faktisch nicht. Die sechs häufigsten Bruchstellen lassen sich klar benennen.
Tastaturbedienung
Ohne Fokusreihenfolge und Tastenlogik bleibt der Kalender für Tab- und Pfeiltasten-Nutzer unerreichbar - ein Verstoß gegen WCAG 2.1.1 (W3C).
Zielgröße
Tagesfelder unter 24 x 24 (W3C) CSS-Pixeln verfehlen das WCAG-Kriterium 2.5.8 und sind auf dem Touchscreen kaum treffsicher zu bedienen.
Fokus-Management
Öffnet der Kalender, ohne den Fokus mitzunehmen, sucht der Screenreader-Nutzer ins Leere - die Fokusreihenfolge nach WCAG 2.4.3 bricht (W3C).
Rollen und Namen
Ein div statt eines button hat weder Rolle noch zugänglichen Namen; WCAG 4.1.2 verlangt beides, damit die Ansage überhaupt entsteht (W3C).
Status und Fehler
Belegte oder gesperrte Termine werden oft nur farblich markiert; ohne Ansage über eine Live-Region bleibt der Konflikt für Screenreader unsichtbar.
Kontrast
Der markierte Tag hebt sich zu blass ab. Kontrast ist mit 83,9 Prozent (WebAIM Million, 2026) betroffener Startseiten ohnehin die häufigste Barriere.
Diese Fehler treten selten einzeln auf. Ein Widget, das die Tastatur ignoriert, hat meist auch keine Rollen und keine Live-Region - und genau solche Häufungen erklären, warum die durchschnittliche Startseite im WebAIM Million Report 2026 auf 56,1 (WebAIM Million, 2026) Fehler kam. Leere, unbeschriftete Bedienelemente sind mit 46,3 Prozent (WebAIM Million, 2026) betroffener Seiten ein verwandtes Muster: Ein Icon-Button ohne Namen ist für Tastatur, Screenreader und Suchmaschine gleichermaßen ein Nichts. Die gute Nachricht ist, dass sich alle sechs Bruchstellen mit etablierten Mustern beheben lassen.
Tastaturbedienung: der Kalender als Raster
Das Vorbild für einen zugänglichen Kalender ist der Date Picker Dialog aus dem WAI-ARIA Authoring Practices Guide (W3C). Dort ist der Kalender ein Raster (grid), in dem sich der Fokus mit den Pfeiltasten von Zelle zu Zelle bewegt. Diese Logik ist für Screenreader-Nutzer vertraut, weil sie derselben Systematik wie eine Tabelle folgt: Man tastet sich Tag für Tag, Woche für Woche voran. Der auslösende Button trägt eine klare Beschriftung und das Attribut aria-haspopup, sodass angesagt wird, dass sich ein Dialog öffnet. Innerhalb des Rasters gilt ein festes Tastaturschema, das jeder Kalender erfüllen sollte.
- Pfeil links und rechts bewegen den Fokus um einen Tag zurück oder vor
- Pfeil hoch und runter springen um eine Woche nach oben oder unten
- Bild-auf und Bild-ab wechseln zum vorherigen oder nächsten Monat
- Pos1 und Ende springen an den Wochenanfang und das Wochenende
- Eingabe oder Leertaste wählen den fokussierten Tag aus und bestätigen
- Escape schließt den Dialog und gibt den Fokus an das Datumsfeld zurück
Entscheidend ist, dass immer nur der gerade fokussierte Tag im Tab-Fluss liegt (roving tabindex), damit sich der Nutzer nicht durch 31 einzelne Elemente hangeln muss. Wer diese Grundlagen vertiefen möchte, findet in der Tastaturnavigation in der Webentwicklung die allgemeinen Muster für Fokusreihenfolge und sichtbaren Fokus. Für das Textfeld, in das ein Datum auch direkt getippt werden kann, liefert das Combobox-Muster des WAI-ARIA Authoring Practices Guide (W3C) die passende Ergänzung.
Fokus-Management beim Öffnen und Schließen
Ein Kalender-Dialog verhält sich technisch wie ein modales Overlay - und erbt damit dessen Anforderungen. Beim Öffnen muss der Fokus in den Dialog wandern, idealerweise auf den heutigen oder den bereits gewählten Tag. Solange der Dialog offen ist, bleibt der Fokus darin gefangen (Fokus-Falle), damit die Tabulatortaste nicht unbemerkt in die dahinterliegende Seite abwandert. Beim Schließen - ob per Auswahl, per Escape oder per Klick daneben - kehrt der Fokus exakt auf das auslösende Datumsfeld zurück. Verliert der Fokus an dieser Stelle den Faden, landet der Nutzer unvermittelt am Seitenanfang und muss sich neu orientieren.
Diese Choreografie ist kein Kalender-Sonderfall, sondern gilt für jedes Overlay. Wie sie sich sauber umsetzen lässt, zeigen die Beiträge zu barrierefreien Modals und Overlays und zum Fokus-Management in Single-Page-Apps - gerade in Frameworks, die den DOM dynamisch neu aufbauen, geht der Fokus sonst leicht verloren.
Der Fokus ist der Cursor des Tastatur-Nutzers
Zielgröße: 24 Pixel für jeden Tag
Mit WCAG 2.2, seit dem 5. Oktober 2023 offizielle Empfehlung des W3C (W3C), kam das Erfolgskriterium 2.5.8 Zielgröße (Minimum) hinzu. Es verlangt, dass Bedienelemente mindestens 24 x 24 (W3C) CSS-Pixel groß sind oder einen entsprechenden Abstand zueinander haben - mit wenigen Ausnahmen etwa für Elemente im Fließtext. Für einen Kalender heißt das konkret: Jedes einzelne Tagesfeld ist ein Bedienelement und muss die Schwelle erfüllen. Winzige Zahlen in einem engen Raster verfehlen sie regelmäßig, besonders auf dem Smartphone, wo der Finger deutlich ungenauer trifft als der Mauszeiger. WCAG 2.2 brachte insgesamt 9 (W3C) neue Kriterien; die wichtigsten für Buchungen fasst der Beitrag zu den neuen WCAG-2.2-Kriterien zusammen.
| Vorgabe | Zielgröße | Kontext |
|---|---|---|
| WCAG 2.5.8 (Minimum) | 24 x 24 CSS-Pixel | Erfolgskriterium AA, seit WCAG 2.2 Pflicht |
| WCAG 2.5.5 (Enhanced) | 44 x 44 CSS-Pixel | Erfolgskriterium AAA, empfohlener Zielwert |
| Apple Human Interface Guidelines | 44 x 44 Punkt | Empfehlung für Tippziele unter iOS |
| Google Material Design | 48 x 48 dp | Empfehlung für Touch-Ziele unter Android |
Die 24-Pixel-Marke ist die gesetzlich relevante Untergrenze, nicht das Ideal. Die höheren Werte der Plattform-Empfehlungen von Apple (Apple Human Interface Guidelines) und Google (Google Material Design) zeigen, dass großzügige Tippziele auch außerhalb der Barrierefreiheit als gute Praxis gelten - sie senken Fehlbedienungen für alle. Wer den Kalender ohnehin überarbeitet, sollte die Tagesfelder eher an den 44 Pixeln orientieren und den Kontrast des markierten Tages ausreichend hoch wählen, damit die Auswahl nicht nur über Farbe erkennbar ist.
Belegte Termine, Fehler und Bestätigung
Ein Kalender zeigt nicht nur Tage, sondern auch Zustände: ausgebucht, gesperrt, nur vormittags frei. Werden diese Zustände allein farblich dargestellt, entgehen sie Screenreader-Nutzern und Menschen mit Farbfehlsichtigkeit vollständig. Die Lösung ist eine programmatische Auszeichnung - etwa aria-disabled für nicht wählbare Tage - kombiniert mit einer verständlichen Textinformation. Wählt jemand ein volles Zeitfenster, gehört die Rückmeldung in eine Live-Region, damit sie ohne Fokuswechsel angesagt wird. Wie sich solche Status- und Fehlermeldungen zugänglich gestalten, vertieft der Beitrag zu barrierefreien Fehler- und Statusmeldungen.
Nach der Datumsauswahl folgen weitere Formularschritte - Name, Kontakt, Anliegen. Auch sie brauchen sichtbare Beschriftungen, eine klare Fehlervermeidung und eine bestätigende Zusammenfassung, wie sie die Systematik der barrierefreien Formulare und Validierung beschreibt. Schließt der Termin mit einer Rechnung oder einem Beleg ab, reicht die Zugänglichkeit bis ins Dokument hinein; welche Formate dafür geeignet sind, zeigt der Beitrag zur barrierefreien E-Rechnung mit XRechnung und ZUGFeRD.
Native Alternativen und geprüfte Muster
Die verlässlichste Abkürzung führt über das native Datumsfeld des Browsers. Ein input vom Typ date bringt Tastaturbedienung, Screenreader-Ansage und eine plattformgerechte Bedienoberfläche von Haus aus mit - ohne dass ein Team die gesamte Tastaturlogik nachbauen muss. Für viele Buchungsstrecken ist das die robusteste Basis, ergänzt um klare Beschriftungen und Hinweise zum erwarteten Format. Wo das Design einen individuellen Kalender verlangt, gilt der Grundsatz: nicht neu erfinden, sondern ein geprüftes Muster umsetzen. Der Date Picker Dialog des WAI-ARIA Authoring Practices Guide (W3C) ist als Blaupause frei verfügbar und deckt Tastatur, Rollen und Fokus bereits ab. In unseren Referenzprojekten beginnt die Umsetzung deshalb mit der Frage, ob ein Eigenbau überhaupt nötig ist.
Der beste Datepicker ist oft der, den man nicht selbst geschrieben hat. Ein natives Datumsfeld oder ein geprüftes Muster bedient Tastatur und Screenreader zuverlässiger als jeder schöne Nachbau, der die assistive Technik vergisst.
Am Ende steht die Prüfung, denn ein automatischer Scan erkennt fehlende Rollen oder zu kleine Ziele, beurteilt aber nicht, ob sich der Kalender wirklich bedienen lässt. Das zeigt erst der manuelle Test - einmal komplett mit der Tastatur und einmal mit einem Screenreader durch die Buchung. Diese Kombination ist der Kern eines belastbaren WCAG-Audits und macht aus einem unsicheren Eigenbau eine Buchungsstrecke, die alle bedienen können. Angesichts von 95,9 Prozent (WebAIM Million, 2026) fehlerhafter Startseiten ist das weniger eine Kür als die Voraussetzung dafür, dass aus einem Besuch ein Termin wird.