Online-Buchung und Reservierung barrierefrei: BFSG für Booking-Systeme

Warum Online-Buchungssysteme im BFSG-Fokus stehen

Online-Terminbuchung und Reservierungssysteme sind eine der haeufigsten digitalen Dienstleistungen. Vom Arzt-Termin ueber den Restaurant-Tisch bis zur Friseur-Buchung – ueberall werden Kalender-Widgets und Booking-Formulare eingesetzt. Und genau diese Widgets sind oft die groesste Barrierefreiheits-Schwachstelle auf einer Webseite: Kalender die nur per Mausklick funktionieren, Zeitslots ohne Tastatursteuerung und Bestaetigungen die fuer Screenreader unsichtbar sind.

Gemaess § 1 BFSG fallen digitale Dienstleistungen unter die Barrierefreiheitspflicht – und eine Online-Buchung ist eine digitale Dienstleistung par excellence. Die zugehoerige BFSGV (Barrierefreiheitsstaerkungsverordnung) verweist auf die harmonisierte Norm EN 301 549, die wiederum WCAG 2.1 AA als technischen Standard referenziert. Das bedeutet: Jeder Buchungsschritt – vom Kalender-Widget ueber die Formularfelder bis zur Bestaetigung – muss die WCAG-Kriterien erfuellen.

In der Praxis betrifft das Hotels, Restaurants, Aerzte, Friseure, Fitnessstudios, Coaches, Fotografen und alle anderen Anbieter, die Termine oder Reservierungen online entgegennehmen. Auch wenn du ein Drittanbieter-Widget wie Calendly oder SimplyBook einbindest, bist du als Webseitenbetreiber fuer die Barrierefreiheit auf deiner Seite verantwortlich.

Die haeufigsten Probleme bei Booking-Widgets

Kalender-Picker die nicht per Tastatur navigierbar sind – ein direkter Verstoss gegen WCAG SC 2.1.1 (Tastatur). Zeitslot-Auswahl per Drag-and-Drop statt per Klick/Tastatur. Fehlende ARIA-Labels fuer Kalender-Zellen: Der Screenreader sagt nur „Klickbar“ statt „15. April 2026, Donnerstag, verfuegbar“. Weitere Informationen finden Sie im BFSG-Glossar.

Bestaetigungsnachrichten die nur visuell angezeigt aber nicht per aria-live verkuendet werden (Verstoss gegen SC 4.1.3, Statusmeldungen). Mehrstufige Buchungsprozesse bei denen der Fokus nach jedem Schritt verloren geht. Und: Fehlende Fehleridentifizierung (SC 3.3.1) – wenn ein Datum nicht verfuegbar ist, wird das nur farblich markiert, nicht textlich kommuniziert.

Ein besonders haeufiges Problem: Monatswechsel im Kalender. Viele Datepicker laden den naechsten Monat per AJAX nach, ohne den Screenreader darueber zu informieren. Der Nutzer drueckt „Naechster Monat“, aber es passiert – aus Screenreader-Sicht – nichts.

Barrierefreie Datepicker: Das ARIA Date Picker Pattern

Der Kalender ist das Herzstück jeder Terminbuchung – und gleichzeitig die groesste Huerde. Das W3C ARIA Authoring Practices beschreibt ein konkretes Date Picker Pattern, das als Referenz dient:

Grundstruktur: Der Kalender bekommt role="grid". Jede Zeile ist eine Woche (role="row"), jede Zelle ein Tag (role="gridcell"). Die Wochentags-Kopfzeile nutzt role="columnheader". So versteht ein Screenreader die Tabellen-Struktur.

Labels: Jede Zelle braucht ein aussagekraeftiges aria-label, z. B. aria-label="15. April 2026, Donnerstag, verfuegbar". Nicht verfuegbare Tage bekommen aria-disabled="true" und ein Label wie "15. April 2026, nicht verfuegbar".

Tastatur-Navigation (SC 2.1.1): Pfeiltasten navigieren tageweise (links/rechts) und wochenweise (oben/unten). Pos1/Ende springen zum Wochen-Anfang/-Ende. Bild-auf/Bild-ab wechseln den Monat. Enter oder Leertaste waehlen das Datum aus. Escape schliesst den Datepicker.

Fokus-Management (SC 4.1.2): Der aktuell fokussierte Tag muss per aria-selected="true" oder tabindex="0" gekennzeichnet sein. Beim Monatswechsel bleibt der Fokus auf dem entsprechenden Tag im neuen Monat. Aenderungen werden per aria-live="polite" auf einer versteckten Region verkuendet.

Mehrstufige Buchungsprozesse barrierefrei gestalten

Die meisten Buchungssysteme fuehren den Nutzer durch mehrere Schritte: Leistung waehlen, Datum/Uhrzeit waehlen, persoenliche Daten eingeben, Zusammenfassung pruefen, Buchung bestaetigen. Jeder einzelne Schritt muss WCAG-konform sein.

Fortschrittsanzeige: Nutze eine sichtbare Schrittanzeige (z. B. „Schritt 2 von 4: Datum waehlen“). Der aktive Schritt bekommt aria-current="step". So wissen Screenreader-Nutzer jederzeit, wo sie sich im Prozess befinden.

Fokus-Steuerung: Bei jedem Schrittwechsel muss der Tastaturfokus auf die Ueberschrift oder das erste interaktive Element des neuen Schritts gesetzt werden. Ohne explizites Fokus-Management landet der Fokus am Seitenanfang – der Nutzer muss dann die komplette Navigation erneut durchtabben.

Zurueck-Navigation: Der Nutzer muss jederzeit zum vorherigen Schritt zurueckkehren koennen, ohne Daten zu verlieren. WCAG SC 3.3.4 (Fehlervermeidung) verlangt bei rechtlich bindenden Aktionen die Moeglichkeit, Eingaben zu pruefen und zu korrigieren.

Validierung: Fehlermeldungen muessen direkt beim betroffenen Feld erscheinen, nicht nur als Zusammenfassung am Seitenanfang. Nutze aria-describedby, um die Fehlermeldung mit dem Feld zu verknuepfen (SC 3.3.1). Teste den kompletten Ablauf mit der Tastatur-Checkliste.

Zahlungsintegration: Stripe, PayPal und Co.

Wenn dein Buchungsprozess eine Online-Zahlung beinhaltet, kommen meist Payment-iFrames von Stripe, PayPal oder Klarna zum Einsatz. Diese iFrames sind eigenstaendige Inhalte, fuer die der Zahlungsanbieter die WCAG-Konformitaet verantwortet.

Deine Verantwortung als Webseitenbetreiber: Der iFrame braucht ein aussagekraeftiges title-Attribut, z. B. title="Zahlungsformular – Kreditkarte oder PayPal". Der iFrame muss per Tastatur erreichbar sein (kein tabindex="-1"). Und: Der Uebergang vom Buchungsformular zum Payment-iFrame darf keine Fokus-Falle erzeugen – der Nutzer muss den iFrame auch wieder verlassen koennen (SC 2.1.2, Keine Tastaturfalle).

Stripe Elements und PayPal Smart Buttons sind in der Regel gut getestet. Aeltere Integrationsmethoden (z. B. PayPal-Weiterleitung mit Popup) koennen problematisch sein. Teste die gesamte Zahlungsstrecke per Tastatur und mit NVDA oder VoiceOver.

Bestaetigungs-Seiten und E-Mails

Nach einer erfolgreichen Buchung erwartet der Nutzer eine klare Bestaetigung. WCAG SC 3.3.4 verlangt bei rechtlich bindenden Transaktionen eine ueberpruefbare Zusammenfassung. Zeige mindestens: gebuchte Leistung, Datum und Uhrzeit, Preis, Stornierungsmoeglichkeit.

Die Bestaetigungsseite muss per role="alert" oder aria-live="assertive" verkuendet werden, damit Screenreader die erfolgreiche Buchung sofort mitteilen. Vermeide rein grafische Erfolgsmeldungen (gruenes Haekchen ohne Text).

Bestaetigungs-E-Mails sollten als strukturierter HTML-Text formatiert sein – nicht als Bild-Newsletter. Nutzer mit Screenreadern koennen Bild-E-Mails nicht lesen. Fuege eine Textversion (Multipart-MIME) bei.

Vergiss auch die Stornierungsoption nicht: Wenn Nutzer ihre Buchung online stornieren oder aendern koennen, muss dieser Prozess ebenfalls barrierefrei sein. Der Stornierungslink in der E-Mail muss als echter Link erkennbar sein (nicht nur farblich hervorgehoben) und die Stornierungsseite muss alle WCAG-Kriterien erfuellen.

Beliebte Booking-Tools im Barrierefreiheits-Check

Calendly hat in den letzten Jahren viel fuer Barrierefreiheit getan und ist einer der besseren Anbieter. Die Kalender-Navigation ist per Tastatur moeglich, ARIA-Labels sind vorhanden. Schwachstelle: Die iFrame-Einbettung kann Fokus-Probleme verursachen.

Microsoft Bookings ist relativ gut, weil Microsoft allgemein auf Accessibility achtet. Die Integration in Outlook/Teams ist barrierefrei. Die eigenstaendige Booking-Page erfuellt die meisten WCAG-Kriterien.

SimplyBook.me hat grundlegende ARIA-Attribute, aber Tastaturprobleme beim Kalender. Bookly (WordPress) variiert stark je nach Theme und Konfiguration. Doctolib arbeitet an WCAG-Konformitaet, hat aber noch Luecken bei der Tastatursteuerung.

Eigenbau-Loesungen sind oft am schlechtesten – weil Barrierefreiheit selten von Anfang an mitgedacht wurde. Wenn du selbst ein Buchungssystem baust, orientiere dich am ARIA Date Picker Pattern und teste von Beginn an mit Tastatur und Screenreader.

Tipp: Fordere vor der Entscheidung fuer ein Tool dessen VPAT (Voluntary Product Accessibility Template) oder Accessibility-Statement an. Serioese Anbieter koennen dokumentieren, welche WCAG-Kriterien sie erfuellen – und welche nicht.

Drittanbieter-Widgets: Deine Verantwortung

Ein haeufiges Missverstaendnis: „Das Widget kommt von Calendly/Doctolib/Bookly – die sind verantwortlich, nicht ich.“ Das stimmt nicht. Gemaess § 3 BFSG bist du als Anbieter der digitalen Dienstleistung verantwortlich – unabhaengig davon, welche Software du einsetzt.

Wenn dein eingebettetes Widget nicht barrierefrei ist, hast du drei Optionen: (1) Den Anbieter kontaktieren und auf Barrierefreiheit draengen. (2) Zu einem barrierefreieren Anbieter wechseln. (3) Eine gleichwertige Alternative anbieten – z. B. Buchung per Telefon oder E-Mail, prominent sichtbar neben dem Widget.

Option 3 ist ein Fallback, ersetzt aber nicht die Pflicht zur barrierefreien Webseite. Das BFSG verlangt, dass die digitale Dienstleistung selbst barrierefrei ist – nicht nur ein Umweg ueber einen anderen Kanal. Mehr zu barrierefreien Formularen findest du in unserem Ratgeber Formulare barrierefrei gestalten.

Schritt-fuer-Schritt: Buchungssystem BFSG-konform machen

Schritt 1: Bestandsaufnahme. Pruefe deine Buchungsseite mit dem bf-check Scanner. So erkennst du die groessten Barrieren auf einen Blick.

Schritt 2: Tastatur-Test. Versuche den gesamten Buchungsprozess ausschliesslich per Tastatur abzuschliessen – vom Oeffnen des Kalenders ueber die Datumswahl bis zur finalen Bestaetigung. Unser Ratgeber Tastatur-Bedienbarkeit testen erklaert die Methodik.

Schritt 3: Screenreader-Test. Starte NVDA (Windows) oder VoiceOver (Mac) und navigiere durch den Buchungsprozess. Wird jeder Schritt korrekt verkuendet? Sind Kalender-Zellen mit Datum und Verfuegbarkeit beschriftet?

Schritt 4: Drittanbieter pruefen. Wenn du ein Widget von Calendly, SimplyBook oder Bookly einsetzt: Hat der Anbieter ein Accessibility-Statement? Teste das Widget auf deiner konkreten Seite – die Integration kann Probleme erzeugen, die das Tool allein nicht hat.

Schritt 5: Zahlungsstrecke testen. Ist der Payment-iFrame per Tastatur erreichbar? Hat er einen aussagekraeftigen title? Kann der Nutzer den iFrame wieder verlassen?

Schritt 6: Bestaetigung pruefen. Wird die Buchungsbestaetigung per aria-live verkuendet? Enthaelt sie alle relevanten Informationen? Ist die Bestaetigungs-E-Mail als Text lesbar?

Schritt 7: Dokumentation. Erstelle eine Erklaerung zur Barrierefreiheit und verlinke sie im Footer. Beschreibe, welche Buchungsalternativen es gibt, falls das Widget nicht vollstaendig barrierefrei ist.

Wenn du eine Webseite im Gastgewerbe betreibst, findest du branchenspezifische Hinweise in unserem Artikel BFSG fuer Hotels, Pensionen und Ferienwohnungen.

Häufig gestellte Fragen