Barrierefreiheit.KI-gesteuert.BFSG-konform.

Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt die EU-Richtlinie European Accessibility Act in deutsches Recht um. Seit dem 28. Juni 2025 müssen alle digitalen Produkte und Dienstleistungen – darunter Websites, Online-Shops, Banking-Apps und E-Book-Reader – barrierefrei sein. Betroffen sind Hersteller, Händler und Dienstleister mit mehr als 10 Beschäftigten oder über 2 Millionen Euro Jahresumsatz. Verstöße können mit Bußgeldern bis 100.000 Euro und Abmahnungen geahndet werden.

Die BFSG-Pflicht gilt seit dem 28. Juni 2025 für alle neuen digitalen Produkte und Dienstleistungen. Bestehende Produkte, die vor diesem Stichtag auf dem Markt waren, haben eine Übergangsfrist bis 28. Juni 2030. Wichtig: Websites und Apps gelten als Dienstleistungen – und für diese gilt keine Übergangsfrist. Das bedeutet, Ihre Website muss bereits jetzt barrierefrei sein.

Die Marktüberwachungsbehörden der Länder können Bußgelder bis zu 100.000 Euro verhängen und Produkte vom Markt nehmen. Zusätzlich drohen wettbewerbsrechtliche Abmahnungen durch Mitbewerber oder Verbraucherschutzverbände. Seit Inkrafttreten des BFSG steigt die Zahl der Beschwerden und Prüfungen stetig. Eine dokumentierte Compliance-Strategie mit regelmäßigen Audits ist deshalb unverzichtbar.

Der European Accessibility Act (EAA) ist die EU-Richtlinie, das BFSG die deutsche Umsetzung. Beide verweisen auf die harmonisierte Norm EN 301 549, die wiederum die Web Content Accessibility Guidelines (WCAG) als technischen Standard referenziert. In der Praxis bedeutet das: Wer WCAG 2.1 Level AA erfüllt, erfüllt auch die technischen Anforderungen des BFSG. Wir empfehlen direkt WCAG 2.2 AA als Ziel, da dieser Standard neun zusätzliche Kriterien umfasst.

Kleinstunternehmen mit weniger als 10 Beschäftigten und maximal 2 Millionen Euro Jahresumsatz sind vom BFSG ausgenommen – allerdings nur für Dienstleistungen. Falls Sie digitale Produkte herstellen oder vertreiben, greift die Ausnahme nicht. Unabhängig davon empfehlen wir Barrierefreiheit: Sie erreichen mehr Nutzer, verbessern die SEO und minimieren das Abmahnrisiko.

WCAG definiert drei Konformitätsstufen: Level A ist das absolute Minimum und deckt grundlegende Barrieren ab. Level AA ist der gesetzlich geforderte Standard – hier fallen Farbkontraste, Tastaturzugänglichkeit und Textgrößen-Anpassung hinein. Level AAA ist die höchste Stufe für maximale Zugänglichkeit, aber in der Praxis selten vollständig umsetzbar. Unser Ziel für jede Website: mindestens WCAG 2.2 Level AA.

Laut dem WebAIM Million Report 2025 sind die Top-6-Fehler: Zu geringer Farbkontrast (81 % aller Websites), fehlende Alt-Texte für Bilder (54 %), fehlende Formular-Labels (48 %), leere Links ohne erkennbaren Zweck (44 %), fehlende Dokumentsprache (28 %) und leere Buttons (26 %). Die gute Nachricht: All diese Issues können automatisiert erkannt und großteils per KI gefixt werden.

WCAG 2.2 (veröffentlicht Oktober 2023) ergänzt neun neue Erfolgskriterien: Focus Not Obscured (2.4.11/12), Dragging Movements (2.5.7), Target Size Minimum (2.5.8), Consistent Help (3.2.6), Accessible Authentication (3.3.7/8) und Redundant Entry (3.3.9). Diese adressieren besonders Touch-Interfaces, kognitive Einschränkungen und mobile Nutzung. Wir prüfen Ihre Website direkt gegen den aktuellsten Standard.

WAI-ARIA wird benötigt, wenn natives HTML für dynamische UI-Komponenten nicht ausreicht – zum Beispiel für Custom-Dropdowns, Tabs, Modals, Accordion-Menüs, Slider oder Live-Benachrichtigungen. Die erste Regel von ARIA lautet: Natives HTML bevorzugen. Nur wenn kein passendes HTML-Element existiert, werden ARIA-Rollen, Zustände und Eigenschaften ergänzt. Falsch eingesetztes ARIA schadet mehr als es nützt.

EN 301 549 ist die harmonisierte europäische Norm für ICT-Barrierefreiheit und die technische Grundlage des BFSG. Sie referenziert WCAG für Webinhalte, enthält aber zusätzliche Anforderungen für Software, Dokumente, Hardware und Echtzeit-Kommunikation. Wenn Ihre digitale Präsenz mehr als eine Website umfasst – etwa Apps, PDFs oder Kundenportale – müssen alle Komponenten dieser Norm entsprechen.

Unsere KI-Systeme kombinieren drei Ansätze: Regelbasierte Scanner (axe-core, Pa11y) prüfen gegen über 100 WCAG-Regeln mit zero-false-positive-Garantie. Machine-Learning-Modelle analysieren Farbkontraste, Textstruktur und Seitenkomplexität. Computer-Vision (GPT-4 Vision) bewertet Bilder und generiert Alt-Texte. Die Ergebnisse werden nach Schweregrad, Auswirkung und Fix-Aufwand priorisiert.

Automatisierte KI-Tools erkennen zuverlässig 50 bis 80 Prozent aller WCAG-Verstöße: fehlende Alt-Texte, Kontrastfehler, fehlende Labels, ARIA-Probleme und Dokumentstruktur. Für die verbleibenden 20 bis 50 Prozent – etwa sinnvolle Tab-Reihenfolge, verständliche Fehlermeldungen oder logische Lesereihenfolge – ist manuelles Expert-Testing erforderlich. Unser Professional-Paket kombiniert beides.

GPT-4 Vision analysiert den visuellen Inhalt jedes Bildes und den umgebenden Seitenkontext – Überschriften, Bildunterschriften, Link-Ziele. Daraus generiert die KI eine prägnante Beschreibung, die den Zweck des Bildes vermittelt. Dekorative Bilder werden automatisch erkannt und mit leerem alt-Attribut markiert. Bei einem typischen Audit mit 500 Bildern sind die Alt-Texte in unter 30 Minuten fertig.

Accessibility-Overlays sind JavaScript-Widgets, die Barrieren oberflächlich maskieren, ohne den Quellcode zu ändern. Sie werden von Experten und der Accessibility-Community abgelehnt, da sie häufig neue Probleme schaffen und keine echte Compliance garantieren. Unser Ansatz: Wir fixen den tatsächlichen Code – HTML-Struktur, CSS-Kontraste, ARIA-Attribute – und beseitigen Barrieren an der Wurzel.

Ja – unsere KI-Remediation-Pipeline kann viele Issues automatisch beheben: Alt-Texte ergänzen, Farbkontraste anpassen, fehlende Labels hinzufügen, ARIA-Attribute korrigieren und Dokumentsprache setzen. Für komplexere Fixes wie Tastaturnavigation, semantische Strukturänderungen oder Custom-Komponenten erstellt die KI detaillierte Fix-Tickets mit Code-Snippets und Priorität.

Wir arbeiten mit einem Multi-Tool-Stack: axe DevTools für automatisierte WCAG-Tests mit Zero-False-Positive-Garantie, WAVE für visuelle Inline-Analyse, Lighthouse für Performance und Accessibility-Scoring, Pa11y für CI/CD-Integration, Accessibility Insights von Microsoft für manuelle Tests, und Custom KI-Agents für Alt-Text-Generierung und Screenreader-Simulation.

Schritt 1: Automatisierter Scan aller Seiten mit axe-core und Pa11y. Schritt 2: KI-Analyse von Bildern, Farben und Dokumentstruktur. Schritt 3: Manuelles Expert-Testing (im Professional-Paket) für Tastaturnavigation, Screenreader-Kompatibilität und kognitive Zugänglichkeit. Schritt 4: Priorisierter Report mit konkreten Fix-Empfehlungen. Schritt 5: Auf Wunsch KI-gestützte Remediation der erkannten Issues.

Ja – und wir empfehlen das ausdrücklich. Wir integrieren axe-core und Pa11y direkt in Ihren Build-Prozess (GitHub Actions, GitLab CI, Jenkins). Bei jedem Commit wird automatisch geprüft und Builds können bei kritischen Issues gestoppt werden. So verhindern Sie, dass neue Barrieren in die Produktion gelangen – Shift-Left-Accessibility für nachhaltige Compliance.

Wir testen mit NVDA (Windows), VoiceOver (macOS/iOS) und TalkBack (Android). Geprüft werden: Korrekte Vorlesereihenfolge, Überschriftenhierarchie, Link- und Button-Beschriftungen, Formular-Labels und Fehlermeldungen, ARIA-Live-Regionen für dynamische Inhalte, und die Navigierbarkeit durch Landmarks. Screenreader-Tests decken Barrieren auf, die kein automatisiertes Tool finden kann.

Unsere Empfehlung: Automatisierte CI/CD-Checks bei jedem Deploy, wöchentliche automatisierte Crawls der gesamten Website, quartalsweise manuelle Expert-Reviews, und einen umfassenden Re-Audit nach größeren Redesigns oder Feature-Releases. Das kontinuierliche Monitoring zwischen den Audits erkennt Regressions sofort.

Jedes Formularfeld braucht ein sichtbares Label (nicht nur Placeholder), das programmatisch verknüpft ist. Pflichtfelder müssen klar gekennzeichnet sein (nicht nur durch Farbe). Fehlermeldungen müssen spezifisch sein und das betroffene Feld identifizieren. Erfolgreiche Absendungen brauchen eine Bestätigung. Autofill-Attribute erleichtern die Eingabe. Unsere KI prüft all diese Kriterien automatisch.

Videos benötigen Untertitel (für gehörlose Nutzer), eine Audiodeskription (für blinde Nutzer) und ein Transkript. Der Videoplayer muss per Tastatur bedienbar sein. Automatisches Abspielen ist zu vermeiden. Blinkende Inhalte dürfen nicht mehr als dreimal pro Sekunde blinken (Epilepsie-Schutz). Wir prüfen Ihre Multimedia-Inhalte und empfehlen kosteneffiziente Lösungen für Untertitel und Transkripte.

Sehr wichtig. Screenreader-Nutzer navigieren primär über Überschriften. Eine korrekte Hierarchie (H1 → H2 → H3, ohne Sprünge) ist essentiell. Jede Seite braucht genau eine H1 als Hauptüberschrift. Überschriften dürfen nicht nur visuell, sondern müssen semantisch korrekt ausgezeichnet sein. Unsere KI prüft die gesamte Dokumentstruktur und erkennt falsche Hierarchien automatisch.

Skip-Links ermöglichen es Tastaturnutzern, wiederkehrende Bereiche wie Navigation und Header zu überspringen und direkt zum Hauptinhalt zu gelangen. WCAG 2.4.1 (Level A) fordert einen solchen Mechanismus. Ein Skip-Link wird als erstes fokussierbares Element platziert und ist typischerweise nur bei Tastaturfokus sichtbar. Die Implementierung dauert wenige Minuten und beseitigt eine häufige Level-A-Barriere.

Ja – das BFSG und EN 301 549 erstrecken sich auch auf digitale Dokumente. Barrierefreie PDFs benötigen: korrekte Tags-Struktur mit Überschriften, Alt-Texte für Bilder, eine definierte Lesereihenfolge, Dokumentsprache und aussagekräftige Link-Texte. Wir empfehlen, Informationen primär als HTML bereitzustellen und PDFs nur ergänzend anzubieten – oder PDF/UA-konforme Dokumente zu erzeugen.

Unser Monitoring umfasst: Automatisierte WCAG-Scans nach jedem Deploy, wöchentliche Crawls aller Seiten auf neue Issues, Echtzeit-Alerts bei Regressions per E-Mail und Slack, ein Trend-Dashboard mit Issue-Entwicklung über Zeit, und automatisierte Compliance-Reports für Stakeholder und Behörden. So stellen Sie sicher, dass Ihre Website dauerhaft barrierefrei bleibt.

Die Erklärung nach §13 BFSG muss enthalten: Den Konformitätsstatus (konform, teilweise konform, nicht konform), die referenzierte Norm (EN 301 549 / WCAG), eine Liste bekannter Einschränkungen mit Begründung und Zeitplan, den Feedback-Mechanismus für Nutzer, und den Verweis auf das behördliche Schlichtungsverfahren. Unsere KI generiert diese Erklärung automatisch und aktualisiert sie nach jedem Audit.

Typische Zeitrahmen: Kleine Website (bis 50 Seiten) erreicht Compliance in 2 bis 4 Wochen. Mittelgroße Projekte (E-Commerce mit 200+ Seiten) benötigen 4 bis 8 Wochen. Enterprise-Projekte (Multi-Domain, komplexe Webanwendungen) planen wir mit 8 bis 16 Wochen. Kritische Level-A-Issues werden in der ersten Woche adressiert, damit die grundlegende Zugänglichkeit schnellstmöglich hergestellt ist.

In den allermeisten Fällen nicht. Barrierefreiheit betrifft vor allem die technische Umsetzung: HTML-Semantik, ARIA-Attribute, Farbkontraste und Tastaturnavigation. Optisch reichen oft minimale Anpassungen aus – beispielsweise eine 10 bis 15 Prozent dunklere Textfarbe für ausreichend Kontrast. Wir zeigen Ihnen Vorher/Nachher-Vergleiche, damit Sie jede visuelle Änderung vor der Umsetzung freigeben können.

Unser Dashboard zeigt: Gesamtzahl der Issues nach WCAG-Level (A/AA/AAA), Issue-Trend über Zeit, betroffene Seitenzahl pro Issue-Typ, Top-10-Issues nach Häufigkeit, axe- und Lighthouse-Accessibility-Score, Fix-Rate und durchschnittliche Fix-Dauer, Compliance-Prozentsatz pro WCAG-Kategorie, und Regression-Alerts. Alle Daten sind als PDF oder CSV exportierbar.