Barrierefreie Terminbuchung: Praxis, Kanzlei, Handwerk, Dienstleistung

Das Wichtigste in Kürze

• § 1 Absatz 3 Nummer 5 BFSG nennt „Dienstleistungen im elektronischen Geschäftsverkehr“. Eine Online-Terminvergabe, über die Verbraucher verbindlich buchen, kann darunterfallen – bei Praxis, Kanzlei, Handwerksbetrieb, Friseur und Werkstatt gleichermaßen.
• Die Kleinstunternehmer-Ausnahme nach § 3 Absatz 3 BFSG greift bei vielen kleinen Betrieben – aber nur, wenn beide Bedingungen zusammen erfüllt sind: weniger als zehn Beschäftigte und höchstens 2 Millionen Euro Jahresumsatz oder Bilanzsumme.
• Der schwierigste Baustein ist das Kalender-Widget: Datumsauswahl mit der Tastatur, ein vollständig angesagtes Datum, ein sichtbarer Fokus. Die Alternative „Datum eintippen“ ist der Rettungsanker.
• Kommt das Buchungstool von einem Anbieter, stellen Sie ihm vier Fragen – schriftlich. Was eine gute Antwort ist, steht unten.
• Ein Telefon daneben hilft vielen. Das Gesetz kennt aber keinen Ersatzkanal, und gleichwertig ist ein Telefon nur unter Bedingungen, die selten erfüllt sind.
• Der Selbsttest in zehn Minuten: einmal mit der Tabulatortaste durch die ganze Buchung, einmal mit Vorlesesoftware hören, einmal bei 200 Prozent Zoom.

Technische Einordnung, keine Rechtsberatung. Ob und wie das BFSG auf Ihr Angebot anwendbar ist, beurteilen Anwältinnen und Anwälte.

Wann eine Terminvergabe unter das BFSG fällt

Das BFSG zählt in § 1 Absatz 3 auf, für welche Dienstleistungen es gilt – für solche, „die für Verbraucher nach dem 28. Juni 2025 erbracht werden“. Nummer 5 dieser Liste lautet schlicht: „Dienstleistungen im elektronischen Geschäftsverkehr“. Was damit gemeint ist, sagt § 2 Nummer 26 BFSG: „digitale Dienste nach § 1 Absatz 4 Nummer 1 des Digitale-Dienste-Gesetzes, die über Webseiten und über Anwendungen auf Mobilgeräten angeboten werden und elektronisch und auf individuelle Anfrage eines Verbrauchers im Hinblick auf den Abschluss eines Verbrauchervertrags erbracht werden“.

Drei Merkmale stecken in dieser Definition, und alle drei lassen sich an einer Terminbuchung nachvollziehen: Sie läuft über eine Website oder eine App, sie wird elektronisch auf individuelle Anfrage erbracht, und sie zielt auf einen Vertrag mit einem Verbraucher. Entscheidend ist deshalb, ob am Ende eine verbindliche Zusage steht – und ob sich das Angebot an Verbraucher richtet.

• Verbindliche Buchung eines Termins mit Bestätigung: Alle drei Merkmale liegen nahe.
• Kontaktformular mit Terminwunsch, auf das jemand händisch antwortet: Die Abgrenzung ist weniger eindeutig und im Zweifel eine Rechtsfrage. Barrierefrei sein sollte das Formular ohnehin – es ist der Weg zu Ihnen.
• Reine Telefonnummer ohne digitale Buchung: kein digitaler Dienst im Sinne der Definition.

Die Branchen unterscheiden sich weniger, als es zunächst scheint. Die Zahnarztpraxis, die Termine über ein Praxisportal vergibt, der Handwerksbetrieb mit Online-Terminvergabe für die Heizungswartung, der Friseursalon mit Zeitfenstern je Mitarbeiterin, die Kfz-Werkstatt mit Buchung für Reifenwechsel und Hauptuntersuchung, die Kanzlei mit online buchbarer Erstberatung – technisch ist es immer dieselbe Strecke: Leistung wählen, Tag wählen, Zeitfenster wählen, Daten eingeben, bestätigen. Ein Unterschied liegt beim Gegenüber: Eine Kanzlei, die ausschließlich Unternehmen berät, hat keine Verbraucher als Kundschaft. Der Handwerker, der Privathaushalte bedient, sehr wohl.

Bei Arztpraxen kommt eine Besonderheit hinzu: Die Heilbehandlung selbst steht nicht in der Liste des § 1 Absatz 3 BFSG. Die Terminbuchung im Internet ist davon zu trennen – sie ist ein digitaler Weg, über den Patientinnen und Patienten etwas verbindlich vereinbaren. Wo genau die Grenze verläuft, ist eine Rechtsfrage; die technische Bestandsaufnahme lässt sich unabhängig davon machen.

Die Kleinstunternehmer-Ausnahme

§ 3 Absatz 3 Satz 1 BFSG lautet: „Absatz 1 gilt nicht für Kleinstunternehmen, die Dienstleistungen anbieten oder erbringen.“ Was ein Kleinstunternehmen ist, definiert § 2 Nummer 17 BFSG: „ein Unternehmen, das weniger als zehn Personen beschäftigt und das entweder einen Jahresumsatz von höchstens 2 Millionen Euro erzielt oder dessen Jahresbilanzsumme sich auf höchstens 2 Millionen Euro beläuft“.

Beide Bedingungen müssen zusammen erfüllt sein. Eine Gemeinschaftspraxis mit drei Ärztinnen und zwölf Angestellten liegt bei den Beschäftigten über der Schwelle, auch wenn der Umsatz darunter bleibt. Ein Friseursalon mit sechs Beschäftigten liegt bei den Beschäftigten darunter – dann entscheidet die zweite Bedingung, also Jahresumsatz oder Jahresbilanzsumme. Wie Teilzeitkräfte und Auszubildende zu zählen sind, ist eine Rechtsfrage – die Einzelheiten stehen im Ratgeber zur Kleinstunternehmer-Ausnahme nach § 3 Absatz 3 BFSG. Wer sich auf die Ausnahme beruft, sollte die Zahlen für das jeweilige Geschäftsjahr belegen können.

Was das Gesetz vom Dienstleistungserbringer verlangt

§ 14 Absatz 1 BFSG sieht vor, dass der Dienstleistungserbringer seine Dienstleistung „nur anbieten oder erbringen“ darf, wenn sie die Barrierefreiheitsanforderungen der Verordnung erfüllt und er die Informationen nach Anlage 3 Nummer 1 – in der Praxis „Erklärung zur Barrierefreiheit“ genannt – erstellt und „für die Allgemeinheit in barrierefreier Form zugänglich gemacht hat“. Absatz 3 verlangt, dass die Anforderungen „stets erfüllt werden“, und dass Veränderungen bei der Art und Weise der Erbringung „gebührend Rechnung“ getragen wird. Für ein Buchungstool heißt das übersetzt: Ein Update des Anbieters, das den Kalender umbaut, ist ein Anlass, erneut hinzusehen.

§ 37 Absatz 2 BFSG nennt für eine Dienstleistung, die entgegen § 14 Absatz 1 angeboten wird, eine Geldbuße „bis zu hunderttausend Euro“. Dieser Rahmen gilt nach § 37 Absatz 2 BFSG nur für bestimmte Tatbestände; in den übrigen Fällen liegt er bei zehntausend Euro. Wie Marktüberwachung und Bußgeldverfahren tatsächlich ablaufen und was zuerst passiert, steht im Ratgeber zum Bußgeld nach § 37 BFSG. Ein Grund zur Panik ist die Zahl nicht; ein Grund, den Kalender einmal selbst mit der Tastatur zu bedienen, schon.

Wo Terminkalender typischerweise scheitern

Ein Datumsauswahl-Widget ist eine der schwierigsten Komponenten im Web. Diese fünf Fehlerbilder begegnen uns am häufigsten – vier davon findet ein automatisierter Test, das zweite fällt nur einem Menschen auf:

• Nicht mit der Tastatur bedienbar. Der Kalender öffnet sich nur bei Mausklick, oder man kommt zwar hinein, aber nicht wieder heraus (WCAG 2.1.1 Tastatur und 2.1.2 Keine Tastaturfalle).
• Freie Termine nur durch Farbe erkennbar. Grün gleich frei, grau gleich belegt – ohne Text daneben ist das für viele nicht unterscheidbar (WCAG 1.4.1 Benutzung von Farbe).
• Kein sichtbarer Fokus. Man tabbt durch dreißig Tage und sieht nicht, wo man steht (WCAG 2.4.7 Fokus sichtbar).
• Der Zustand wird nicht angesagt. Ein ausgewählter Tag ist visuell hervorgehoben, aber ohne einen ausgezeichneten Zustand (aria-selected an der Rasterzelle, aria-pressed an der Schaltfläche) oder aria-current erfährt eine Vorlesesoftware nichts davon (WCAG 4.1.2 Name, Rolle, Wert).
• Zeitfenster ohne Beschriftung. Schaltflächen, die nur „09:00“ heißen, ohne Bezug zum Datum – im Zusammenhang vorgelesen ergibt das eine Zahlenreihe (WCAG 4.1.2 Name, Rolle, Wert und 1.3.1 Info und Beziehungen).

Die Zahlen dazu stammen aus unserer Erhebung 2026 über 85 Websites mittelständischer Betriebe – nicht nur Terminbuchungen, aber Betriebe mit Online-Berührungspunkt für Verbraucher: Schaltflächen ohne erkennbaren Namen auf 19 von 85 Websites, Auswahllisten ohne Beschriftung auf 12 von 85, Formularfelder ohne Beschriftung auf 10 von 85, eingebettete Frames ohne Titel auf 10 von 85. Jeder dieser Befunde sitzt in einer Buchungsstrecke an einer Stelle, an der es keinen Umweg gibt.

Das Kalender-Widget: der schwierigste Baustein

Ein Monatskalender besteht aus 28 bis 42 Feldern, und jedes davon ist ein Bedienelement mit mehreren Zuständen: frei, belegt, ausgewählt, heute, vergangen. Dazu kommen die Navigation zum nächsten Monat und die Tatsache, dass der Kalender meist als aufklappende Ebene über der Seite liegt. Jede dieser Eigenschaften ist eine eigene WCAG-Frage. Der Reihe nach, mit dem Wortlaut der Kriterien aus der deutschen Übersetzung der WCAG 2.1 (nicht autorisierte Übersetzung; verbindlich ist die englische Fassung).

Öffnen, bedienen, schließen: 2.1.1 und 2.1.2

Erfolgskriterium 2.1.1 Tastatur (Stufe A) verlangt: „Alle Funktionalitäten des Inhalts sind durch eine Tastaturschnittstelle bedienbar, ohne dass eine bestimmte Zeiteinteilung für einzelne Tastenanschläge erforderlich ist …“ Der Wortlaut geht danach weiter: Ausgenommen sind nur Funktionen, die den Pfad einer Bewegung auswerten – Handschrift etwa. Ein Kalender gehört nicht dazu. Für ihn heißt das: Die Schaltfläche, die ihn öffnet, reagiert auf die Eingabetaste; innerhalb des Rasters bewegen die Pfeiltasten den Fokus um einen Tag oder eine Woche; Bild-auf und Bild-ab wechseln den Monat; die Eingabetaste wählt aus.

Erfolgskriterium 2.1.2 Keine Tastaturfalle (Stufe A) ist die Gegenrichtung: Wenn der Fokus in den Kalender bewegt werden kann, „dann kann der Fokus von diesem Bestandteil weg bewegt werden, indem man nur die Tastaturschnittstelle benutzt“. Escape schließt den Kalender, und der Fokus kehrt zu der Schaltfläche zurück, die ihn geöffnet hat. Ein Kalender, aus dem man nur mit der Maus herausfindet, ist eine Tastaturfalle – und der Hinweis zum Kriterium sagt, warum sie so schwer wiegt: Solcher Inhalt „kann die Möglichkeit eines Benutzers beeinträchtigen, die ganze Seite zu nutzen“.

Das Raster als Struktur: 1.3.1

Erfolgskriterium 1.3.1 Info und Beziehungen (Stufe A): „Informationen, Struktur und Beziehungen, die über die Darstellung vermittelt werden, können durch Software bestimmt werden oder stehen in Textform zur Verfügung.“ Visuell steht die 9 unter „Di“ in der Zeile der zweiten Septemberwoche. Programmatisch muss dieselbe Beziehung vorhanden sein: die Wochentage als Spaltenköpfe, der Monatsname als Überschrift oder Beschriftung des Rasters. Ein Kalender aus 42 gleichförmigen <div>-Elementen ohne diese Struktur ist für eine Vorlesesoftware eine Zahlenreihe von 1 bis 30.

Was ein Tag sagen muss: 4.1.2

Erfolgskriterium 4.1.2 Name, Rolle, Wert (Stufe A) verlangt, dass für alle Bestandteile der Benutzerschnittstelle „Name und Rolle durch Software bestimmt werden“ können und dass „Zustände, Eigenschaften und Werte, die vom Benutzer festgelegt werden können, … durch Software festgelegt“ sein können. Für ein Kalenderfeld heißt das dreierlei: Der Name ist das vollständige Datum („Dienstag, 9. September 2026“), nicht die Ziffer 9. Die Rolle ist Schaltfläche oder Rasterzelle – nicht ein <div> mit Klick-Handler. Der Zustand hängt an dieser Entscheidung: In einem role="grid"-Raster trägt die Rasterzelle aria-selected; eine Schaltfläche darf das Attribut nicht tragen – dort sagt aria-pressed, dass der Tag gewählt ist (nachgemessen: aria-selected an einer Schaltfläche ergibt den Befund aria-allowed-attr). Unabhängig davon gilt für beide: aria-disabled, wenn der Tag nicht verfügbar ist, und aria-current="date" für heute.

Damit ist auch die Farbfrage beantwortet: Erfolgskriterium 1.4.1 Benutzung von Farbe (Stufe A) verlangt, dass Farbe „nicht als einziges visuelles Mittel benutzt“ wird, um ein visuelles Element zu unterscheiden. Ein belegter Tag braucht neben dem Grau ein zweites Merkmal – durchgestrichen, mit Text „belegt“ oder gar nicht anwählbar und so angesagt.

Sehen, wo man steht: 2.4.7

Erfolgskriterium 2.4.7 Fokus sichtbar (Stufe AA): „Jede durch Tastatur bedienbare Benutzerschnittstelle hat einen Bedienmodus, bei dem der Tastaturfokus sichtbar ist.“ In Kalender-Widgets wird der Fokusrahmen besonders oft entfernt, weil er das Raster unruhig macht. Die Folge: Man drückt zwölfmal die Pfeiltaste und weiß nicht, ob man auf dem 9. oder dem 21. steht. Wie ein Fokusrahmen aussehen kann, der zum Design passt und trotzdem messbar sichtbar ist, steht im Ratgeber zu Tastaturbedienung und sichtbarem Fokus.

Wenn das Datum nicht passt: 3.3.1 bis 3.3.3

Drei Kriterien regeln, was passiert, wenn jemand einen Tag wählt, der nicht geht – ein Sonntag, ein Tag in der Vergangenheit, ein Datum außerhalb des Buchungsfensters:

• Erfolgskriterium 3.3.2 Beschriftungen (Labels) oder Anweisungen (Stufe A): „Wenn der Inhalt eine Eingabe durch den Benutzer verlangt werden Beschriftungen (Labels) oder Anweisungen bereitgestellt.“ Vor der Auswahl steht also, was gewählt werden kann: „Termine sind Montag bis Freitag bis zu acht Wochen im Voraus buchbar.“
• Erfolgskriterium 3.3.1 Fehlererkennung (Stufe A): „Wenn ein Eingabefehler automatisch erkannt wird, dann wird das fehlerhafte Element identifiziert und der Fehler wird dem Benutzer in Textform beschrieben.“ Also nicht ein rot blinkendes Feld, sondern ein Satz: „Der 7. September liegt in der Vergangenheit.“
• Erfolgskriterium 3.3.3 Fehlerempfehlung (Stufe AA): „Wenn ein Eingabefehler automatisch erkannt wird und Korrekturempfehlungen bekannt sind, dann werden diese Empfehlungen dem Benutzer bereitgestellt …“ – ausgenommen ist im Wortlaut danach nur, was die Sicherheit oder den Zweck des Inhalts gefährden würde; ein freier Termin ist kein solcher Fall. Das Buchungssystem kennt die Korrektur immer – es weiß, wann der nächste freie Termin ist. Der Satz lautet also: „Der nächste freie Termin ist Donnerstag, 11. September.“

Die Alternative: Datum eintippen

Das robusteste Mittel gegen alle Kalenderprobleme ist ein zweiter Weg, der keinen Kalender braucht: ein beschriftetes Eingabefeld, in das man das Datum tippt. Es ist mit jeder Tastatur bedienbar, jede Vorlesesoftware kennt es, und es fällt nicht auseinander, wenn das Widget ein Update bekommt. Das Kalender-Widget bleibt daneben als Komfort für die Maus.

<label for="datum">Wunschtermin (TT.MM.JJJJ)</label>
<input type="text" id="datum" name="datum" inputmode="numeric"
       aria-describedby="datum-hinweis">
<p id="datum-hinweis">Montag bis Freitag, bis zu acht Wochen im Voraus.</p>
<button type="button" aria-expanded="false" aria-controls="kalender">
  Kalender öffnen
</button>
<div id="kalender" hidden><!-- das Raster --></div>

Das Format steht in der Beschriftung, der Hinweis ist über aria-describedby mit dem Feld verknüpft, und die Schaltfläche sagt über aria-expanded, ob der Kalender gerade offen ist; das Ziel mit der id kalender muss dabei auf der Seite vorhanden sein, auch solange es verborgen ist – ein aria-controls, das ins Leere zeigt, ist selbst ein Befund. Ein <input type="date"> ist ebenfalls möglich – der Browser bringt dann seine eigene, tastaturbedienbare Auswahl mit. Beide Wege erfüllen die Kriterien nur, wenn die Fehlermeldung dazu in Textform kommt.

Was ein automatisierter Test hier findet: fehlende Namen, fehlende Rollen, Kontraste, fehlerhaft aufgebaute ARIA-Muster. Was er nicht findet: ob die Pfeiltasten wirklich bewegen, ob Escape schließt, ob der Fokus zurückkehrt. Automatisierte Prüfung deckt die maschinell prüfbaren Kriterien ab; eine vollständige Konformitätsbewertung erfordert zusätzlich manuelle Prüfung – beim Kalender mehr als bei jedem anderen Baustein.

Die Zeitfenster-Auswahl

Nach dem Tag kommt die Uhrzeit: eine Reihe von Schaltflächen, „09:00“, „09:30“, „10:00“. Visuell ist das eindeutig, weil die Überschrift darüber das Datum nennt. Für eine Vorlesesoftware, die von Element zu Element springt, ist die Überschrift längst vorbei – übrig bleibt „09:00, Schaltfläche“. Vier Dinge machen aus der Zahlenreihe eine Auswahl:

• Das Datum steht im Namen oder in der Gruppe. Sichtbar bleibt „09:00“. Das Datum kommt entweder in den zugänglichen Namen – „09:00 Uhr am Dienstag, 9. September 2026“, über aria-label oder einen visuell verborgenen Textzusatz (WCAG 4.1.2) – oder über die Gruppierung aus dem nächsten Punkt. Eines von beidem muss es sein; das Muster unten geht den zweiten Weg.
• Die Zeiten sind eine Gruppe. Ein <fieldset> mit <legend> „Freie Zeiten am Dienstag, 9. September“ gibt jedem Eintrag seinen Zusammenhang zurück (WCAG 1.3.1). Werden die Zeiten als Optionsfelder umgesetzt, bringt der Browser die Pfeiltasten-Bedienung von selbst mit.
• Belegt ist nicht nur grau. Ein ausgebuchtes Zeitfenster braucht ein zweites Merkmal oder verschwindet ganz aus der Liste (WCAG 1.4.1). Und es macht einen Unterschied, wie es deaktiviert wird: disabled nimmt das Element aus der Tabulatorreihenfolge – wer nur tabbt, erfährt nicht, dass es je da war. aria-disabled="true" lässt es erreichbar und lässt es als „nicht verfügbar“ ansagen; das ist der freundlichere Weg und derselbe, den wir oben für belegte Kalendertage empfehlen. Ehrlicher als beides ist ein Satz darüber: „Drei von zwölf Zeiten sind noch frei.“
• Der Wechsel wird angesagt. Wählt jemand einen anderen Tag, tauschen die Zeiten unter dem Kalender aus – für eine Vorlesesoftware lautlos. Erfolgskriterium 4.1.3 Statusmeldungen (Stufe AA) verlangt, dass solche Meldungen „durch Software bestimmt werden“ können, „ohne Fokus zu erhalten“. Eine Live-Region, die „Sechs freie Zeiten am Dienstag, 9. September“ meldet, erfüllt das.

<fieldset>
  <legend>Freie Zeiten am Dienstag, 9. September 2026</legend>
  <input type="radio" id="z0900" name="zeit" value="09:00">
  <label for="z0900">09:00 Uhr</label>
  <input type="radio" id="z0930" name="zeit" value="09:30">
  <label for="z0930">09:30 Uhr</label>
</fieldset>
<p aria-live="polite">6 freie Zeiten am Dienstag, 9. September 2026</p>

Zwei Randfälle, die in der Praxis oft übersehen werden: Eine lange Zeitliste in einem eigenen Scrollbereich muss mit der Tastatur erreichbar sein – Scrollbereiche ohne Tastaturzugang fanden wir auf 4 von 85 Websites. Und wenn zu jeder Zeit eine Dauer oder ein Preis gehört („45 Minuten, 38 €“), gehört diese Angabe in den Text des Eintrags, nicht in einen Tooltip, der nur beim Überfahren mit der Maus erscheint.

Formularfelder, Bestätigung und Absage per Mail

Nach dem Zeitfenster kommt das Formular, und hier greift dieselbe Technik wie bei jedem anderen Formular – mit dem Unterschied, dass es kurz ist und deshalb schnell nachlässig gebaut wird.

Die Datenfelder

In unserer Erhebung 2026 hatten 10 von 85 Websites Formularfelder ohne Beschriftung und 12 von 85 Auswahllisten ohne Beschriftung. Auswahllisten sind in Buchungsformularen besonders häufig: das Anliegen, der Versichertenstatus, der Fahrzeugtyp, die gewünschte Mitarbeiterin. Ohne <label> hört jemand mit Vorlesesoftware „Auswahlliste“ – wofür, bleibt offen.

• Jedes Feld bekommt ein sichtbares <label>, dessen for auf die id des Feldes zeigt. Ein Platzhaltertext ist keine Beschriftung (WCAG 3.3.2).
• Name, Telefonnummer und E-Mail-Adresse tragen autocomplete="name", "tel" und "email" – Erfolgskriterium 1.3.5 Bestimmung des Eingabezwecks (Stufe AA). Der Browser füllt dann aus, was er kennt, und jede Person mit motorischer Einschränkung spart die Tipparbeit.
• Pflichtfelder werden mit required ausgezeichnet und das Sternchen wird einmal erklärt.
• Die Einwilligungs-Checkbox zum Datenschutz hat ein Label, das den ganzen Satz enthält – nicht nur das Wort „Datenschutz“ neben einem Kästchen ohne Verknüpfung.
• Fehler werden in Textform benannt, dem Feld über aria-describedby zugeordnet, und der Fokus springt nach dem Absenden dorthin (WCAG 3.3.1, 3.3.3, 2.4.3 Fokus-Reihenfolge).

Die ausführliche Fassung mit Codebeispielen steht im Ratgeber zu barrierefreien Formularen. Ein Punkt verdient in Buchungsformularen besondere Aufmerksamkeit: das Captcha vor dem Absenden. Ein Bildrätsel ohne Alternative sperrt blinde Menschen vom Termin aus, und ein Rechenrätsel sperrt andere. Welche Verfahren ohne diese Hürde auskommen, steht im Ratgeber zu barrierefreien Captchas.

Die Bestätigung

Nach dem Absenden erscheint eine Bestätigung – oft ein grünes Häkchen mit „Vielen Dank“. Für jemanden, der nicht sieht, ist ein Häkchen nichts. Die Bestätigung braucht eine Überschrift („Ihr Termin ist gebucht“), den Termin in Textform – Datum, Uhrzeit, Leistung, Ort, Ansprechperson – und den Fokus auf dieser Überschrift, damit die Vorlesesoftware sie als Erstes liest. Wird die Bestätigung ohne Seitenwechsel eingeblendet, muss sie als Statusmeldung angesagt werden (WCAG 4.1.3).

Erfolgskriterium 3.3.4 Fehlervermeidung (rechtliche, finanzielle, Daten) (Stufe AA) gilt für Seiten, „die eine für den Benutzer auftretende rechtliche Verpflichtung oder finanzielle Transaktion zur Folge haben“. Ob eine Terminbuchung das ist, hängt von Ihrem Angebot ab – bei einer verbindlichen Buchung mit Ausfallregelung liegt es nahe. Das Kriterium lässt drei Wege zu und verlangt mindestens einen: Die Buchung ist rücknehmbar (der Absage-Link aus der Bestätigungsmail, siehe unten), die Eingaben werden auf Fehler geprüft und lassen sich korrigieren, oder es gibt vor dem endgültigen Absenden eine Seite „Bitte prüfen Sie Ihre Angaben“, auf der sich jedes Feld noch ändern lässt. Wer den Absageweg ohnehin sauber baut, hat den ersten Weg schon.

Die Mail und die Absage

Die Bestätigungsmail gehört zur Buchung dazu, und für sie gelten dieselben Regeln: Der Termin steht als Text darin, nicht nur in einem Bild oder ausschließlich in einer angehängten Kalenderdatei. Der Link zum Absagen oder Verschieben hat einen sprechenden Text – „Termin am 9. September absagen“ statt „hier klicken“ (Erfolgskriterium 2.4.4 Linkzweck (im Kontext), Stufe A). Und die Absageseite, auf der er landet, stellt keine neuen Hürden auf: kein Login, kein Captcha, eine Bestätigung in Textform, dass der Termin gestrichen ist.

Der Grund, warum die Absage so viel Aufmerksamkeit verdient: Wer online gebucht hat, weil er nicht telefonieren kann, kann auch nicht anrufen, um abzusagen. Ein Absageweg, der nur über das Telefon führt, macht aus einem barrierefreien Buchungsweg einen halben.

Wenn das Buchungstool von einem Anbieter kommt: vier Fragen

Die meisten Betriebe kaufen die Terminbuchung ein. Damit gilt dasselbe wie bei Hotel-Buchungsstrecken: Sie können den Code nicht ändern, ein Prüfwerkzeug misst ihn trotzdem, und die Dienstleistung bleibt Ihre. Was daraus rechtlich folgt, ist eine Frage für eine anwaltliche Beratung. Was daraus praktisch folgt, ist eindeutig: Sie brauchen von Ihrem Anbieter eine belastbare Aussage – schriftlich.

Diese vier Fragen bringen Klarheit. Zu jeder steht, was eine gute Antwort ist – und woran Sie eine schwache erkennen.

1. Lässt sich die gesamte Buchung mit der Tastatur abschließen – einschließlich des Kalenders?

   Gute Antwort: „Ja“, mit der Tastenbelegung dazu (Pfeiltasten im Raster, Escape schließt, Tabulator verlässt den Kalender) und einer Testadresse, an der Sie es selbst nachvollziehen können. Schwache Antwort: „Unsere Software ist barrierefrei“ ohne Beleg – oder der Verweis auf ein Overlay-Widget, das man dazuschalten könne. Warum das keine Antwort ist, steht im Ratgeber zu Overlays und dem BFSG.

2. Was hört jemand mit Vorlesesoftware bei einem Tag im Kalender und bei einem Zeitfenster?

   Gute Antwort: nennt den Wortlaut – „Dienstag, 9. September 2026, 4 freie Zeiten“ – und sagt, mit welcher Vorlesesoftware und welchem Browser getestet wurde. Schwache Antwort: „Wir setzen ARIA ein.“ ARIA ist ein Werkzeug, kein Ergebnis; ein halb gesetztes Attribut kann mehr schaden als gar keines.

3. Gibt es zur Kalenderauswahl eine Alternative – ein Eingabefeld für das Datum oder eine Liste der nächsten freien Termine?

   Gute Antwort: „Ja“, mit der Angabe, wo die Alternative steht und dass sie standardmäßig eingeschaltet ist. Schwache Antwort: „Auf Anfrage konfigurierbar“ – dann ist sie bei Ihnen vermutlich aus, und Sie sollten das jetzt ändern lassen.

4. Wie werden Fehler gemeldet – bei einem falschen Datum, einem leeren Pflichtfeld, einem inzwischen vergebenen Zeitfenster?

   Gute Antwort: in Textform, dem Feld zugeordnet, mit einer Empfehlung („Der nächste freie Termin ist …“), und der Fokus springt zur Meldung; am besten mit einem Beispieltext. Schwache Antwort: „Das Feld wird rot markiert.“ Das ist eine Farbe, keine Meldung.

Fordern Sie zusätzlich schriftlich an: einen aktuellen Prüfbericht zur EN 301 549 beziehungsweise zu den WCAG 2.1 Stufe AA mit Datum und Werkzeug; die Aussage, ob auch manuell geprüft wurde – ein reiner Werkzeuglauf deckt nur die maschinell prüfbaren Kriterien ab; eine Liste bekannter Abweichungen mit Zeitplan zur Behebung; und eine Zusage, wie Sie über Updates informiert werden, die den Kalender oder das Formular verändern. Der letzte Punkt ist kein Formalismus: § 14 Absatz 3 BFSG verlangt vom Dienstleistungserbringer, Veränderungen bei der Erbringung „gebührend Rechnung“ zu tragen – und ein Update des Buchungstools ist genau eine solche Veränderung.

Wenn der Anbieter nichts liefern kann, ist das eine Information: Dann kennen Sie das Risiko, und Sie können es in Ihrer Barrierefreiheitserklärung benennen – statt es zu übersehen.

Der Selbsttest in zehn Minuten

Sie brauchen dafür kein Werkzeug und keine Vorkenntnisse – nur die eigene Buchungsseite, eine Tastatur und die Bereitschaft, einen Testtermin sofort wieder abzusagen. Hat Ihr Buchungstool einen Testmodus oder einen internen Kalender, nehmen Sie den.

1. Minute 1 bis 3: mit der Tabulatortaste durch die ganze Buchung

   Legen Sie die Maus außer Reichweite. Tabulator springt vorwärts, Umschalt und Tabulator zurück, Pfeiltasten bewegen im Kalender, Eingabetaste wählt aus, Escape schließt. Vier Fragen dabei: Kommen Sie in den Kalender hinein und wieder heraus? Sehen Sie in jedem Moment, wo Sie stehen? Ist die Reihenfolge sinnvoll – erst Leistung, dann Tag, dann Zeit, dann Daten (WCAG 2.4.3 Fokus-Reihenfolge)? Kommen Sie bis zur Bestätigung? Sobald Sie zur Maus greifen müssen, haben Sie den Befund.

2. Minute 4 bis 7: Bildschirm aus, Vorlesesoftware hören

   Jedes Betriebssystem bringt eine mit: unter Windows die Sprachausgabe (Windows-Taste, Strg und Eingabetaste zugleich), auf dem Mac VoiceOver (Befehlstaste und F5). Schalten Sie sie ein, drehen Sie den Bildschirm weg oder dunkeln Sie ihn ab, und gehen Sie die Buchung noch einmal mit der Tastatur durch. Hören Sie hin: Wird beim Tag das ganze Datum gesagt oder nur „9“? Hören Sie beim Zeitfenster nur „09:00, Schaltfläche“ – oder auch das Datum, sei es im Namen selbst oder beim Betreten der Gruppe? Sagt die Software beim Feld „Eingabefeld“ oder „Telefonnummer, Pflichtfeld“? Wird die Fehlermeldung vorgelesen, ohne dass Sie sie suchen müssen? Was Sie hier hören, hört jede blinde Person, die bei Ihnen buchen will.

3. Minute 8 bis 9: Zoom auf 200 Prozent

   Strg und Plus, bis der Browser 200 Prozent anzeigt. Erfolgskriterium 1.4.4 Textgröße ändern (Stufe AA) verlangt, dass Text „ohne assistierende Technik um bis zu 200 Prozent geändert werden“ kann, „ohne dass dabei Inhalt oder Funktionalität verloren geht“ – ausgenommen sind Untertitel und Bilder eines Textes. „Ohne assistierende Technik“ heißt: Der Zoom des Browsers allein muss reichen; eine Vergrößerungssoftware zählt nicht. Ist der Kalender vollständig zu sehen? Überlappen die Zeitfenster? Muss man seitlich scrollen? Und auf dem Telefon: Lässt sich die Seite mit zwei Fingern vergrößern? Auf 13 von 85 Websites unserer Erhebung war das Zoomen blockiert – eine einzige Zeile im Seitenkopf, vor Jahren eingebaut, um das Layout zu schützen.

4. Minute 10: absichtlich falsch

   Senden Sie das Formular leer ab. Tippen Sie ein Datum in der Vergangenheit ein. Wählen Sie einen Sonntag. Steht der Fehler als Satz da? Sagt er, was zu tun ist? Springt der Fokus zur Meldung, oder steht er noch auf der Absenden-Schaltfläche?

Diese vier Handgriffe finden die Barrieren, die eine Buchung abbrechen lassen. Was sie nicht finden, findet ein automatisierter Test: Kontraste (unzureichend auf 72 von 85 Websites unserer Erhebung), fehlerhafte ARIA-Auszeichnungen, Icon-Links ohne Namen, doppelte id-Werte, auf die ARIA verweist. Und was beide nicht finden – ob eine Fehlermeldung verständlich formuliert ist, ob die Leistungsbezeichnungen jemand versteht, der die Branche nicht kennt –, findet nur ein Mensch. Automatisierte Prüfung deckt die maschinell prüfbaren Kriterien ab; eine vollständige Konformitätsbewertung erfordert zusätzlich manuelle Prüfung.

Baustein, Kriterium, Selbsttest: auf einen Blick

Die Tabelle fasst die Strecke zusammen – vom Knopf „Termin buchen“ bis zur Absagemail. Jede Zeile nennt den Baustein, die zuständigen Erfolgskriterien der WCAG 2.1 und den Handgriff, mit dem Sie den Punkt selbst prüfen. Alle genannten Kriterien liegen auf Stufe A oder AA, also auf der Stufe, auf die die EN 301 549 verweist; was die einzelnen Kriterien verlangen, steht im Ratgeber zu den Kriterien der WCAG 2.1 AA.

Die Kriteriennummern sind bewusst so knapp gehalten, dass Sie die Tabelle an Ihren Anbieter oder Ihre Agentur weitergeben können. Wer eine Zeile nicht zuordnen kann, hat damit die erste Frage für das Gespräch.

Wenn das Werkzeug nicht barrierefrei ist: drei Wege

Der Selbsttest ist gelaufen, die Antwort des Anbieters liegt vor – und es reicht nicht. Dann gibt es drei Wege, und sie schließen einander nicht aus.

Weg 1: den Anbieter wechseln

Der Weg für alle, deren Buchungstool von einem Anbieter kommt, der die vier Fragen nicht beantwortet, auf ein Overlay verweist oder die Alternative zum Kalender „auf Anfrage“ verspricht und nie liefert. Der Wechsel ist einfacher, als er klingt: Auf Ihrer eigenen Website ändert sich ein Link oder ein eingebetteter Rahmen. Die Arbeit liegt im Umzug – bestehende Termine exportieren, Leistungen und Zeiten neu anlegen, die Bestätigungsmails prüfen.

Wichtig ist die Reihenfolge: Stellen Sie die vier Fragen dem neuen Anbieter, bevor Sie unterschreiben, und lassen Sie sich einen Testzugang geben. Machen Sie dort den Selbsttest. Ein Wechsel, nach dem dieselben Barrieren stehen, kostet doppelt.

Weg 2: das Telefon als gleichwertiger Weg – was das heißt und was nicht

Zuerst die ehrliche Einordnung: Das BFSG kennt keinen Ersatzkanal. § 14 Absatz 1 verlangt, dass die Dienstleistung selbst die Anforderungen erfüllt. Zwei Entlastungstatbestände kennt das Gesetz allerdings: § 16 BFSG (grundlegende Veränderung der Wesensmerkmale) und § 17 BFSG (unverhältnismäßige Belastung nach Anlage 4). Beide sind an eine eigene Beurteilung und deren Dokumentation gebunden und keine Selbstverständlichkeit; ob einer davon auf Ihren Fall passt, ist eine Frage für eine anwaltliche Beratung. Ob eine Telefonnummer daneben im Einzelfall rechtlich etwas ändert, beurteilen Anwältinnen und Anwälte – wir können nur sagen, wann ein Telefonweg praktisch gleichwertig ist. Das ist er nur, wenn mindestens dies gilt:

• Gleiche Termine. Am Telefon sind dieselben Zeitfenster buchbar wie online – nicht nur die, die übrig bleiben.
• Gleiche Zeiten. Die Online-Buchung ist auch abends und am Wochenende erreichbar. Ein Telefon, das werktags von neun bis zwölf besetzt ist, ist es nicht.
• Gleiche Bedingungen. Keine Gebühr, keine schlechtere Stornofrist, dieselbe Bestätigung in Textform – etwa per Mail oder SMS.
• Gleicher Aufwand. Zwanzig Minuten Warteschleife sind keine Gleichwertigkeit.

Und selbst dann ist das Telefon nicht für alle ein Weg. Gehörlose und schwerhörige Menschen, Menschen mit einer Sprechbehinderung, Menschen, für die ein Anruf aus anderen Gründen nicht in Frage kommt – für sie ist das Telefon die Barriere, nicht die Lösung. Ein Textkanal daneben (E-Mail oder ein barrierefreies Kontaktformular mit einer Zusage, binnen eines Werktags zu antworten) fängt einen Teil davon auf. Das Telefon ist eine Ergänzung, und als solche gehört es ehrlich benannt in Ihre Erklärung zur Barrierefreiheit – eine Vorlage dafür steht im Muster für die Barrierefreiheitserklärung.

Weg 3: umbauen

Der Weg für alle, deren Buchung im eigenen Code liegt, aus einem Plugin mit anpassbaren Vorlagen stammt oder von einem Anbieter kommt, der mitzieht. Drei Hebel, in dieser Reihenfolge:

1. Die Alternative zuerst

   Ein Eingabefeld für das Datum und Optionsfelder für die Zeiten – kleiner Aufwand, große Wirkung. Damit ist der Weg zum Termin für Tastatur und Vorlesesoftware offen, noch bevor jemand den Kalender anfasst.

2. Native Elemente statt nachgebauter

   Ein <button> statt eines <div> mit Klick-Handler bringt Tastaturbedienung, Rolle und Fokus von selbst mit. Ein <label> statt eines Platzhalters, ein <fieldset> statt einer Überschrift, die nur optisch dazugehört.

3. Fokus und Status führen

   Escape schließt und springt zurück; nach dem Absenden landet der Fokus auf der Meldung; der Tageswechsel wird über eine Live-Region angesagt. Das ist der Teil, der Entwicklungsarbeit braucht – und der Teil, den kein Werkzeug prüfen kann.

Der Aufwand bemisst sich nach Vorlagen, nicht nach Elementen: Ein Kalender wird einmal repariert, auch wenn er auf zwölf Seiten eingebunden ist. Wie sich das in ein Budget übersetzt, steht im Ratgeber zu den Kosten der BFSG-Umsetzung. Und nach dem Umbau gilt: nachmessen. Erst der zweite Lauf belegt, dass der erste etwas gebracht hat.

Der Weg zum Termin gehört auch dazu

Die Buchung ist der letzte Schritt. Davor liegt Ihre eigene Seite, und dort finden wir in unseren Prüfläufen eigene Befunde – unabhängig davon, wie gut das Buchungstool ist:

• der Knopf „Termin buchen“ als reines Bild ohne Alternativtext – Bilder ohne Alternativtext fanden wir auf 27 von 85 Websites
• das eingebettete Buchungstool in einem Rahmen ohne Titel – Frames ohne Titel auf 10 von 85; eine Vorlesesoftware sagt dann „Frame“ und sonst nichts, ein title="Terminbuchung" behebt das
• Icon-Links ohne Namen in Kopf- und Fußzeile – Links ohne erkennbaren Linktext auf 50 von 85
• Öffnungszeiten in einer Tabelle ohne Kopfzeilen
• Kontaktdaten in einer Grafik – für eine Vorlesesoftware unsichtbar
• Kontraste in der Farbwelt der Praxis oder Kanzlei: helles Grau, zartes Blau, dünne Schrift – unzureichender Farbkontrast auf 72 von 85
• ein Consent-Banner, das den Fokus einfängt und nicht mehr hergibt – wie es richtig geht, steht im Ratgeber zu barrierefreien Consent-Bannern

Das sind alles Punkte, die im bestehenden Auftritt korrigierbar sind – ohne neue Website. Und sie sind der Teil, den Sie ohne Ihren Anbieter in der Hand haben.

Der nächste Schritt

Bevor Sie mit Ihrem Anbieter sprechen, ist eine Messung nützlich: Sie sagt Ihnen, wie viele Befunde es gibt und auf welchen Adressen sie sitzen – auch auf denen der Buchungs-Subdomain, wenn sie mitgeprüft wird. Mit diesen Adressen wird aus einem allgemeinen Unbehagen ein konkretes Gespräch – und aus den vier Fragen oben werden Fragen mit Zahlen.

Diesen Scan macht die Technische Betreuung: Der erste Lauf liefert sofort die beiden vollständigen Berichte, auf Wunsch einschließlich der Subdomain, auf der das Buchungstool läuft, und danach misst er alle 14 Tage nach – damit ein Update des Anbieters nicht monatelang unbemerkt bleibt. Der Bericht nennt zu jedem Befund die Seiten, auf denen er sitzt; an diesen Adressen sehen Sie selbst, was auf Ihren eigenen Seiten liegt und was auf denen des Buchungsanbieters. Was der automatisierte Test abdeckt und was nur eine manuelle Prüfung leisten kann, steht transparent darin: Automatisierte Prüfung deckt die maschinell prüfbaren Kriterien ab; eine vollständige Konformitätsbewertung erfordert zusätzlich manuelle Prüfung. Den Selbsttest von oben ersetzt er nicht – er ergänzt ihn um das, was Sie mit der Tastatur nicht sehen.

Häufige Fragen

Dieser Artikel ist eine technische Einordnung und keine Rechtsberatung. Quellen: Barrierefreiheitsstärkungsgesetz (BFSG), insbesondere § 1 Absatz 3 Nummer 5, § 2 Nummer 17 und 26, § 3 Absatz 3, § 14 und § 37; Barrierefreiheitsstärkungsgesetz-Verordnung (BFSGV); WCAG 2.1 in der deutschen Übersetzung (nicht autorisierte Übersetzung vom 15. Juni 2022 nach dem Übersetzungsverzeichnis des W3C; verbindlich ist die englische Originalfassung), insbesondere die Erfolgskriterien 1.1.1, 1.3.1, 1.3.5, 1.4.1, 1.4.3, 1.4.4, 2.1.1, 2.1.2, 2.4.3, 2.4.4, 2.4.7, 3.3.1, 3.3.2, 3.3.3, 3.3.4, 4.1.2 und 4.1.3; EN 301 549. Eigene Messwerte aus 85 automatisiert geprüften Websites mittelständischer Betriebe, September 2026 (Erhebung 2026).