Compliance & DSGVO

Echter axe-core-Lauf gegen WCAG 2.0, 2.1 und 2.2 Level A und AA (Tags `wcag2a`, `wcag2aa`, `wcag21a`, `wcag21aa`, `wcag22a`, `wcag22aa`) in Playwright-Chromium — ein umfangreiches Regelwerk statt einfacher HTML-Heuristik, inklusive der neuen 2.2-Kriterien wie Zielgröße/Target-Size (2.5.8). Dieser detaillierte axe-core-Lauf läuft im Monitoring-Daemon sowie im kostenlosen öffentlichen BFSG-Tool; im On-Demand-Scan stammt der Barrierefreiheits-Score dagegen aus Lighthouse. Jede Verletzung trägt Regel-ID, Kurztitel, Beschreibung, Impact-Severity (critical/serious/moderate/minor), Anzahl betroffener Elemente und Help-URL zur Deque University — die Liste zeigt bis zu 25 Verletzungen plus bis zu 15 Regeln aus der `incomplete`-Ausgabe von axe-core, die als Kandidaten für eine manuelle Nachprüfung gelten. Einige 2.2-Kriterien — etwa Consistent Help (3.2.6), Redundant Entry (3.3.7) und Accessible Authentication (3.3.8) — sind grundsätzlich nicht automatisiert testbar; für sie existiert keine axe-core-Regel, sie tauchen daher weder in der Verletzungs- noch in der `incomplete`-Liste auf und müssen rechtlich gesehen ohnehin manuell geprüft werden. Die seit 28.06.2025 in Deutschland geforderten Nachweise werden so regelmäßig automatisch erhoben.

Sinkt der gemessene axe-core-Score unter 50, legt das Monitoring automatisch einen Alert „accessibility_low“ an — Severity warning, bei einem Score unter 30 critical. Der Alert nennt den Score und die Zahl der gefundenen WCAG-Verstöße und wird (wie alle Alerts) über Ihre konfigurierten Kanäle zugestellt. So fällt eine plötzliche Regression auf, etwa nach einem Theme-Update.

Aus dem aktuellen Barrierefreiheits-Score erzeugt XICTRAQ auf Knopfdruck eine Vorlage für die Erklärung zur Barrierefreiheit (Markdown, herunterladbar). Der Konformitätsstatus wird aus dem Score abgeleitet: ab 80 % „teilweise konform“, darunter „nicht konform“. „Vollständig konform“ vergibt die Vorlage bewusst nie — eine automatisierte Messung deckt nur einen Teil der WCAG-Erfolgskriterien ab und kann vollständige Konformität nicht belegen. Liegt für die Website noch keine Messung vor, wird keine Vorlage erzeugt. Die Vorlage folgt der Struktur nach BITV 2.0 / Richtlinie (EU) 2016/2102 und enthält die Pflicht-Abschnitte Stand der Vereinbarkeit, nicht barrierefreie Inhalte, Erstellungsdatum, Feedback-/Kontaktangaben und Durchsetzungsverfahren. Eine anpassbare Startvorlage — keine fertige Rechtsurkunde.

Eigenständig vom technischen axe-core-/WCAG-Scan prüft XICTRAQ jetzt, ob eine Barrierefreiheitserklärung verlinkt ist — und wie inhaltlich tief sie ist. Im Erklärungstext wird nach drei Bausteinen der EU-Mustererklärung zur Barrierefreiheit (Durchführungsbeschluss (EU) 2018/1523, Anhang Abschnitt 1) gesucht: einem Feedback-/Kontaktmechanismus für gemeldete Barrieren, einer Aussage zum Konformitätsstatus (z. B. „teilweise konform“) und einem Erstellungs-/Aktualisierungsdatum. Fehlt ein Baustein, erscheint ein Info-/Low-Hinweis. Die Angaben, die § 14 Abs. 1 Nr. 2 BFSG mit Anlage 3 von Dienstleistern verlangt, prüft XICTRAQ nicht einzeln. Das ist eine reine Vorhandenseins- und Inhalts-Prüfung — keine Rechtsprüfung und kein Ersatz für den technischen WCAG-Scan.

Der Content-Scan erkennt jetzt zusätzlich zum Impressum- und Datenschutz-Link auch einen AGB-/Terms-Link. So sehen Sie auf einen Blick, ob die üblichen Pflicht- und Standard-Rechtstexte überhaupt verlinkt sind. Fehlt ein AGB-Link, ist das ein Info-/Low-Hinweis — eine inhaltliche oder rechtliche Bewertung der Texte erfolgt nicht.

Beim Content-Scan werden im HTML-Body fünf häufige Risiko-Muster erkannt: externe Google Fonts (fonts.googleapis.com / fonts.gstatic.com — DSGVO-Risiko nach LG München I 3 O 17493/20), Google Analytics inkl. gtag/ga.js, Facebook Pixel (fbevents.js / fbq-Aufruf), fehlender Impressum-Link und fehlender Datenschutz-Link. Befunde gehen in den Privacy-Risiko-Score ein und werden im Compliance-Tab mit Severity (high/medium) angezeigt.

Für eingebundene Dienste wie Google Maps und reCAPTCHA wird der Befund aus den tatsächlichen Browser-Netzwerk-Anfragen vor jeder Consent-Interaktion abgeleitet — nicht mehr nur aus einem HTML-Muster-Treffer. Lädt ein Tracker nachweislich vor Einwilligung über das Netzwerk, bleibt das eine klare Verletzung (hohe Severity). Wird das Snippet hingegen von einer Consent-Management-Plattform (CMP) zurückgehalten und feuert erst nach Zustimmung, wird das nicht mehr als harter Verstoß gewertet, sondern als informativer Hinweis „Consent-Steuerung prüfen (Interaktionstest erforderlich)“ ausgewiesen — das entfernt Fehlalarme auf korrekt per CMP gesteuerten Seiten. Steht keine Browser-Netzwerk-Analyse zur Verfügung, wird ein reiner HTML-Treffer als „geringe Konfidenz“ markiert. Kein Rechtsrat, sondern ein technischer Indikator.

Auf Knopfdruck (Button „Cookie-Banner prüfen“, ca. 60 Sekunden) lädt Playwright die Seite in einem frischen Profil ohne Cookies. Phase 1 (vor jeder Einwilligung): Accept- und Reject-Buttons werden per Textmuster (DE + EN) gefunden und nach Fläche, Hintergrundfarbe und Above-the-fold-Lage verglichen. Dark-Pattern-Befunde: „no_reject_button“ (kein Ablehnen, BGH I ZR 7/16), „reject_smaller“ (Ablehnen < 60 % der Akzeptieren-Fläche), „reject_unstyled“ (nur Akzeptieren hat farbigen Hintergrund), „reject_below_fold“ und „buttons_not_identifiable“ (Banner sichtbar, Buttons im Shadow-DOM/iframe nicht auffindbar). Parallel werden alle Dritt-Tracker, die VOR Consent über das Netzwerk laden, klassifiziert (z. B. Google Analytics, Google Ads, Meta Pixel) und als „tracker_before_consent“ gemeldet. Phase 2 (nach Klick auf „Ablehnen“ + Reload): lädt nach Reject trotzdem Tracking, wird „reject_does_not_block“ (kritisch) gesetzt und banner_actually_blocks=false — der Banner ist „Theater“. Gesamt-Score 0–100.

Bewertungs-Siegel (z. B. Trustpilot, Trusted Shops, ProvenExpert, eKomi) laden auf vielen Seiten selbst Google Fonts, Maps oder Analytics nach. Solche Sub-Requests werden über die Initiator-Kette (Chrome-DevTools-Protocol-Script-Stack) dem Widget zugeordnet und als „tracker_via_trust_widget“ gesondert ausgewiesen — sie ziehen KEINEN Punkteabzug von der Seite, weil sie dem Drittanbieter-Siegel zuzurechnen sind. Das entfernt Pre-Consent-Fehlalarme. Hinweis: Wer ein solches Siegel einbindet, hat ggf. über den Widget-Anbieter selbst eine Consent-Pflicht.

Beim Content-Scan wird der HTML-Body nach src=- und href=-Attributen durchsucht, die auf http:// zeigen (unabhängig vom Element-Typ, etwa Bilder, Skripte oder Stylesheets). Browser blocken diese auf HTTPS-Seiten — das führt zu unsichtbaren Layout-Fehlern. Anzahl + Liste der Fundstellen im Dashboard.

Der Score ist `erreichte Punkte / mögliche Punkte × 100`, gerundet auf ganze Prozent. Ampel: ab 80 grün (geringes Risiko), ab 50 gelb (mittleres Risiko), darunter rot (hohes Risiko). Sind alle zehn Kriterien gemessen, beträgt die Summe 115 Punkte — ein fehlendes Impressum allein kostet also rund 13 Prozentpunkte. Unter dem Ring listet die Karte jeden Verstoß einzeln mit Paragraph und Punktabzug auf.

Ein Kriterium hat drei Zustände: erfüllt, verletzt — oder noch nicht erhoben. Solange für eine Website noch kein vollständiger Scan gelaufen ist, fehlen einzelne Rohwerte; diese Kriterien erscheinen in der Karte unter „Nicht geprüft“ und fallen aus Zähler UND Nenner heraus. Der Score bezieht sich dann ausdrücklich nur auf die tatsächlich gemessenen Kriterien, der Zähler darunter nennt die Zahl der geprüften. Ein fehlender Messwert wird nie als Verstoß gewertet — ein Falschbefund mit Paragraph und Punktabzug wäre schädlicher als eine offen ausgewiesene Lücke. Ist noch gar nichts gemessen, bleibt die Ampel grau und der Ring zeigt einen Strich statt einer Zahl.

SSL, CSP und Domain-Ablauf liefert der automatische Scan (Free alle 24 Stunden, bezahlte Pläne alle 6 Stunden; der Domain-Ablauf per RDAP läuft in jedem Plan täglich). HSTS, Cookies, Impressum, Datenschutz, Google Analytics und Facebook-Pixel erhebt der vollständige Scan, den Sie auf Knopfdruck starten; Google Fonts zusätzlich der tägliche Cookie-Scan im Browser. Der Zeitstempel unter der Karte nennt den ältesten dieser Stände. Derselbe Score wird im Changelog vermerkt, wenn er sich um mindestens 10 Punkte oder über eine Ampelgrenze hinweg ändert.