← Alle SOPs · Phase 4 · Technik & Interaktion

SOP 39

Formulare Drittanbieter

ProjektleitungGeschäftsführungITRecht

0 von 5 Schritten erledigt0 %

So schaffst du Rechtssicherheit und Nutzerfreundlichkeit ohne doppelte Arbeit

Weil die Nutzung von spezialisierten Tools für Umfragen (Typeform), Terminbuchungen (Calendly) oder Kontaktformulare zwar effizient ist, du damit aber eine kritische Nutzer-Interaktion an einen Dritten auslagerst.

Wenn ein potenzieller Kunde keinen Termin über dein Calendly-Widget buchen kann oder eine Nutzerin kein Feedback über ein Typeform-Formular abgeben kann, verlierst du Geschäftskontakte und verstößt gegen das BFSG.

Die Verantwortung für die Barrierefreiheit der gesamten Nutzerreise liegt also immer bei dir, auch wenn ein Teil davon auf einer externen Plattform stattfindet – wie zum Beispiel bei Formularen von Drittanbietern.

Wann musst du das machen?

Bevor du ein Abonnement für ein Formular-, Umfrage- oder Buchungs-Tool abschließt.

Bevor du ein Formular eines solchen Tools auf deiner Website einbettest.

Als Teil eines regelmäßigen Audits deiner wichtigsten Nutzerreisen (z. B. Kontakt, Bewerbung, Terminbuchung).

Welches Gesetz verlangt das?

EAA / BFSG: Das Gesetz deckt deine gesamte digitale Dienstleistung ab. Eine essenzielle Interaktion wie die Kontaktaufnahme oder Terminbuchung muss für alle Menschen möglich sein, unabhängig von der dahinterliegenden Technologie.

Der Prozess im Detail

Schritt für Schritt – zum Aufklappen und Abhaken.

1🟧 Phase 1: Recherchiere vor dem Test – Was verspricht der Anbieter?›

Bevor du Zeit mit dem Testen verbringst, mache eine schnelle Vorab-Prüfung.

Accessibility Statement suchen: Überprüfe die Website des Anbieters (meist im Footer) auf Begriffe wie „Accessibility“, „Barrierefreiheit“ oder „VPAT“ (Voluntary Product Accessibility Template). Allein die Existenz einer solchen Erklärung zeigt, dass sich das Unternehmen mit dem Thema befasst.

Hilfe-Center durchsuchen: Suche in der Dokumentation des Tools nach „keyboard navigation“, „screen reader“ oder „accessibility“. Findest du dazu keine Einträge, ist das ein sehr schlechtes Zeichen.

2🟨 Phase 2: Der Härtetest – Die Live-Prüfung›

Erstelle ein einfaches Test-Formular mit dem Tool und binde es auf einer Test-Seite deiner Website ein. Führe dann die folgenden Kernprüfungen durch:

Tastatur-Navigation: Kannst du alle Felder, Optionen (Radio-Buttons, Checkboxen) und Buttons nur mit der Tab-Taste (und Shift+Tab) erreichen? Kannst du Dropdowns öffnen und mit den Pfeiltasten und Enter eine Auswahl treffen?

Sichtbarer Fokus: Ist immer ein klarer Fokus-Indikator sichtbar, wenn du durch das Formular tabst?

Labels & Beschriftungen: Sind alle Formularfelder dauerhaft sichtbar beschriftet? Oder verlässt sich das Tool auf Platzhaltertexte, die beim Tippen verschwinden? (Ein häufiger Fehler bei design-lastigen Tools wie Typeform).

Fehlermeldungen: Wenn du das Formular mit Fehlern abschickst: Sind die Fehlermeldungen klar, hilfreich und den richtigen Feldern zugeordnet? Werden sie von Screenreadern vorgelesen?

Kontraste: Haben Texte, Buttons und Formularränder ausreichende Farbkontraste?

3🟩 Phase 3: Der iFrame-Check (bei Einbettung)›

Wenn das Formular per iframe eingebettet wird, gelten zusätzlich die Regeln aus SOP 33.

Titel: Stelle sicher, dass der iframe ein aussagekräftiges title-Attribut hat (z. B. title=“Kontaktformular von Typeform“). Füge es manuell hinzu, falls der Einbettungscode des Anbieters es nicht vorsieht.

Tastaturfalle: Prüfe, ob du mit der Tab-Taste aus dem Formular wieder heraus zu den Inhalten deiner Hauptseite navigieren kannst.

4🟥 Phase 4: Die Entscheidung – Go oder No-Go›

Dokumentiere deine Ergebnisse und triff eine bewusste Entscheidung.

K.o.-Kriterien: Wenn grundlegende Dinge wie die Tastaturbedienung oder sichtbare Labels nicht funktionieren, kannst du das Tool nicht ohne Gesetzesverstoß für essenzielle Prozesse einsetzen.

Risikoabwägung: Bei kleineren Mängeln (z. B. suboptimale Kontraste, die du nicht ändern kannst) musst du entscheiden, ob das Risiko tragbar ist. Eine zwingende Voraussetzung dafür ist eine gute barrierefreie Alternative.

5🟦 Phase 5: Das Sicherheitsnetz – Biete immer eine Alternative an›

Dies ist dein wichtigster Schutz. Selbst wenn das Tool die Tests besteht, solltest du immer eine einfache und barrierefreie Alternative direkt neben der Einbettung anbieten.

Für Kontaktformulare:

„Probleme mit dem Formular? Senden Sie uns eine E-Mail an hallo@firma.de oder rufen Sie uns an unter 030-123456 .“

Für Terminbuchungen:

„Alternativ können Sie Ihren Termin auch telefonisch oder per E-Mail mit uns vereinbaren: 030-123456 oder termin@firma.de .“

Diese Alternative stellt sicher, dass niemand von deiner Dienstleistung ausgeschlossen wird, selbst wenn die Technik des Drittanbieters versagt.

Ergebnis

Am Ende dieser SOP hast du:

Einen bewussten und rechtssicheren Entscheidungsprozess für den Einsatz von Drittanbieter-Tools.

Verhindert, dass du dich von unzugänglichen Lösungen abhängig machst, die deinem Geschäft und Ruf schaden.

Eine sichere Nutzererfahrung für alle geschaffen, bei der es immer einen funktionierenden Ausweg gibt.

Klare Argumente, um im Team zu begründen, warum ein bestimmtes „cooles“ Tool nicht eingesetzt werden kann.

Und hier noch ein hoffentlich nützlicher E-Mail-Baustein, mit dem du darüber informierst, dass nun DSGVO und Barrierefreiheit synchronisiert sind:

DSGVO & Barrierefreiheit – Maßnahmen synchronisiert

Tool-Evaluierungs-Scorecard: Barrierefreiheit von Drittanbieter-Formularen/Komponenten

Tool-Name: [Name des zu bewertenden Tools, z.B. „Typeform“, „Calendly“, „HubSpot Forms“]

Tool-Anbieter: [Name des Anbieters] Verantwortliche(r) für Evaluierung: [Dein Name] Datum der Evaluierung: [Datum] Betroffene Anwendungsbereiche/Prozesse: [Wo soll das Tool eingesetzt werden? Z.B. „Kontaktformulare“, „Newsletter-Anmeldung“, „Terminbuchung“]

Phase 1: Vorab-Recherche (Bewertung: Ja/Nein/Nicht gefunden)

Accessibility Statement / Barrierefreiheitserklärung auf Anbieter-Website gefunden?

Ja (Link: [URL])

Nein

Nicht gefunden

Dokumentation zu Barrierefreiheit (Keyboard Navigation, Screen Reader etc.) im Hilfe-Center gefunden?

Ja (Link: [URL])

Nein

Nicht gefunden

Erste Einschätzung basierend auf Recherche (z.B. Anbieter engagiert sich, oder es gibt keine Hinweise): [Kurze Einschätzung hier eintragen]

Phase 2: Live-Prüfung (Bewertung: ✅ Erfüllt / ⚠️ Mängel / ❌ K.o.-Kriterium)

Tastatur-Navigation (Tab, Shift+Tab, Pfeiltasten, Enter): Alle interaktiven Elemente zugänglich und bedienbar?

✅ Erfüllt

⚠️ Mängel (Beschreibung: [Details])

❌ K.o.-Kriterium (Beschreibung: [Details])

Sichtbarer Fokus-Indikator: Immer klar erkennbar?

✅ Erfüllt

⚠️ Mängel (Beschreibung: [Details])

❌ K.o.-Kriterium (Beschreibung: [Details])

Labels & Beschriftungen: Dauerhaft sichtbar und mit Feldern verknüpft (keine reinen Platzhalter)?

✅ Erfüllt

⚠️ Mängel (Beschreibung: [Details])

❌ K.o.-Kriterium (Beschreibung: [Details])

Fehlermeldungen: Klar, hilfreich, Feldern zugeordnet, Screenreader-kompatibel?

✅ Erfüllt

⚠️ Mängel (Beschreibung: [Details])

❌ K.o.-Kriterium (Beschreibung: [Details])

Kontraste: Ausreichend für Texte, Buttons, Elemente?

✅ Erfüllt

⚠️ Mängel (Beschreibung: [Details])

❌ K.o.-Kriterium (Beschreibung: [Details])

Phase 3: iFrame-Check (bei Einbettung) (Bewertung: ✅ Erfüllt / ⚠️ Mängel / ❌ K.o.-Kriterium / N/A)

iframe hat aussagekräftiges title -Attribut?

✅ Erfüllt

⚠️ Mängel (Beschreibung: [Details])

❌ K.o.-Kriterium (Beschreibung: [Details])

N/A (kein iframe)

Keine Tastaturfalle beim iframe (Navigation zur Hauptseite möglich)?

✅ Erfüllt

⚠️ Mängel (Beschreibung: [Details])

❌ K.o.-Kriterium (Beschreibung: [Details])

N/A (kein iframe)

Phase 4: Entscheidung & Risikoabwägung

Liegt ein K.o.-Kriterium vor (min. ein ❌ in Phase 2 oder 3)?

Ja → Tool nicht nutzbar für essentielle Prozesse.

Nein

Zusammenfassung der Mängel (falls ⚠️ vorhanden): [Hier alle identifizierten Mängel kurz auflisten]

Entscheidung:

GO: Tool kann eingesetzt werden (mit/ohne kleinere Anpassungen).

NO-GO: Tool darf nicht eingesetzt werden.

Eingeschränkt GO: Tool nur für nicht-essentielle Prozesse / mit zwingender Alternative nutzbar.

Begründung der Entscheidung: [Kurze Begründung, warum die Entscheidung getroffen wurde]

Phase 5: Sicherheitsnetz – Alternativlösung (immer verpflichtend)

Alternative(n) geplant und direkt neben der Einbettung kommuniziert?

Alternative(n) für Kontaktformulare: [E-Mail-Adresse, Telefonnummer, Link zu barrierefreiem Formular etc.]

Alternative(n) für Terminbuchungen: [E-Mail-Adresse, Telefonnummer etc.]

Nein (Aktion: [Was wird getan, um dies zu beheben?])

Zusätzliche Kommentare/Aktionen: [Hier können spezifische Notizen, Herausforderungen oder besondere Umstände festgehalten werden.]

Unterschrift zur Dokumentation:

Verantwortliche:r für Evaluierung: _________________________ Datum: ____________

Projektleitung: _________________________ Datum: ____________

DSB / Legal (falls relevant): _________________________ Datum: ____________

Fragen & Antworten

Wie kann ich testen, ob alle Elemente innerhalb eines komplexen Tools (z.B. ein Kalender-Widget) mit der Tastatur bedienbar sind?

Ein umfassender Tastaturtest erfordert mehr als nur Tab und Shift+Tab . Um alle Elemente innerhalb eines komplexen Widgets zu prüfen, nutze zusätzlich:

Pfeiltasten: Für die Navigation innerhalb von Radio-Button-Gruppen, Dropdown-Optionen, Datumsfeldern in Kalendern oder Slidern.

Enter oder Space : Zum Aktivieren von Buttons, Öffnen von Dropdowns oder Auswählen von Checkboxen/Radio-Buttons.

Escape : Zum Schließen von Modal-Dialogen, Pop-ups oder Kalender-Pickern.

Spezielle Navigationstasten: Manche Komponenten, wie Datums-Widgets, nutzen Page Up / Page Down oder Home / End für die Navigation durch Monate/Jahre.

Kontextmenü-Taste: (Oft rechts neben der Leertaste) kann bei manchen Elementen spezifische Funktionen aufrufen.

Der Test sollte alle möglichen Interaktionen abbilden, die ein Mausnutzer ausführen würde, um sicherzustellen, dass Tastaturnutzer die gleiche Funktionalität haben.

Ich habe festgestellt, dass das Einbinden eines Tools per iframe eine Tastaturfalle erzeugt. Der Anbieter hat keine direkte Lösung. Was sind meine Optionen?

Eine Tastaturfalle ist ein K.o.-Kriterium , du, da sie Nutzer:innen komplett blockiert. Wenn der Anbieter keine direkte Lösung bietet, hast du folgende Optionen:

Sofortige alternative Kontaktmöglichkeit: Biete direkt neben dem iframe eine barrierefreie E-Mail-Adresse oder Telefonnummer an, damit Nutzer:innen nicht blockiert sind. Das ist ein absolutes Minimum.

Direkter Dialog mit dem Anbieter: Skaliere das Problem zum Anbieter. Zeige ihm auf, dass dies ein Verstoß gegen gängige Barrierefreiheitsstandards ist und er so eine breite Nutzergruppe ausschließt. Manche Anbieter reagieren auf solches Feedback.

Programmatische Umgehung (hochkomplex): Nur für erfahrene Entwickler:innen: Es gibt JavaScript-Techniken (z.B. mittels postMessage und der Kontrolle des Fokus von der Elternseite in den iframe und zurück), um eine Tastaturfalle zu umgehen. Dies ist aber extrem schwierig, fehleranfällig und hängt stark davon ab, wie das iframe -Innere aufgebaut ist und ob es Nachrichten von außen akzeptiert. Dies ist meist ein letzter Ausweg .

Tool wechseln: Wenn keine der oben genannten Optionen praktikabel ist, solltest du das Tool für essentielle Prozesse nicht einsetzen und nach einer barrierefreien Alternative suchen.

Die SOP erwähnt das title-Attribut für iframes. Was, wenn der Anbieter-Code kein title-Attribut im iframe liefert? Kann ich das selbst hinzufügen?

Ja, du kannst und musst das title -Attribut selbst hinzufügen, wenn der Anbieter es nicht mitliefert, du! Das title -Attribut ist essenziell für Screenreader. Es gibt dem Nutzer einen kurzen, prägnanten Überblick über den Inhalt oder Zweck des iframe .

Wenn du den Einbettungscode erhältst, suchst du den <iframe> -Tag und fügst das Attribut manuell hinzu:

Wähle einen Titel, der den Inhalt des iframe klar beschreibt, z.B. "Kontaktformular von Musterfirma" , "Online-Terminbuchungsservice" oder "Interaktive Karte von Google Maps" . Ohne dieses Attribut ist der iframe für Screenreader-Nutzer ein nicht identifizierbarer, leerer Kasten.

Was bedeutet es, wenn ein Tool sich auf %22Platzhaltertexte, die beim Tippen verschwinden%22 verlässt, und warum ist das ein Problem für die Barrierefreiheit?

Ein „Platzhaltertext“ (oft als placeholder im HTML-Input-Feld) ist der Text, der in einem Eingabefeld erscheint, solange der Nutzer noch nichts eingegeben hat (z.B. „Name“ oder „E-Mail-Adresse“). Sobald der Nutzer zu tippen beginnt, verschwindet dieser Text.

Das Problem für die Barrierefreiheit, du, ist zweifach:

Kurzzeitgedächtnis: Nutzer:innen mit kognitiven Einschränkungen oder Leseschwierigkeiten, die eine Pause beim Ausfüllen machen, vergessen eventuell, was in diesem Feld verlangt wurde, da der Platzhalter verschwunden ist.

Screenreader: Obwohl moderne Screenreader Platzhaltertexte oft lesen können, sind sie kein Ersatz für ein dauerhaft sichtbares <label> -Element, das technisch mit dem Eingabefeld verknüpft ist ( <label for="feldID">Name</label><input type="text" id="feldID"> ). Ein Label bleibt immer sichtbar, unabhängig von der Eingabe und ist der Standard für Barrierefreiheit.

Verlasse dich nie ausschließlich auf Platzhaltertexte für die Beschriftung von Feldern. Sie können eine Ergänzung zum Label sein, aber niemals ein Ersatz.

Wie weit muss die barrierefreie Alternative gehen? Muss sie genau dieselbe Funktionalität bieten wie das Tool des Drittanbieters?

Die Alternative muss ausreichend sein, um den primären Zweck der Interaktion zu erfüllen , du. Sie muss nicht zwingend exakt die gleiche Funktionsvielfalt wie das Drittanbieter-Tool bieten, aber sie muss sicherstellen, dass niemand von deiner Dienstleistung ausgeschlossen wird.

Beispiel Kontaktformular: Wenn das Hauptformular nicht barrierefrei ist, reicht es aus, eine E-Mail-Adresse und/oder eine Telefonnummer als Alternative anzubieten. Der Nutzer kann seine Anfrage so stellen.

Beispiel Terminbuchung: Wenn das komplexe Buchungstool nicht funktioniert, reicht eine Telefonnummer oder E-Mail-Adresse aus, um einen Termin zu vereinbaren.

Best Practice: Die Alternative sollte so einfach und direkt wie möglich sein. Je komplexer das ausgeschlossene Tool, desto wichtiger ist eine einfache und zuverlässige Alternative.

Das Ziel ist, eine Fallback-Lösung zu bieten, die Diskriminierung aufgrund mangelnder Zugänglichkeit verhindert und sicherstellt, dass jeder Kunde seine Anliegen vorbringen kann.

← SOP 38 Übersicht SOP 40 →