IT-SICHERHEIT • BFSG-HAFTUNG • SUPPLY-CHAIN-SCHUTZ

Klartext: Warum Baukästen und „Overlay-Tools“ ein Sicherheits- und Haftungsrisiko sind.

Während Angriffe auf vernetzte Systeme und mittelständische Betriebe täglich zunehmen, holen sich Tausende Unternehmen über aufgeblähte Plugin-Baukästen und fremde „Barrierefreiheits-Widgets“ unwissentlich offene Scheunentore ins eigene Haus – und haften im Ernstfall trotzdem ganz allein.

„Wer dem falschen Schildschmied misstraut, muss nur die Rückseite des Pergaments lesen – dort steht in winziger Schrift, dass das Eisen beim ersten Hieb bricht.“

TEIL 1: DIE UNSICHTBARE ANGRIFFSFLÄCHE

Jedes fremde Skript ist ein offenes Tor in Ihr System

Echte Barrierefreiheit und echte IT-Sicherheit gehören untrennbar zusammen. Die meisten Unternehmen ahnen nicht, welches Risiko sie sich mit typischen Agentur-Baukästen und sogenannten „1-Klick-Overlays“ einkaufen:

Das Overlay als offenes Scheunentor (Supply-Chain-Angriff)

Wer sich ein Barrierefreiheits-Overlay (das kleine „Männchen-Icon“ am Bildschirmrand) einbaut, bindet ein externes JavaScript von einem fremden Server direkt in seine Website ein. Dieses Skript besitzt vollen Lese- und Schreibzugriff auf die gesamte Seite – inklusive aller Daten, die Kunden, Mandanten oder Patienten in Formulare eintippen. Wird der Server des Overlay-Anbieters kompromittiert, schleust das Skript mit einem Schlag Schadcode auf Tausende Kundenwebseiten gleichzeitig ein.

Das WordPress-Plugin-Desaster

Eine typische Standard-Agenturseite besteht aus einem schweren Theme-Baukasten und 20 bis 30 zusammengewürfelten Plugins völlig unterschiedlicher Drittentwickler. Jedes einzelne Plugin ist eine potenzielle Sicherheitslücke. Wird im Praxis- oder Betriebsalltag nur zwei Wochen lang ein kritisches Update übersehen, übernehmen automatisierte Bots die Seite, kapern den Mailserver oder nutzen die Website als Sprungbrett.

Reines HTML, CSS & Vanilla JS: Null Angriffsfläche

Was nicht existiert, kann nicht gehackt werden. Auf unseren handgeschriebenen Seiten gibt es keine verwundbare SQL-Datenbank im Hintergrund, kein offenes /wp-admin-Login-Tor für Brute-Force-Attacken und keine 30 fremden Plugins, die heimlich Daten abgreifen. Auf dem gehärteten Linux-Server liegen ausschließlich statische, ultraschnelle Dateien.

SYSTEMVERGLEICH AUF EINEN BLICK

Baukasten & Overlay-Fassade vs. Confirmation Bias Architektur

Typische Baukasten- & Overlay-Seite	Handgeschriebene Seite von Confirmation Bias
✗ Fremde Skripte lesen live mit: Volles Sicherheits- und Datenschutzrisiko durch nachgeladenen Fremdcode von Drittservern.	✓ 100 % autarker Code: Keine externen Abhängigkeiten, keine fremden Tracker, volle DSGVO-Sicherheit ohne Cookie-Banner-Zwang.
✗ Dauer-Baustelle durch Plugin-Updates: Ständige Gefahr durch Sicherheitslücken in Datenbanken, Themes und Drittanbieter-Erweiterungen.	✓ Gehärtetes Fundament ohne Datenbank-Ballast: Reines HTML, CSS und eigenes JS – wartungsarm, extrem schnell und immun gegen SQL-Injection.
✗ Schein-Barrierefreiheit & Abmahnrisiko: Overlay-Widgets erfüllen weder das BFSG noch die EN 301 549 v4.1.1 und stören echte Screenreader massiv.	✓ Echte Barrierefreiheit im Quellcode: Saubere Semantik, echte Tastaturführung, Vorlese-Funktion und Hochkontrast direkt ab Zeile 1.

TEIL 2: DIE HAFTUNGSFALLE IM KLEINGEDRUCKTEN

Warum Sie trotz Overlay-Abo vor dem Gesetz ganz allein haften

Viele Anbieter von Overlay-Tools werben aggressiv mit „100 % BFSG-Konformität per Mausklick“. Ein Blick in deren eigene Allgemeine Geschäftsbedingungen (AGB) offenbart jedoch das genaue Gegenteil: Dort schließen diese Anbieter regelmäßig jede Garantie und Haftung für die tatsächliche gesetzliche Barrierefreiheit ausdrücklich aus.

Im Klartext bedeutet das: Sie zahlen Monat für Monat Lizenzgebühren für ein fremdes Skript, tragen das volle IT-Sicherheitsrisiko auf Ihrer Seite – und haften bei einer Prüfung durch die Marktüberwachungsbehörde oder einer Abmahnung nach dem Barrierefreiheitsstärkungsgesetz (BFSG) trotzdem zu 100 % selbst.

NEUER EU-MASSSTAB SEIT SEPTEMBER 2026 • EN 301 549 v4.1.1 & WCAG 2.2

Warum 99 % aller Baukästen und Overlays am neuen September-2026-Standard scheitern

Mit der aktualisierten europäischen Norm EN 301 549 (v4.1.1 vom September 2026) und der verbindlichen Umstellung auf WCAG 2.2 haben sich die Prüfregeln für das Barrierefreiheitsstärkungsgesetz (BFSG) spürbar verschärft. Während herkömmliche Agenturen noch mit veralteten Schablonen arbeiten, ist unsere Architektur bereits vollständig auf die neuen Pflichtkriterien gehärtet:

Strenges Verdeckungsverbot (Focus Not Obscured)

Wenn ein Nutzer per Tab-Taste durch eine Seite navigiert, darf das fokussierte Element niemals durch feste Header, Cookie-Banner, Chat-Widgets oder aufpoppende Browser-Übersetzer verdeckt werden. Unsere Seiten regeln dies nativ im CSS-Fundament.

Präzise Treffflächen (44 × 44 Pixel) & Betriebssystem-Signale

Für Menschen mit Tremor oder motorischen Einschränkungen garantieren wir mindestens 44 × 44 Pixel große Bedienflächen. Zudem erkennt unser Code automatisch Schutzsignale des Betriebssystems wie reduzierte Bewegung (prefers-reduced-motion) und nativen System-Kontrast (forced-colors).

Intelligente Sprach-Weiche & Screenreader-Ansagepult

Unkontrollierte Browser-Zwangspopups zerstören oft barrierefreie ARIA-Strukturen und verdecken das Menü. Unser Smart-Translate-Schutz unterdrückt störende Übersetzungs-Popups bei allen bereits handübersetzten Sprachen, lässt den Browser-Übersetzer für internationale Gäste anderer Muttersprachen aber gezielt offen – begleitet von einem unsichtbaren Live-Ansagepult (aria-live) für blinde Nutzer.

Fazit: Wer heute in eine Website investiert, sollte keine Architektur von gestern kaufen – sondern den Standard, der für die kommenden Jahre Gesetz ist.