Barrierefreiheit nach BFSG und WCAG 2.2
Wir prüfen Ihre Anwendung automatisiert und manuell gegen WCAG 2.2 AA, sortieren die Befunde nach ihrer Wirkung auf Nutzer und beheben sie dort, wo sie entstehen: im Quellcode. Die Erfahrung dafür stammt unter anderem aus Komplify, einer Prüfplattform für BFSG und WCAG, die wir für die Prevision UG entwickelt haben.
Hintergrund
Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt den European Accessibility Act (Richtlinie (EU) 2019/882) um und gilt seit dem 28. Juni 2025. Erfasst sind Dienstleistungen, die nach diesem Datum für Verbraucher erbracht werden, darunter Dienstleistungen im elektronischen Geschäftsverkehr: Websites und Apps, über die Verbraucher elektronisch einen Vertrag abschließen, etwa Onlineshops, Buchungsstrecken oder Vertragsabschlüsse im Kundenportal. Dazu kommen unter anderem Bankdienstleistungen für Verbraucher, Telekommunikationsdienste und E-Books.
Die konkreten Anforderungen stehen in der Verordnung zum BFSG (BFSGV): Websites und mobile Anwendungen müssen wahrnehmbar, bedienbar, verständlich und robust sein, im elektronischen Geschäftsverkehr ausdrücklich auch Identifizierungs-, Authentifizierungs- und Zahlungsfunktionen. Für harmonisierte Normen, deren Fundstelle im Amtsblatt der EU veröffentlicht ist, gilt eine Konformitätsvermutung (§ 4 BFSG). Die EN 301 549 ist im September 2026 in Version 4.1.1 erschienen, verweist auf WCAG 2.2 und ordnet ihre Anforderungen erstmals dem European Accessibility Act zu; bis harmonisierte Normen im Amtsblatt bekannt gemacht sind, nennt die Bundesfachstelle Barrierefreiheit die EN 301 549 und die WCAG als maßgebliche Orientierung.
Kleinstunternehmen, die Dienstleistungen anbieten, sind ausgenommen. Die Marktüberwachungsstelle der Länder für die Barrierefreiheit von Produkten und Dienstleistungen (MLBF) in Magdeburg prüft anlassbezogen und in Stichproben, setzt Fristen zur Nachbesserung und kann das Angebot einer nicht konformen Dienstleistung als letztes Mittel untersagen. Diese Übersicht ersetzt keine Rechtsberatung.
Typische Ausgangslagen
Die meisten Befunde entstehen nicht durch fehlenden Willen, sondern durch Komponenten, die nie mit Tastatur oder Screenreader benutzt wurden.
Ein div mit Klick-Handler sieht aus wie ein Button, ist per Tastatur aber nicht erreichbar und wird vom Screenreader nicht als Schaltfläche angesagt. Selbst gebaute Dropdowns, Tabs und Datumsauswahlen sind eine häufige Quelle solcher Fehler.
Öffnet sich ein Modal, bleibt der Tastaturfokus oft auf der Seite dahinter oder landet nach dem Schließen im Nichts. Für Tastaturnutzer endet der Bestellvorgang an genau dieser Stelle.
Felder ohne verknüpftes Label, Pflichtangaben nur farblich markiert, Fehlermeldungen, die zwar erscheinen, aber nicht angesagt werden. Identifizierungs-, Authentifizierungs- und Zahlungsfunktionen nennt die BFSGV für den elektronischen Geschäftsverkehr ausdrücklich.
Ein Scanner erkennt, dass ein Alternativtext fehlt, aber nicht, ob ein vorhandener zum Bild passt. Ob die Fokusreihenfolge logisch ist, beurteilt nur ein Mensch.
Was wir entwickeln
Wir arbeiten an Ihrer Codebasis. Ein nachträglich eingebundenes Overlay-Skript kann fehlende Semantik oder falsche Fokusführung nicht zuverlässig reparieren, weil die Ursache im Quellcode liegt.
Automatische Prüfung mit axe-core und Verhaltensprüfungen im Browser, ergänzt um manuelle Tests mit Tastatur, Screenreader und Zoom. Jeder Befund nennt das WCAG-Kriterium, die betroffene Stelle, die Auswirkung und einen Lösungsweg.
Semantisches HTML, vollständige Tastaturbedienung, Fokusmanagement in Dialogen und Menüs, ausreichende Kontraste, beschriftete Formulare mit verständlichen Fehlermeldungen und ARIA dort, wo natives HTML nicht ausreicht.
Kritische Bausteine wie Dialog, Menü, Tabs, Combobox und Datumsauswahl bauen wir einmal sauber und ersetzen damit die fehlerhaften Varianten in der gesamten Anwendung.
Bei Neuentwicklungen gehört WCAG 2.2 AA zu den Abnahmekriterien jeder Komponente. So muss später keine Oberfläche nachgerüstet werden.
Sie erhalten eine Bestandsaufnahme, welche Nutzerwege nach welchen Kriterien geprüft wurden, was erfüllt ist und was offen bleibt. Die rechtliche Formulierung Ihrer Angaben liegt bei Ihnen und Ihrer Rechtsberatung.
Automatische Prüfungen laufen bei jedem Pull Request und schlagen an, wenn neuer Code bekannte Fehlerklassen wieder einführt.
Vorgehen
Wir richten die Arbeit an den Nutzerwegen aus, die für einen Vertragsabschluss zählen, nicht an der Zahl der Seiten.
Gemeinsam bestimmen wir die Strecken, auf die es ankommt: Registrierung, Login, Suche, Warenkorb, Bezahlung, Kontakt. Dazu kommen die Seitenvorlagen, aus denen der Rest der Anwendung besteht.
Ein Scan über die gesamte Anwendung findet die eindeutigen Fehler. Die manuelle Prüfung der kritischen Wege deckt den Rest ab: Tastaturbedienung, Fokus, Screenreader-Ausgabe und Darstellung bei 400 Prozent Zoom.
Zuerst kommt, was Nutzer vollständig blockiert, etwa ein nicht bedienbarer Bezahlschritt. Wir beheben Ursachen in gemeinsam genutzten Komponenten, damit eine Korrektur an vielen Stellen gleichzeitig wirkt.
Ein zweiter Prüfdurchlauf bestätigt die Korrekturen. Automatische Prüfungen in der CI und eine kurze Checkliste für neue Komponenten halten das erreichte Niveau in künftigen Releases.
Technologie
Maßstab ist WCAG 2.2 auf Stufe AA, auf die auch die aktuelle EN 301 549 verweist. Automatisch prüfen wir mit axe-core in einem Headless-Browser. In Komplify haben wir diese Grundlage um heuristische, verhaltensbasierte und seitenübergreifende Prüfungen erweitert, etwa für Tastaturfallen, Fokusreihenfolge und sichtbaren Fokus, und uneindeutige Treffer als Hinweis zur manuellen Prüfung statt als Verstoß gekennzeichnet.
Die Korrekturen setzen wir im Stack Ihrer Anwendung um, häufig React, Next.js und TypeScript. ARIA verwenden wir sparsam: Ein natives button-Element ist robuster als ein nachgebautes mit drei ARIA-Attributen.
Referenzen
Komplify ist das Produkt unseres Kunden Prevision UG, wir haben die Plattform einschließlich der Prüf-Engine entwickelt. Dabei haben wir genau gelernt, welche Fehler sich automatisch zuverlässig erkennen lassen und wo eine manuelle Prüfung unverzichtbar bleibt.
Insights
Barrierefreiheit
Die WebAIM-Million-Studie prüft jedes Jahr die Startseiten der eine Million meistbesuchten Websites. 2026 fällt das Ergebnis erstmals seit Jahren schlechter aus. Wir ordnen die Zahlen ein und zeigen, welche Fehler Sie zuerst beheben sollten.
Barrierefreiheit
Aktion Mensch und Google haben kurz vor dem Stichtag des BFSG die 65 meistbesuchten Onlineshops in Deutschland von Menschen mit Behinderung testen lassen. Nur 20 waren vollständig per Tastatur bedienbar. Wir zeigen, an welchen Stellen im Kaufprozess Kunden scheitern, was das Gesetz verlangt und wie die Marktüberwachung ein Jahr später arbeitet.
Häufige Fragen
Erfasst sind vor allem Dienstleistungen für Verbraucher, die nach dem 28. Juni 2025 erbracht werden, darunter Websites und Apps, über die Verbraucher einen Vertrag abschließen. Kleinstunternehmen mit weniger als zehn Beschäftigten und höchstens 2 Millionen Euro Jahresumsatz oder Jahresbilanzsumme sind bei Dienstleistungen ausgenommen. Ob Ihr konkretes Angebot erfasst ist, ist eine Rechtsfrage: Wir liefern die technische Bewertung, nicht die rechtliche.
Nein. Automatische Prüfungen finden eindeutige Fehler wie fehlende Beschriftungen oder zu geringe Kontraste zuverlässig. Viele WCAG-Kriterien lassen sich aber nur von Menschen beurteilen, etwa ob ein Alternativtext zum Bild passt oder ob die Fokusreihenfolge logisch ist. Deshalb kombinieren wir beides.
Nach § 14 BFSG und Anlage 3 beschreiben Sie Ihre Dienstleistung in barrierefreiem Format, erläutern, wie sie die Anforderungen erfüllt, und nennen die zuständige Marktüberwachungsbehörde. Die Angaben gehören in die AGB oder an eine andere deutlich wahrnehmbare Stelle. Wir liefern die technische Grundlage, die rechtliche Formulierung sollte Ihre Rechtsberatung prüfen.
Nein, wir zertifizieren nicht und beraten nicht rechtlich. Sie erhalten einen nachvollziehbaren Prüfbericht: welche Nutzerwege nach welchen WCAG-Kriterien geprüft wurden, was wir behoben haben und welche Punkte offen sind. Das ist eine belastbare Grundlage für Ihre Barrierefreiheitsinformation und für Rückfragen der Marktüberwachung.
Der Aufwand hängt vom Umfang der Anwendung, der Zahl der kritischen Nutzerwege, dem Zustand der vorhandenen Komponenten und Ihrem Technologie-Stack ab. Im kostenlosen 30-minütigen Erstgespräch ordnen wir ein, ob ein Audit, eine gezielte Nachbesserung oder der Neubau einzelner Komponenten sinnvoll ist. Danach erhalten Sie einen transparenten Vorschlag für Vorgehen, Meilensteine und Abrechnung.
Erstgespräch
Schicken Sie uns den Link zu Ihrer Anwendung oder beschreiben Sie die wichtigsten Nutzerwege. Im kostenlosen 30-Minuten-Gespräch mit den Gründern klären wir, wo die größten Barrieren liegen und wie wir sie im Code beheben. Auf Anfragen antworten wir innerhalb von 24 Stunden.
Weitere Leistungen
Interne Tools, Dashboards und SaaS-Produkte, die Ihre Prozesse abbilden, statt sie zu verbiegen. Konzipiert und programmiert von den Gründern selbst.
Mehr erfahrenGeschützte Portale für Kunden, Händler und Mitglieder: Bestellungen, Buchungen und Dokumente im Self-Service, mit klaren Rollen und Freigaben.
Mehr erfahrenAPI-Integrationen, ERP- und Buchhaltungsanbindungen, PDF-Importe und automatische Jobs, die Daten zuverlässig zwischen Ihren Systemen bewegen.
Mehr erfahrenBackend-Erfahrung aus der ePA, eine Terminplattform für ein Praxisnetz und Architekturen, die Art. 9 DSGVO und § 393 SGB V von Anfang an berücksichtigen.
Mehr erfahren
