WCAG-2.2-AA-Erfüllungsbericht
Das Ergebnis vorab: Die öffentliche Terminbuchungsstrecke von termin.email erfüllt die Web Content Accessibility Guidelines (WCAG) 2.2 auf Stufe AA und damit auch WCAG 2.1 AA. Jedes Erfolgskriterium ist erfüllt oder trifft auf die Strecke nicht zu. Diese Seite dokumentiert die Bewertung Kriterium für Kriterium.
Diese Erklärung ist eine Selbstbewertung (Eigenerklärung) des Betreibers auf Grundlage einer kriteriengenauen Prüfung des Quellcodes. Sie ist keine unabhängige Zertifizierung durch eine akkreditierte Prüfstelle.
Geltungsbereich
Bewertet wurde ausschließlich die öffentliche Terminbuchungsstrecke der auf termin.email gehosteten Mandanten (Profil, Kalender, Buchungsformular, Bestätigung, Verwaltung, Warteliste und Umfrage). Der eingeloggte Verwaltungsbereich (/app, /admin) ist nicht Gegenstand dieser Erklärung.
Zugrunde gelegte Norm und Methode
Grundlage sind die Erfolgskriterien der WCAG 2.1 und der WCAG 2.2 auf den Konformitätsstufen A und AA. Jedes Kriterium wurde am tatsächlichen Code (Templates, CSS, JavaScript) geprüft, Farbkontraste wurden rechnerisch nach der WCAG-Formel ermittelt, Zielgrößen und Fokus für WCAG 2.2 im Browser gemessen. Die Befunde der Vollprüfung vom 6. Juli 2026 wurden zusätzlich in einer adversarialen Mehr-Agenten-Review skeptisch gegengeprüft.
Zusammenfassung
- 37 Erfüllt
- 0 Teilweise erfüllt
- 0 Nicht erfüllt
- 13 Nicht anwendbar
Bewertet wurden alle 50 Erfolgskriterien der Stufen A und AA nach WCAG 2.1.
Bewertung je Erfolgskriterium
| Nr. | Erfolgskriterium | Stufe | Bewertung | Anmerkung |
|---|---|---|---|---|
| 1.1.1 | Nicht-Text-Inhalt | A | Erfüllt | Einziges Bild der Strecke ist das Logo, das ein Mandant hochladen kann (kopf__logo im Seitenkopf der Buchungsseite und im eingebetteten Fenster); sein Alt-Text nennt den Mandanten. Weitere Grafiken gibt es nicht, weder <img> noch <svg>; die Flächen und Farbverläufe der Stilvorlage sind rein dekorativ und tragen keine Information. Dekorative Textzeichen wie Monatspfeile und Wochentagskürzel sind korrekt per aria-label, aria-hidden bzw. <abbr title> ausgezeichnet; das Honeypot-Feld ist aria-hidden. Geprüft am 06.07.2026, am 10.09.2026 am Markup der Vorlagen nachgeprüft. |
| 1.2.1 | Nur-Audio und Nur-Video (aufgezeichnet) | A | Nicht anwendbar | Kein zeitbasiertes Medium vorhanden, kein <video>/<audio>/autoplay in der Buchungsstrecke. Geprüft am 06.07.2026. |
| 1.2.2 | Untertitel (aufgezeichnet) | A | Nicht anwendbar | Keine synchronisierten Medien mit Ton, für die Untertitel erforderlich wären. Geprüft am 06.07.2026. |
| 1.2.3 | Audiodeskription oder Volltext-Alternative (aufgezeichnet) | A | Nicht anwendbar | Kein aufgezeichnetes Videomaterial, für das Audiodeskription oder eine Volltextalternative nötig wäre. Geprüft am 06.07.2026. |
| 1.2.4 | Untertitel (live) | AA | Nicht anwendbar | Keine Live-Medien; die Strecke besteht aus statisch gerenderten Seiten. Geprüft am 06.07.2026. |
| 1.2.5 | Audiodeskription (aufgezeichnet) | AA | Nicht anwendbar | Kein aufgezeichnetes Video, damit kein Inhalt für Audiodeskription. Geprüft am 06.07.2026. |
| 1.3.1 | Info und Beziehungen | A | Erfüllt | Durchgängig semantische Struktur: <main>, genau eine <h1> je Seite, logische <h2>, Label-Feld-Verknüpfung über for/id, Kalender und Umfrage-Matrix als echte <table> mit <caption>/<th scope>, Detailanzeigen als <dl>; fehlerhafte Felder tragen aria-invalid und aria-describedby. Geprüft am 06.07.2026. |
| 1.3.2 | Bedeutungstragende Reihenfolge | A | Erfüllt | Lineare Quellreihenfolge header → main → footer; das zweispaltige Kalenderlayout entsteht per CSS-Grid ohne DOM-Umsortierung und kollabiert responsiv auf eine Spalte. Kein order/float, das die Lesereihenfolge verdreht. Geprüft am 06.07.2026. |
| 1.3.3 | Sensorische Eigenschaften | A | Erfüllt | Anweisungen und Bedienelemente werden nie allein über Form, Größe, Position oder Farbe beschrieben; alle Steuerelemente tragen Text bzw. aria-label, Fehlerhinweise verlinken per Textanker auf das Feld. Geprüft am 06.07.2026. |
| 1.3.4 | Ausrichtung | AA | Erfüllt | Keine Orientierungssperre, Layout rein flow-/grid-basiert mit relativen Einheiten, kein @media (orientation) und kein transform:rotate. Geprüft am 06.07.2026. |
| 1.3.5 | Eingabezweck bestimmen | AA | Erfüllt | Die personenbezogenen Sammelfelder tragen die passenden autocomplete-Token (name, email); der Honeypot bewusst autocomplete=off. Notiz und benutzerdefinierte Fragen haben keinen normativen HTML-Autocomplete-Zweck. Geprüft am 06.07.2026. |
| 1.4.1 | Benutzung von Farbe | A | Erfüllt | Information nie allein über Farbe: Fehler kombinieren Fläche + Text + role=alert + aria-invalid, der gewählte Kalendertag ist zusätzlich per aria-current und Button-Semantik markiert, Pflichtfelder tragen ein textliches „ *". Geprüft am 06.07.2026. |
| 1.4.2 | Audio-Steuerung | A | Nicht anwendbar | Kein automatisch abspielender Ton (kein <audio>/<video>/autoplay). Geprüft am 06.07.2026. |
| 1.4.3 | Kontrast (Minimum) | AA | Erfüllt | Alle Fließ- und Bedientexte real nachgerechnet ≥ 4,5:1 (Fließtext auf Weiß 13,91:1, auf dem Body-Hintergrund 12,45:1, Primärbutton 8,60:1, Hinweistext 7,84:1, Fehlertext 7,68:1, Kalenderbutton 11,20:1); auch der leise gesetzte Sekundärtext bleibt bei 6,48:1. Geprüft am 06.07.2026, die Werte am 09.09.2026 gegen die Stilvorlage nachgerechnet, nachdem die Palette gewechselt hatte. |
| 1.4.4 | Textgröße ändern | AA | Erfüllt | Schriftgrößen durchgängig in rem, Buttons/Inputs erben die Schrift; das Viewport-Meta erlaubt Zoom ohne maximum-scale/user-scalable=no, Text skaliert bei 200 % ohne Verlust. Geprüft am 06.07.2026. |
| 1.4.5 | Bilder eines Textes | AA | Nicht anwendbar | Keine Textgrafiken, aller sichtbare Text ist echter HTML-Text mit Systemschriften. Geprüft am 06.07.2026. |
| 1.4.10 | Reflow | AA | Erfüllt | Responsiv per Grid mit relativen Einheiten; der Kalender kollabiert bei schmaler Breite auf eine Spalte, breite Elemente sind per overflow-x:auto gekapselt, kein erzwungenes 2D-Scrollen bei 320 px. Geprüft am 06.07.2026. |
| 1.4.11 | Nicht-Text-Kontrast | AA | Erfüllt | Der Fokusindikator erreicht 8,39:1 auf dem Seitenhintergrund. Der Ruhe-Rahmen der Eingabefelder, Auswahllisten und Textfelder nutzt --farbe-rand-eingabe #6f7874 = 4,55:1 auf der weißen Feldfüllung / 4,07:1 auf dem Seitenhintergrund #f6f2e9, also über der 3:1-Schwelle. Sekundärknöpfe tragen einen dekorativen Rahmen #cfc8b8 = 1,49:1; erkennbar sind sie an ihrer Beschriftung mit 12,45:1, die Umrandung trägt also keine zur Erkennung erforderliche Information. Dekorative Karten- und Tabellenränder sind Container, keine aktiven UI-Komponenten, und fallen nicht unter 1.4.11. Geprüft am 06.07.2026, die Werte am 09.09.2026 gegen die Stilvorlage nachgerechnet. |
| 1.4.12 | Textabstand | AA | Erfüllt | line-height 1,55 über der Anforderung; keine !important-Fixierung von Zeilen-/Zeichen-/Wortabstand und keine feste Höhe auf Textcontainern, größere Abstände per Nutzer-Stylesheet führen zu keinem Inhaltsverlust. Geprüft am 06.07.2026. |
| 1.4.13 | Inhalt bei Hover oder Fokus | AA | Nicht anwendbar | Bei Hover/Fokus wird kein zusätzlicher überlagernder Inhalt eingeblendet; Hover-/Fokus-Regeln ändern nur das Element selbst, kein Tooltip/Popover (nur natives <abbr title>). Geprüft am 06.07.2026. |
| 2.1.1 | Tastatur | A | Erfüllt | Alle interaktiven Elemente sind native, tastaturbedienbare Controls (<button>, <a>, <input>, <select>, <textarea>); kein div/span-Klickhandler, das Pfeiltasten-JS ist reine Progressive Enhancement. Geprüft am 06.07.2026. |
| 2.1.2 | Keine Tastaturfalle | A | Erfüllt | Keine Tastaturfalle, preventDefault greift nur für die Pfeil-/Pos1-/Ende-Navigation im Kalender, Tab bleibt frei; keine Modals oder Fokus-Rückfänge. Geprüft am 06.07.2026. |
| 2.1.4 | Tastenkürzel für Zeichen | A | Erfüllt | Keine accesskey-Attribute; das JS reagiert nur auf Nicht-Zeichen-Navigationstasten, keine Einzelzeichen-Kürzel. Geprüft am 06.07.2026. |
| 2.2.1 | Zeiteinteilung anpassbar | A | Erfüllt | Am Code verifiziert: kein knappes UI-Timeout, kein meta-refresh, kein Timeout-Skript. Das einzige clientseitige Zeitfenster ist das Formular-Token mit 2 h (BookingFormToken MAX_AGE 7200 s), eine Sicherheits-/Replay-Frist. Läuft es ab, rendert die Submit-Action die Seite mit übernommenen Eingaben (Name/E-Mail/Notiz + Custom-Antworten via staleContext) und buchbaren Alternativen neu, kein Datenverlust. Die 30-Minuten-Reservierung des Slots (bookings:expire-pending) ist eine Echtzeit-Reservierung gegen Doppelbuchung. Beide Fristen erfüllen die WCAG-Ausnahmen „Echtzeit-Ereignis" (umkämpfter Slot wie bei einer Auktion) bzw. „wesentlich" (Token-Frische = CSRF-/Replay-Schutz); ein Verlängern würde Kernfunktion bzw. Sicherheit aushebeln. Geprüft am 06.07.2026. |
| 2.2.2 | Pausieren, Beenden, Ausblenden | A | Nicht anwendbar | Kein sich bewegender, blinkender oder automatisch aktualisierender Inhalt > 5 s; die einzige aria-live-Region aktualisiert nur nach einer Nutzeraktion. Geprüft am 06.07.2026. |
| 2.3.1 | Drei Blitze oder unterhalb des Schwellenwerts | A | Nicht anwendbar | Keine blinkenden/blitzenden Inhalte, keine Medien, keine Blink-Keyframes, keine JS-Farbwechselschleife. Geprüft am 06.07.2026. |
| 2.4.1 | Blöcke umgehen | A | Erfüllt | Sprung-Link („Zum Inhalt springen", .sprung-link → #inhalt) ist jetzt auch in der öffentlichen Buchungsstrecke vorhanden (public.twig, vor dem Header); das Embed-Layout hat <main id="inhalt"> als erstes Element ganz ohne vorangehenden Block. Zusätzlich bieten die Landmarken (main/nav) einen ARIA-Bypass. Geprüft am 06.07.2026. |
| 2.4.2 | Seite mit Titel versehen | A | Erfüllt | Jede Seite setzt einen aussagekräftigen, seitenspezifischen <title> (z. B. „Terminart | Mandant", „Umfragetitel | Mandant"). Geprüft am 06.07.2026. |
| 2.4.3 | Fokus-Reihenfolge | A | Erfüllt | DOM-Reihenfolge = sinnvolle Bedienreihenfolge (Fehlerliste → Felder → Absenden); kein positiver tabindex, nur tabindex=-1 am Honeypot und ein Roving-Tabindex im Kalender. Geprüft am 06.07.2026. |
| 2.4.4 | Linkzweck (im Kontext) | A | Erfüllt | Linkzwecke aus Text oder Kontext erkennbar: Icon-Pfeile mit aria-label, Slot-Links mit der Uhrzeit als Text, Fuß- und Fehlerlink-Texte im Klartext. Geprüft am 06.07.2026. |
| 2.4.5 | Verschiedene Methoden | AA | Nicht anwendbar | Die öffentliche Strecke besteht ausschließlich aus Schritten eines Buchungs-/Abstimmungsprozesses; für Prozessschritte greift die 2.4.5-Ausnahme. Die Profilseite listet zusätzlich alle Terminarten als Einstieg. Geprüft am 06.07.2026. |
| 2.4.6 | Überschriften und Beschriftungen | AA | Erfüllt | Je Seite eine treffende <h1> und passende <h2>-Abschnitte; Formular-Labels konkret und per <label for> verknüpft, Umfrage-Radios mit aussagekräftigem aria-label. Geprüft am 06.07.2026. |
| 2.4.7 | Fokus sichtbar | AA | Erfüllt | focus-visible setzt einen 3px-Outline in Primärfarbe (kein outline:none); der reduced-motion-Block lässt den Fokusring unberührt, Kontrast des Rings 8,39:1 auf dem Seitenhintergrund. Geprüft am 06.07.2026, der Wert am 09.09.2026 gegen die Stilvorlage nachgerechnet. |
| 2.5.1 | Zeigergesten | A | Nicht anwendbar | Keine pfadbasierten oder Mehrpunkt-Gesten, Bedienung ausschließlich per Einzelklick/Tap; kein touch/pointermove/Drag-Handler. Geprüft am 06.07.2026. |
| 2.5.2 | Zeigerabbruch | A | Erfüllt | Alle Aktionen über native Aktivierung von <a>/<button type=submit> (up-Event, Abbruch durch Wegziehen möglich); keine eigenen mousedown/pointerdown-Aktivierungen. Geprüft am 06.07.2026. |
| 2.5.3 | Beschriftung im Namen | A | Erfüllt | Sichtbarer Beschriftungstext ist im zugänglichen Namen enthalten; nur die icon-only Pfeile ohne sichtbaren Worttext nutzen zulässig aria-label. Geprüft am 06.07.2026. |
| 2.5.4 | Bewegungsaktivierung | A | Nicht anwendbar | Keine Funktion wird durch Geräte- oder Nutzerbewegung ausgelöst, keine devicemotion/deviceorientation-Listener. Geprüft am 06.07.2026. |
| 3.1.1 | Sprache der Seite | A | Erfüllt | Beide Basis-Layouts setzen <html lang> mit gültigem BCP-47-Code (de/en) und Fallback „de"; alle Buchungs-Templates erben davon. Geprüft am 06.07.2026. |
| 3.1.2 | Sprache von Teilen | AA | Erfüllt | Bis zum 05.10.2026 nur teilweise erfüllt, weil Texte des Kunden keine Sprachauszeichnung hatten. Seitdem trägt jeder Text, den der Kunde selbst schreibt, ein lang-Attribut mit der Sprache, die für ihn eingestellt ist: Name und Beschreibung der Terminart, Fragen im Buchungsformular samt Antwortmöglichkeiten, Titel, Beschreibung und Ort einer Umfrage, Impressum, Datenschutzerklärung und eigene Hinweise zur Barrierefreiheit. Ruft ein Gast die Seite auf Englisch auf, liest ein Screenreader die deutschen Texte des Kunden also deutsch vor. Kein Seitentitel mischt Plattform- und Kundentext, denn Teile eines Titels lassen sich in HTML nicht auszeichnen. Der Name des Kunden und die Namen der Gastgeber sind Eigennamen und vom Kriterium ausgenommen. Voraussetzung: Der Kunde schreibt in der eingestellten Sprache. Der einzige fremdsprachige Plattformtext („Website“ im versteckten Spamschutzfeld) liegt in aria-hidden und wird nicht vorgelesen. Geprüft am 05.10.2026 an allen Vorlagen der Strecke; ein Test hält jede Ausgabe von Kundentext fest. |
| 3.2.1 | Bei Fokus | A | Erfüllt | Kein onfocus/autofocus in der Strecke; Fokussieren löst keinen Kontextwechsel aus, der Zeitzonenwechsel erfordert einen expliziten Submit. Geprüft am 06.07.2026. |
| 3.2.2 | Bei Eingabe | A | Erfüllt | Keine onchange-Auto-Submits; jede zustandsändernde Aktion braucht einen expliziten Absende-Knopf, der Zeitzonen-Redirect läuft beim Laden, nicht bei einer Feldeingabe. Geprüft am 06.07.2026. |
| 3.2.3 | Konsistente Navigation | AA | Erfüllt | Kopf und Fußnavigation sind zentral im gemeinsamen Layout definiert und von allen Seiten geerbt, die relative Reihenfolge ist zwangsläufig identisch. Geprüft am 06.07.2026. |
| 3.2.4 | Konsistente Erkennung | AA | Erfüllt | Funktional gleiche Komponenten nutzen durchgängig dieselben Übersetzungsschlüssel (Name/E-Mail/Datenschutz identisch über Formular, Warteliste und Umfrage). Geprüft am 06.07.2026. |
| 3.3.1 | Fehlererkennung | A | Erfüllt | Validierungsfehler erscheinen als Textliste in role=alert über dem Formular, jeder Eintrag verlinkt per Anker auf das Feld, die betroffenen Felder tragen aria-invalid und aria-describedby. Geprüft am 06.07.2026. |
| 3.3.2 | Beschriftungen oder Anweisungen | A | Erfüllt | Jedes Feld hat ein verknüpftes <label for>; Pflichtfelder tragen required und ein sichtbares „*", Umfrage-Radios ein aussagekräftiges aria-label. Geprüft am 06.07.2026. |
| 3.3.3 | Fehlerempfehlung | AA | Erfüllt | Fehlertexte nennen die konkrete Handlungsempfehlung (z. B. „Bitte geben Sie eine gültige E-Mail-Adresse an.") und sind per Anker mit dem betroffenen Feld verknüpft. Geprüft am 06.07.2026. |
| 3.3.4 | Fehlervermeidung (rechtlich, finanziell, Daten) | AA | Erfüllt | Die rechtsverbindliche Buchung ist umkehrbar (Stornieren/Umbuchen) und bestätigt (expliziter Bestätigungsschritt mit Zusammenfassung); keine finanziellen Transaktionen auf der Strecke. Geprüft am 06.07.2026. |
| 4.1.1 | Parsen | A | Erfüllt | In WCAG 2.1 noch normativ: Twig-Auto-Escaping, escapeter Mandanten-Freitext, eindeutige IDs je gerenderter Seite (auch Fehler- und Honeypot-IDs kollisionsfrei). Geprüft am 06.07.2026. |
| 4.1.2 | Name, Rolle, Wert | A | Erfüllt | Jedes Eingabefeld hat ein zugeordnetes <label for>; Kalendertage sind native Buttons mit aria-label und aria-current, Umfrage-Radios tragen aria-label, fehlerhafte Felder aria-invalid und aria-describedby, der Embed-iframe einen title. Geprüft am 06.07.2026. |
| 4.1.3 | Statusmeldungen | AA | Erfüllt | Fehlerzusammenfassungen nutzen role=alert, Erfolgsmeldungen role=status, die nachgeladene Slot-Liste liegt in einer aria-live=polite-Region. Kleiner Nachschärf-Hinweis: eine Fehlermeldung in der Umfrage nutzt role=status statt role=alert (weiterhin eine gültige Statusmeldung). Geprüft am 06.07.2026. |
Zusätzlich: die neuen Kriterien aus WCAG 2.2
WCAG 2.2 ist seit dem 5. Oktober 2023 eine Empfehlung des W3C. Gegenüber WCAG 2.1 kommen neun Kriterien hinzu, sechs davon auf den Stufen A und AA. Maßgeblich für das Barrierefreiheitsstärkungsgesetz ist derzeit die Norm EN 301 549 in der Fassung 3.2.1 und damit WCAG 2.1. Die Fassung 4.1.1, die WCAG 2.2 auf Stufe AA verlangt, ist im September 2026 erschienen und wird verbindlich, sobald die EU-Kommission sie im Amtsblatt nennt. Deshalb haben wir die sechs neuen Kriterien schon jetzt bewertet. Das Kriterium 4.1.1 „Parsing“ entfällt in WCAG 2.2, es steht in der Tabelle oben weiter mit seiner Bewertung nach WCAG 2.1.
- 4 Erfüllt
- 0 Teilweise erfüllt
- 0 Nicht erfüllt
- 2 Nicht anwendbar
Bewertet wurden die 6 neuen Erfolgskriterien der Stufen A und AA nach WCAG 2.2, am 05.10.2026. Die drei neuen Kriterien der Stufe AAA gehören nicht zum Prüfumfang.
| Nr. | Erfolgskriterium | Stufe | Bewertung | Anmerkung |
|---|---|---|---|---|
| 2.4.11 | Fokus nicht verdeckt (Minimum) | AA | Erfüllt | Im gesamten Stylesheet gibt es kein Element mit position: fixed oder sticky und keine Dialoge, Banner oder Überlagerungen, die ein fokussiertes Element verdecken könnten. Der Sprunglink erscheint beim Fokus oben links über dem Inhalt. Am 05.10.2026 im Browser geprüft: Der Fokus wurde nacheinander auf alle bedienbaren Elemente des Buchungsformulars bei 375 Pixel Breite gesetzt, keines war verdeckt. Im eingebetteten Fenster kann eine feste Kopfleiste der einbettenden Website Inhalt überdecken; das liegt außerhalb dieser Anwendung. |
| 2.5.7 | Ziehbewegungen | AA | Nicht anwendbar | Keine Funktion verlangt Ziehen. Termine werden per Tippen, Klicken oder Tastatur gewählt. Das JavaScript der Strecke (buchung.js, embed.js, embed-frame.js) behandelt nur Tastatur, Laden, Größenänderung und Nachrichten, es gibt keine Zieh- oder Wischbehandlung (kein drag, pointermove oder touchmove), und die Vorlagen enthalten kein draggable. Geprüft am 05.10.2026. |
| 2.5.8 | Zielgröße (Minimum) | AA | Erfüllt | Am 05.10.2026 im Browser vermessen: Kalendertage (86 mal 44 Pixel), Uhrzeiten, Knöpfe und die Zeitzonenauswahl sind mindestens 24 mal 24 Pixel groß. Unter 24 Pixel bleiben nur die Sprachlinks, die Links der Fußzeile und einzelne Links wie „Abbrechen“. Sie erfüllen die Abstandsregel: Ein Kreis von 24 Pixel Durchmesser, auf dem Ziel zentriert, schneidet kein anderes Ziel. Das Kästchen der Datenschutz-Zustimmung und die Auswahlknöpfe der Terminumfrage waren 18 Pixel groß und sind seit dem 05.10.2026 24 mal 24 Pixel groß. Bei 375 Pixel Breite (Handy) vermessen wurden Kalender mit Uhrzeiten, Buchungsformular, Erklärung zur Barrierefreiheit, eingebettetes Fenster, Verwaltung, Umbuchen und Terminumfrage, bei 1280 Pixel Kalender mit Uhrzeiten, Buchungsformular und Profil. |
| 3.2.6 | Einheitliche Hilfe | A | Erfüllt | Die Strecke bietet keinen Chat, keine Hotline und keinen eigenen Hilfebereich auf jeder Seite. Der Weg zu Kontaktangaben und Hilfe führt über die Fußzeile mit Impressum, Datenschutzerklärung und Barrierefreiheit. Sie steht auf der Buchungsseite und im eingebetteten Fenster in derselben Reihenfolge (Vorlagen public.twig und embed.twig). Die Kontaktadresse für Barrieren steht auf der Erklärung zur Barrierefreiheit. Geprüft am 05.10.2026. |
| 3.3.7 | Keine doppelte Eingabe | A | Erfüllt | Name und E-Mail-Adresse werden je Vorgang einmal erfragt, ohne Wiederholungsfeld wie „E-Mail bestätigen“. Nach einer abgelehnten Eingabe stehen Name, E-Mail, Nachricht und Antworten wieder in den Feldern. Wird der gewählte Termin vergeben, bietet die Seite Alternativen an und reicht die Angaben mit. Umbuchen und Stornieren fragen nichts erneut ab. Geprüft am 05.10.2026 an den Vorlagen für Buchung, Warteliste, Umfrage und Verwaltung. |
| 3.3.8 | Barrierefreie Anmeldung (Minimum) | AA | Nicht anwendbar | Gäste melden sich nicht an. Buchung, Umbuchung und Absage laufen ohne Konto, die Verwaltung über einen persönlichen Link aus der Bestätigungsmail. Der angemeldete Bereich der Mandanten gehört nicht zum Geltungsbereich dieser Erklärung. Am Quelltext geprüft, ohne Wertung: Die Anmeldung dort nutzt E-Mail und Passwort mit autocomplete-Angaben für Passwortmanager, der Zwei-Faktor-Code ist als Einmalcode ausgezeichnet, und nirgends ist das Einfügen gesperrt. Geprüft am 05.10.2026. |
Barriere melden
Ist Ihnen bei der barrierefreien Nutzung der Buchungsstrecke ein Mangel aufgefallen oder benötigen Sie einen Inhalt in einer zugänglicheren Form? Bitte melden Sie sich, wir bessern nach:
Stand dieser Erklärung
Diese Konformitätserklärung beruht auf der kriteriengenauen Prüfung aller 50 Erfolgskriterien vom 06.07.2026. Zuletzt nachgeprüft wurde sie am 05.10.2026; welches Kriterium wann geprüft wurde, steht in der Anmerkung des jeweiligen Kriteriums.