Wie wir einen BFSG-Scanner in 2.000 Zeilen gebaut haben

Dieser Artikel richtet sich an Entwickler und Tech-Leads, die verstehen wollen, was ein BFSG-Scanner wirklich tut — und warum die populären „Overlay-Widgets" kein echtes BFSG-Compliance-Tool sind. Kein Marketing, nur Technik.

Die Architektur

Compli24 besteht aus drei Komponenten: einem headless-Browser (Playwright + Chromium), einem Analyse-Stack (axe-core + eigene Module) und einer LLM-Schicht (Claude Haiku) für Fix-Vorschläge. Die gesamte Scanner-Logik ist unter 2.000 Zeilen Python — und zwar weil die schweren Teile (DOM-Traversal, Kontrastberechnung, ARIA-Parsing) von axe-core erledigt werden, einer der am besten getesteten Open-Source-Bibliotheken für Web-Accessibility.

Warum Playwright und nicht ein HTTP-Fetch?

Ein statischer HTML-Fetch ist Schnee von gestern. Moderne Websites (Shopify, Next.js, React-SPAs) laden 80% ihres Inhalts erst clientseitig — Produktlisten, Cookie-Banner, Chatbot-Widgets, ARIA-live-Regionen. Wer nur das initiale HTML prüft, übersieht genau die dynamischen Elemente, die im BFSG am häufigsten Probleme machen.

Playwright startet echtes Chromium, wartet auf domcontentloaded + eine kurze Soft-networkidle-Phase (5s Timeout), und injiziert dann axe-core direkt in die Seite. Das axe-Script läuft im Kontext der Seite, sieht alles was ein Screenreader sehen würde, und gibt eine strukturierte Liste von Violations zurück.

Warum axe-core statt Eigenbau?

Wir könnten die Accessibility-Checks selbst schreiben. Wir würden dafür aber 5 Jahre brauchen, um die Qualität von axe-core zu erreichen. Die Deque-Systems-Entwickler pflegen axe-core seit 2015, haben 90+ WCAG-Regeln sauber implementiert und werden von Google, Microsoft und Deque selbst eingesetzt. Wer eigene Parser baut, wiederholt Jahre Forschungsarbeit — und macht Fehler, die axe-core schon längst behoben hat.

Das Ergebnis: statt Accessibility-Regeln zu pflegen, pflegen wir die Interpretation dieser Regeln im BFSG-Kontext: welche Violation zählt als „kritisch" im Sinne des § 3 BFSG? Welche Fix-Suggestion funktioniert in einem deutschen Shopify-Shop? Welche WCAG-Kriterien sind in der EU-Durchsetzungspraxis besonders relevant?

Warum Overlay-Widgets keine BFSG-Lösung sind

Anbieter wie accessiBe und UserWay verkaufen sogenannte „Accessibility-Overlays" — ein JavaScript-Widget, das sich über jede Website legt und behauptet, sie „barrierefrei" zu machen. Die Accessibility-Community (echte, blinde Nutzer, Screenreader- Experten, die WebAIM-Community) hat diesen Ansatz wiederholt als unzureichend bezeichnet:

• Overlays ändern keinen Source-Code — sie kaschieren Probleme clientseitig. Bei deaktiviertem JavaScript ist die Seite wieder nicht zugänglich.
• Screenreader-Nutzer berichten von doppelten Ankündigungen, da das Overlay eigene ARIA-Labels setzt, die mit den vorhandenen konkurrieren.
• Die Overlay Fact Sheet (unterzeichnet von 1000+ Accessibility-Experten) stellt klar: Overlays sind nicht BFSG/WCAG-konform.

Unser Ansatz: den tatsächlichen Source-Code-Fix finden und vorschlagen. Das ist langsamer, aber der einzige Weg, der nachhaltig funktioniert.

Die KI-Fix-Schicht: Claude Haiku

Für konkrete Fix-Vorschläge nutzen wir Claude Haiku 4.5. Warum Haiku und nicht GPT-4 oder Claude Sonnet? Drei Gründe:

1. Kosten: Haiku ist ungefähr 1/10 so teuer wie Sonnet bei vergleichbarer Qualität für kurze, gut strukturierte Prompts. Bei 10.000 Scans pro Monat macht das 90% Einsparung.
2. Latenz:Haiku antwortet in <2 Sekunden, was wichtig ist wenn wir 50 Fix-Vorschläge für einen Scan parallel generieren.
3. Datenschutz / EU-Routing: Anthropic bietet EU-Datenresidenz, Claude-Responses werden nicht zum Training verwendet. Für DSGVO-relevante Workloads ist das ein klares Plus gegenüber OpenAI.

Was offen ist

Automatisierte Tests decken ca. 30–40% aller WCAG-2.1-Kriterien ab. Keyboard-Traps, komplexe Screenreader-Interaktionen und kognitive Zugänglichkeit bleiben manuellen Audits vorbehalten. Deshalb empfehlen wir Kunden mit hohem Risiko-Profil zusätzlich eine BITV-Prüfstellen-Zertifizierung — unser Scanner ersetzt die nicht, aber er reduziert den Aufwand bei einer Prüfstelle von Wochen auf Tage.

Open-Source-Beitrag

Wir haben kleinere Patches zu axe-core beigetragen (deutsche Übersetzungen, BFSG-spezifische Rule-Tags) und planen, unser eigenes Scoring-Modell (welche Violation = welche Bußgeld-Kategorie im deutschen Kontext) dieses Jahr zu veröffentlichen. Dem Ecosystem geben, was man nimmt — das ist die Grundregel nachhaltiger Open-Source-Arbeit.

Diskussion: Fragen, Kritik, Verbesserungsvorschläge? Schreiben Sie uns an kontakt@compli24.de. Technik-Deep-Dives wie diesen planen wir quartalsweise.