Internes Nachschlagewerk · aliaz Werbeagentur

Formulare &
Datenschutz

Stand: DSGVO / TTDSG 2024–2025 Letzte Aktualisierung: Mai 2025

01 Rechtliche Grundlage

DSGVO Art. 6 – Rechtsgrundlage der Verarbeitung

Jede Verarbeitung personenbezogener Daten über ein Formular benötigt eine Rechtsgrundlage. Die relevantesten für Kontaktformulare:

Art. 6 Abs. 1 lit. b DSGVO — Verarbeitung ist rechtmäßig, wenn sie zur Erfüllung eines Vertrags oder zur Durchführung vorvertraglicher Maßnahmen erforderlich ist. → Greift bei konkreten Anfragen: Angebote, Buchungen, Terminvereinbarungen
Art. 6 Abs. 1 lit. f DSGVO — Verarbeitung auf Basis berechtigter Interessen des Verantwortlichen, sofern keine überwiegenden Interessen der betroffenen Person dagegenstehen. → Greift bei allgemeinen Kontaktanfragen; Interessenabwägung erforderlich und zu dokumentieren
Art. 6 Abs. 1 lit. a DSGVO — Einwilligung der betroffenen Person für einen oder mehrere bestimmte Zwecke. → Pflicht z.B. bei Newsletter-Anmeldung; freiwillig, informiert, jederzeit widerrufbar

DSGVO Art. 13 – Informationspflichten beim Formular

Art. 13 Abs. 1 DSGVO — Werden personenbezogene Daten bei der betroffenen Person erhoben, hat der Verantwortliche zum Zeitpunkt der Erhebung Informationen bereitzustellen: Zweck, Rechtsgrundlage, Empfänger, Speicherdauer, Betroffenenrechte. → Datenschutzhinweis direkt am Formular ist Pflicht – nicht nur in der Datenschutzerklärung

TTDSG § 25 – Cookies & Endgeräte-Zugriff

§ 25 Abs. 1 TTDSG — Das Speichern von Informationen in der Endeinrichtung des Endnutzers oder der Zugriff auf bereits gespeicherte Informationen ist nur zulässig, wenn der Endnutzer eingewilligt hat. → Gilt für Cookies und Tracker, die Formular-Dienste wie reCAPTCHA oder externe Formularanbieter setzen
§ 25 Abs. 2 Nr. 2 TTDSG — Ausnahme: Kein Consent nötig, wenn der Zugriff auf die Endeinrichtung unbedingt erforderlich ist, damit der Anbieter einen vom Nutzer ausdrücklich gewünschten Telemediendienst bereitstellen kann. → Technisch zwingend notwendige Cookies (z.B. CSRF-Token) sind consent-frei zulässig
Achtung: Das TTDSG gilt unabhängig von der DSGVO und greift bereits beim bloßen Setzen von Cookies – auch wenn noch keine personenbezogenen Daten verarbeitet werden. Wer das ignoriert, haftet selbst.


03 Das Consent-Formular-Problem

Der vielleicht unterschätzteste UX- und Conversion-Killer auf datenschutzkonformen Websites: das Formular funktioniert erst nach Consent-Erteilung – oder gar nicht.

Typischer Ablauf ohne durchdachte Lösung

1
User landet auf der Seite. Cookie-Banner erscheint. User klickt „Ablehnen" oder schließt den Banner.
2
User füllt das Kontaktformular aus – Name, E-Mail, Nachricht, vielleicht ein langer Text.
3
Klick auf „Absenden". Nichts passiert – oder eine Fehlermeldung erscheint, dass erst reCAPTCHA / Anbieter X zugestimmt werden muss.
4
User muss Cookie-Einstellungen öffnen oder Seite neu laden. Alle Formulardaten sind weg.
5
Conversion-Abbruch. Kein Kontakt. Kein Auftrag. Kein Feedback an den Kunden.
Kein Randproblem. Bei mobilen Nutzern, älteren Usern oder Nutzern mit Browser-Datenschutz-Erweiterungen (uBlock, Privacy Badger) passiert das deutlich häufiger als angenommen. Viele Kunden bemerken es erst, wenn Anfragen dauerhaft ausbleiben – und fragen sich, warum die neue Website schlechter konvertiert als die alte.

Ursachen im Überblick

Google reCAPTCHA im Formular

Contact Form 7, WPForms, Gravity Forms binden reCAPTCHA v3 standardmäßig ein. Das CMP blockt es korrekt – bis Consent erteilt ist. Submit ohne gültige reCAPTCHA-Response schlägt serverseitig fehl.

Formulardaten gehen an Dritte

Formspree, HubSpot-Formulare, Zapier-Integrationen – sobald Daten auf Drittserver wandern, greift Consent-Pflicht. Das CMP blockt Skripte, Submit wird funktionslos.

Falsch konfiguriertes CMP

Schlecht konfigurierte CMPs blocken auch technisch notwendige Endpunkte. Die finale Verantwortung für eine korrekte CMP-Konfiguration liegt beim Kunden als Websitebetreiber – er ist rechtlich Verantwortlicher im Sinne der DSGVO. Die Agentur kann beraten und umsetzen, aber keine rechtsverbindliche Garantie übernehmen.


04 Technische Lösungsansätze

Grundprinzip: Formulare sollten technisch so gebaut sein, dass sie ohne Drittanbieter-Consent funktionieren. Alles andere ist eine UX-Zeitbombe, die beim Kunden landet.

Option A – Server-seitiger Mailversand (Best Practice)

Empfohlen PHP / WordPress + SMTP

Formular-POST geht an eigene WP-Instanz → PHP verarbeitet → SMTP-Versand via eigenem Mailserver oder Transactional-Mail (Mailgun, Brevo, Postmark, Elementor Site Mailer). Kein externer JS nötig. Kein Consent für den Kernprozess.

Option B – reCAPTCHA ersetzen

DSGVO-freundlich Friendly Captcha

Proof-of-Work im Browser. Kein Cookie, kein Tracking. EU-Server. Consent in der Regel nicht nötig. Hosted ab € 9/Monat – Self-Hosting erfordert eigene Infrastruktur, deren Entwicklungs- und Betriebskosten den Monatstarif in der Regel übersteigen.

Kostenfrei Honeypot-Feld

Verstecktes Feld. Bots füllen es aus, Menschen nicht. Kein Consent, kein Drittanbieter. Für viele Projekte vollkommen ausreichend.

Prüfen Cloudflare Turnstile

Keine sichtbare Challenge. Datentransfer an Cloudflare – Consent im Einzelfall prüfen. Kostenfrei.

Prüfen hCaptcha

Datenschutzfreundlicher als Google. Consent weiterhin empfohlen, aber weniger kritisch. Kostenfrei.

Option C – Consent-aware Nachladen (Notlösung)

Wenn ein externer Dienst zwingend nötig ist: Submit initial deaktivieren, CMP-Callback nutzen (z.B. Borlabs Cookie JS-Events). Nachteil: User muss Consent vor Formularnutzung aktiv geben – UX-Problem bleibt bestehen, nur besser kommuniziert.

Anti-Pattern vermeiden: Formular anzeigen, Submit aktiv lassen, nach Klick Fehlermeldung zeigen. User hat Daten eingegeben – das ist der häufigste Frustrationspunkt und führt direkt zu Abbrüchen.

05 Formulare ohne Besucher-Zustimmung Empfehlung

Das Ziel: ein Formular, das für jeden Besucher funktioniert – unabhängig davon, ob er den Cookie-Banner akzeptiert, ablehnt oder ignoriert. Technisch gut lösbar, wenn von Anfang an die richtigen Entscheidungen getroffen werden.

Die drei Bedingungen für Consent-Freiheit (§ 25 Abs. 2 Nr. 2 TTDSG):
(1) Das Formular lädt keine Drittanbieter-Skripte.  (2) Daten werden nicht an externe Server gesendet.  (3) Es werden keine Cookies gesetzt außer technisch zwingend notwendigen.
Sind alle drei Bedingungen erfüllt, greift die gesetzliche Ausnahme – kein Consent nötig. → DSGVO Art. 13 (Informationspflicht + Datenschutzhinweis am Formular) bleibt davon unberührt und ist immer Pflicht

Empfohlener Stack

Nuxt / Vue Frontend + eigener API-Endpunkt
Für Headless-Projekte und Custom-Builds
Kein Consent nötig Headless-kompatibel Volle Kontrolle

Frontend: Formular in Vue 3 / Nuxt. Kein externes Captcha-Skript. Honeypot-Feld als verstecktes Input, Zeitstempel-Prüfung.

API-Route: Nitro/Express-Endpunkt (/api/contact) auf eigenem Server. Validierung + Spam-Check server-seitig, Rate-Limiting per Middleware.

Mailversand: Nodemailer mit eigenem SMTP (Brevo, Mailgun, Postmark). Keine Drittanbieter-Skripte im Browser.

Friendly Captcha – wenn Captcha explizit gewünscht wird
DSGVO-konformes Captcha ohne Consent-Pflicht
Kein Google EU-Server Hosted-Dienst

Funktionsweise: Proof-of-Work – Browser löst kryptografisches Puzzle. Keine Cookies, kein Fingerprinting, kein Tracking-Profil.

Datenschutz: Laut Anbieter und überwiegender Datenschutzexperten-Einschätzung kein Consent nach § 25 TTDSG nötig. WP-Plugin verfügbar, kompatibel mit Fluent Forms und CF7.

Kosten: Hosted ab € 9/Monat – empfohlen. Das Open-Source-Paket existiert, erfordert für Self-Hosting jedoch eigene Server-Infrastruktur und Wartung. Entwicklungs- und Betriebsaufwand übersteigen den Monatstarif des Hosted-Dienstes in der Regel deutlich. Self-Hosting daher nur für Projekte mit spezifischen Anforderungen sinnvoll.

Spam-Schutz ohne Drittanbieter – Methodenvergleich

MethodeConsentWirkungAufwandKosten
Honeypot-FeldNeinMittel (einfache Bots)MinimalKostenlos
Zeitbasierte PrüfungNeinMittel (zu schnelle Submissions)GeringKostenlos
Rate-Limiting (server)NeinHoch (pro IP)MittelKostenlos
Friendly CaptchaNein*HochGering (hosted)ab € 9/Monat
Cloudflare TurnstileIm EinzelfallSehr hochGeringKostenlos
Google reCAPTCHA v3JaSehr hochGeringKostenlos
Externer FormularanbieterJaJe nach AnbieterMinimal€ 0–50+/Monat

* Friendly Captcha: Einschätzung der Mehrheit der Datenschutzexperten, nicht höchstrichterlich entschieden. Bei sensiblen Projekten juristische Absicherung empfehlen.

Honeypot – Implementierung

<!-- HTML: Honeypot unsichtbar per CSS --> <div style="position:absolute;left:-9999px;opacity:0" aria-hidden="true"> <label for="website">Bitte leer lassen</label> <input type="text" name="website" id="website" tabindex="-1" autocomplete="off"> </div> # PHP: Serverseitige Prüfung if (!empty($_POST['website'])) { http_response_code(400); exit; // Bot erkannt } // WordPress-Hook (Fluent Forms): add_filter('fluentform/submission_requirements', function($req, $form) { if (!empty($_POST['website'])) { return new WP_Error('spam', 'Spam erkannt'); } return $req; });

Zeitbasierte Prüfung

<!-- HTML: Timestamp beim Formular-Load --> <input type="hidden" name="_form_time" id="_form_time"> <script> document.getElementById('_form_time').value = Date.now(); </script> # PHP: Unter 3 Sekunden = Bot $elapsed = (time() * 1000) - intval($_POST['_form_time']); if ($elapsed < 3000) { http_response_code(400); exit; }
Kombinations-Empfehlung: Honeypot + Zeitprüfung + Rate-Limiting. Diese drei Maßnahmen fangen über 95% des Bot-Traffics ab – vollständig ohne Drittanbieter, ohne Consent, ohne Kosten.

06 Anbieter & Tools

Formular-Plugins

Consent nötig Contact Form 7 + reCAPTCHA

reCAPTCHA v3 läuft seitenübergreifend. CMP muss blocken → Submit bricht ohne Consent. Ohne reCAPTCHA und mit eigenem SMTP aber Consent-frei nutzbar.

Consent nötig (default) WPForms / Gravity Forms

Gleiches Problem wie CF7 bei reCAPTCHA. Mit Addons (HubSpot, Salesforce) doppelte Consent-Pflicht. Ohne Drittdienste: Consent-frei möglich.

Empfehlenswert Fluent Forms

Honeypot integriert, Friendly Captcha Add-on verfügbar. SMTP-Versand nativ, keine Drittdienste erzwungen. Bestes Kosten-Nutzenverhältnis für diese Anforderung.

Prüfen Elementor Forms (Pro)

Direkt in Elementor integriert. Standard-Versand via WordPress-Mail. reCAPTCHA optional – weglassen = Consent-frei. Zusammen mit Site Mailer ideal.

Consent nötig HubSpot-Formulare

Lädt HubSpot-Script nach. Daten auf HubSpot-Servern (USA). Standard Consent Framework + AVV erforderlich.

DSGVO-freundlich Mautic (self-hosted)

Open-Source Marketing Automation. Self-hosted = keine Drittdaten. Consent nur bei externen Trackern.

SMTP & Mailversand – Tools

ToolKostenConsent am FormularAVV nötigBemerkung
Elementor Site MailerKostenfrei (Limits) / Elementor-AboNein*Ja (Elementor)Kein extra SMTP-Setup, Elementor-Account nötig
WP Mail SMTP + eigener ServerKostenlos (Plugin)NeinNeinMaximale Datensouveränität
Brevo (SMTP)Kostenlos bis 300/TagNein*Ja (Brevo)EU-Hoster, gute DSGVO-Basis
MailgunAb € 0 / Pay-per-useNein*Ja (Mailgun)US-Anbieter, SCCs prüfen
PostmarkAb $ 15/MonatNein*Ja (Postmark)Hohe Deliverability, US-Anbieter

* Kein Consent für das Formular selbst nötig – der SMTP-Versandweg ist technisch notwendig und consent-frei. AVV mit dem jeweiligen Mail-Anbieter separat abschließen.


07 Kundenmitteilung

Vorlage für die Kommunikation mit Kunden – bewusst ohne Juristendeutsch, verständlich und handlungsorientiert.

Betreff
Kontaktformular & Datenschutz – wichtige Information für Ihre Website
Liebe/r [Kunde], im Zuge der aktuellen Datenschutzanforderungen (DSGVO + TTDSG) möchten wir Sie auf einen Punkt aufmerksam machen, der Ihr Kontaktformular direkt betrifft. Viele moderne Formulare setzen für ihren Betrieb auf externe Dienste – zum Beispiel Google reCAPTCHA zum Schutz vor Spam. Diese Dienste laden Skripte von Drittanbietern und setzen Cookies, was nach geltendem Recht eine aktive Einwilligung Ihrer Besucher erfordert. Das hat eine direkte Auswirkung auf die Nutzbarkeit: Besucher, die den Cookie-Banner ablehnen oder bestimmte Dienste nicht freigeben, können das Formular unter Umständen nicht erfolgreich absenden – obwohl der Button sichtbar ist. Jemand füllt das Formular vollständig aus, klickt auf „Senden" – und es passiert nichts. Die eingegebenen Daten gehen verloren. Um das zu vermeiden, gibt es zwei Möglichkeiten: Option 1 – Consent-Management-Tool nachrüsten: Wir integrieren ein geeignetes Tool (z.B. Borlabs Cookie oder einen vergleichbaren Anbieter), das Besucher korrekt um Erlaubnis bittet. Kosten: ca. 30–50 € pro Jahr. Wichtig: Wer den Banner ablehnt, kann das Formular unter Umständen nicht absenden – das ist technisch bedingt und bei dieser Lösung nicht vollständig vermeidbar. Option 2 – Formular technisch umstellen (unsere Empfehlung): Wir bauen das Formular so um, dass es ohne externe Dienste auskommt. Statt Google reCAPTCHA verwenden wir datenschutzfreundliche Alternativen. Das Formular funktioniert dann für alle Besucher – unabhängig von der Cookie-Entscheidung. Keine jährlichen Zusatzkosten für externe Tools. Einen Datenschutzhinweis direkt am Formular benötigen wir in beiden Fällen – das ist gesetzliche Pflicht und bleibt bestehen. Gerne besprechen wir das kurz und setzen die passende Lösung für Ihre Website um. Mit freundlichen Grüßen [Agentur]
Agentur-Hinweis: Diese Vorlage bewusst ohne Rechtsbegriffs-Dschungel. Kunden verstehen „das Formular funktioniert nicht" – nicht „§ 25 TTDSG Abs. 1". Ziel: Verständnis erzeugen, Handlungsbereitschaft herstellen, Projekt auslösen.

08 Checkliste – Formular-Audit

Für neue Projekte und beim Review bestehender Websites. Klicken zum Abhaken.


09 Externe Dienste: Maps, Videos & Social Media

Neben Formularen sind eingebettete Drittinhalte der häufigste Datenschutz-Fallstrick auf gewerblichen Websites. Google Maps, YouTube-Videos, Instagram-Feeds oder Facebook-Buttons laden beim bloßen Seitenaufruf Skripte und setzen Cookies von Drittservern – ohne dass der Besucher das Formular ausfüllt oder einen Button drückt.

Rechtliche Grundlage: § 25 Abs. 1 TTDSG in Verbindung mit Art. 6 Abs. 1 DSGVO. Das Laden externer Inhalte, das mit dem Setzen von Cookies oder dem Übermitteln von Nutzerdaten an Drittserver verbunden ist, erfordert eine aktive, vorherige Einwilligung des Besuchers – unabhängig davon, ob der Inhalt interaktiv ist oder nur angezeigt wird. → Bereits das Einbetten eines YouTube-Iframes ohne Datenschutzmaßnahme ist ein Verstoß gegen § 25 TTDSG

Betroffene Dienste im Überblick

Consent Pflicht Google Maps

Lädt Google-Skripte und setzt Tracking-Cookies beim Seitenaufruf. Überträgt IP-Adresse und ggf. Standortdaten an Google (USA). Betrifft auch die Maps Embed API.

Consent Pflicht YouTube / Vimeo

Standard-Einbettung via iframe lädt sofort Player-Skripte und Cookies. YouTube überträgt Daten an Google auch ohne Play-Klick. Vimeo datenschutzfreundlicher, aber nicht consent-frei.

Consent Pflicht Social Media Plugins

Facebook Like-Button, Instagram-Feed, LinkedIn Share, Twitter/X Embed – alle laden externe Skripte und ermöglichen Cross-Site-Tracking. Bereits das Laden = Datenweitergabe.

Consent Pflicht Google Fonts (extern)

Werden Fonts direkt von Google-Servern geladen, wird die IP-Adresse des Besuchers an Google übermittelt. Lösung: Fonts lokal hosten (keine Consent-Pflicht).

Prüfen OpenStreetMap / Leaflet

Als datenschutzfreundlichere Maps-Alternative. Tile-Server überträgt IP – Consent-Pflicht je nach Einbettung und Tile-Provider. Eigener Tile-Server = consent-frei möglich.

Prüfen Chat-Widgets / Live-Chat

Intercom, Drift, Zendesk Chat laden bei Initialisierung externe Skripte. Erst nach Consent laden oder durch datenschutzfreundliche Alternative ersetzen.

Die Lösung: 2-Klick-Lösung / Consent-Wrapper

Externe Inhalte dürfen standardmäßig nicht geladen werden. Stattdessen wird zunächst ein Platzhalter angezeigt, der den Nutzer informiert und um Zustimmung bittet. Erst nach aktivem Klick wird der eigentliche Inhalt geladen.

Best Practice: 2-Klick / Consent-Wrapper
(1) Platzhalter mit Beschreibung anzeigen: „Hier ist eine Google Maps Karte eingebettet. Zum Laden stimmen Sie der Übertragung Ihrer Daten an Google zu."
(2) Button: „Karte laden" – erst nach Klick wird der iframe eingebettet.
(3) Optional: Checkbox „Immer erlauben" speichert die Einwilligung per Cookie für den aktuellen Besuch.

Technische Umsetzung

WordPress Borlabs Cookie Content Blocker

Borlabs Cookie (und vergleichbare CMPs) können externe Inhalte automatisch blocken und durch einen Consent-Wrapper ersetzen. Konfiguration pro Dienst möglich.

WordPress Oembed-Proxy / lokales Hosting

YouTube: Privacy-Enhanced Mode (youtube-nocookie.com) reduziert Tracking, ist aber kein vollständiger Verzicht. Besser: Thumbnails lokal, Video auf Klick nachladen.

Nuxt / Vue Lazy-Load mit Consent-Check

Komponente prüft beim Mount den CMP-Status. iframe-src wird erst gesetzt wenn Consent für den jeweiligen Dienst vorliegt. CMP-Callback bei nachträglicher Zustimmung nachladen.

Alle Stacks Google Maps ersetzen

Für einfache Standortkarten: statisches Kartenbild verlinkt auf maps.google.com (kein iframe, kein Tracking). Oder: OpenStreetMap mit eigenem Tile-Server.

Wichtig für die Kundenberatung: Viele Kunden wünschen sich explizit eine Google Maps Einbettung oder ein Instagram-Feed-Widget. Das ist möglich – aber erfordert zwingend einen funktionierenden Consent-Wrapper. Der Hinweis, dass ohne diesen eine Abmahnung drohen kann, sollte schriftlich erfolgen und im Angebot dokumentiert werden.

10 Barrierefreiheit: WCAG & BFSG

Barrierefreiheit und Datenschutz werden in Projekten oft getrennt gedacht – dabei betreffen beide dieselben Websites und denselben Personenkreis. Ab 2025 gelten für viele gewerbliche Websites verbindliche Anforderungen, die auch Formulare direkt betreffen.

BFSG – Barrierefreiheitsstärkungsgesetz: Seit dem 28. Juni 2025 müssen bestimmte digitale Produkte und Dienstleistungen, die auf dem deutschen Markt angeboten werden, barrierefrei sein. Das Gesetz setzt die europäische Richtlinie EAA (European Accessibility Act, Richtlinie 2019/882/EU) in deutsches Recht um. → Betroffen: u.a. E-Commerce, Online-Banking, Streaming, Apps – nicht automatisch alle gewerblichen Websites. Prüfung im Einzelfall erforderlich.

Was ist WCAG?

Die Web Content Accessibility Guidelines (WCAG) sind ein international anerkannter Standard des W3C, der beschreibt, wie Webinhalte barrierefrei gestaltet werden. Die Anforderungen sind in vier Prinzipien gegliedert:

Wahrnehmbar Perceivable

Inhalte müssen von allen Sinnen wahrnehmbar sein. Bilder brauchen Alt-Texte, Videos Untertitel, Kontraste müssen ausreichend sein.

Bedienbar Operable

Alle Funktionen müssen per Tastatur bedienbar sein. Kein Inhalt darf nur per Maus erreichbar sein. Formulare müssen vollständig per Tab navigierbar sein.

Verständlich Understandable

Sprache, Struktur und Verhalten müssen vorhersehbar sein. Fehlermeldungen in Formularen müssen klar benennen, was falsch ist und wie man es korrigiert.

Robust Robust

Inhalte müssen mit aktuellen und zukünftigen Hilfstechnologien (Screenreader, Braille-Zeile) kompatibel sein. Korrekte HTML-Semantik ist Pflicht.

Konformitätsstufen

StufeBedeutungRelevanz
AMinimalanforderungen – BasiszugänglichkeitAbsolute Untergrenze, immer einhalten
AAStandard – von BFSG und EN 301 549 gefordertZielstandard für gewerbliche Websites
AAAHöchstsanforderungen – nicht immer erreichbarEmpfehlung für öffentliche Stellen, Bildung

Konkrete Anforderungen an Formulare

Labels & Beschriftungen (WCAG 1.3.1, 3.3.2)

Jedes Eingabefeld braucht ein programmatisch verknüpftes <label>. Placeholder-Text allein ist kein ausreichendes Label – er verschwindet beim Tippen.

Fehlermeldungen (WCAG 3.3.1, 3.3.3)

Fehler müssen in Text beschrieben werden – nicht nur durch Farbe oder ein Icon. Die Meldung muss erklären was falsch ist und idealerweise einen Korrekturvorschlag enthalten.

Kontrastverhältnis (WCAG 1.4.3)

Text zu Hintergrund muss mindestens 4,5:1 betragen (AA). Für große Schrift (18pt / 14pt fett) mindestens 3:1. Eingabefelder, Buttons und Fokus-Indikatoren sind ebenfalls betroffen.

Tastaturzugänglichkeit & Fokus (WCAG 2.1.1, 2.4.7)

Alle Formularelemente müssen per Tab erreichbar sein. Der Fokus muss sichtbar sein – das standardmäßige Browser-Outline nicht einfach per CSS entfernen.

Autocomplete (WCAG 1.3.5)

Persönliche Eingabefelder (Name, E-Mail, Adresse) sollten das autocomplete-Attribut nutzen. Das hilft besonders Menschen mit kognitiven Einschränkungen.

BFSG – Wen betrifft es konkret?

Das BFSG gilt nicht automatisch für alle gewerblichen Websites. Es betrifft primär Unternehmen, die bestimmte digitale Dienstleistungen oder Produkte anbieten: Online-Shops (B2C), Banking-Apps, Streaming-Dienste, E-Books, Verkehrsdienstleistungen. Reine Informationswebsites ohne transaktionale Funktion fallen in vielen Fällen nicht darunter – aber die Abgrenzung ist noch nicht abschließend durch Rechtsprechung geklärt. Im Zweifel: rechtliche Prüfung empfehlen.
Empfehlung für die Projektpraxis: WCAG AA als Standard in die Angebotsleistung aufnehmen und aktiv kommunizieren. Barrierefreiheit ist kein Extra-Feature, sondern ein Qualitätsmerkmal – und für wachsende Zielgruppen schlicht die Voraussetzung zur Nutzung. Wer heute barrierefrei baut, spart morgen Nacharbeit.

Entscheidungsbaum: Bin ich vom BFSG betroffen?

Der folgende Entscheidungsbaum hilft bei der ersten Einschätzung. Er ersetzt keine rechtliche Prüfung, gibt aber eine praxisnahe Orientierung.