--- title: "Ein Jahr BFSG: Barrierefreiheit als Qualitätsmerkmal" lang: de type: blog canonical: https://www.arocom.de/blog/barrierefreiheit-bfsg-praxis alternate: https://www.arocom.de/en/blog/bfsg-accessibility-practice author: "Axel Roth" published: 2026-02-17 --- # Ein Jahr BFSG: Barrierefreiheit als Qualitätsmerkmal Ein Jahr nach Inkrafttreten der BFSG-Pflicht für private Unternehmen zeigt sich in unseren Projekten: Wer Barrierefreiheit als reine Compliance-Checkliste behandelt, zahlt doppelt. Wer sie als Qualitätsmerkmal versteht, gewinnt bessere Usability für alle Nutzer, robusteres HTML, bessere SEO/GEO-Signale und Rechtssicherheit als Nebeneffekt. Die wirksamsten ersten Schritte: semantisches HTML, Tastaturbedienbarkeit, Kontraste und gepflegte Alt-Texte, messbar mit automatisierten Tests im CI. Für den Einstieg hat sich ein 30-Tage-Plan bewährt: Kernstrecken prüfen, Quick Wins umsetzen, Komponenten nach Reichweite priorisieren, Checks automatisieren. ## Ein Jahr BFSG: Barrierefreiheit als Qualitätsmerkmal, nicht als Checkliste Seit Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz auch für viele private Unternehmen. Die erste Reaktion, die wir beobachtet haben, war dieselbe wie bei der DSGVO: Panik, Checklisten, Overlay-Anbieter mit Hundert-Prozent-Versprechen. Ein Jahr und mehrere Accessibility-Projekte später können wir sagen: Der Checklisten-Reflex führt in die Irre. Die Unternehmen, die es richtig angehen, bekommen mehr zurück als Rechtssicherheit. ## Barrierefreiheit ist Usability mit Rückenwind Die wirksamsten Accessibility-Maßnahmen sind zugleich allgemeine Qualitätsmaßnahmen. Eine klare Überschriften-Hierarchie hilft Screenreader-Nutzern und allen, die Seiten überfliegen. Ausreichende Kontraste helfen Menschen mit Sehbeeinträchtigung und jedem, der bei Sonne aufs Handy schaut. Tastaturbedienbarkeit hilft motorisch eingeschränkten Nutzern und Power-Usern. Verständliche Sprache hilft Menschen mit kognitiven Einschränkungen und euren Conversion-Raten. Es gibt einen weiteren Nutznießer, den 2026 niemand mehr ignorieren sollte: KI-Systeme. Semantisches HTML, beschriebene Bilder und klare Struktur sind genau das, was Sprachmodelle brauchen, um Inhalte korrekt zu erfassen. Barrierefreiheit und [GEO](https://www.arocom.de/blog/geo-sichtbarkeit-ki-suche) haben dieselbe technische Grundlage: ein Budget, doppelter Effekt. In Zahlen lässt sich das selten sauber isolieren, aber die Richtung ist in unseren Projekten konsistent: Nach Accessibility-Umbauten sinken Abbrüche in Formularstrecken, und Support-Anfragen der Art "ich finde den Absenden-Knopf nicht" verschwinden. Niemand beschwert sich über eine Website, die sich leichter bedienen lässt. ## Learning 1: Overlays bestehen den Praxistest nicht Eingekaufte "Barrierefreiheits-Widgets" reparieren kein kaputtes HTML, sie legen nur eine Schicht darüber. In Tests mit echten Screenreader-Nutzern fallen sie regelmäßig durch, und als alleinige Maßnahme tragen sie rechtlich nicht. Wie das praktisch aussieht, hat uns ein Test in einem Kundenprojekt gezeigt (anonymisiert, der Verlauf ist typisch): Ein Mittelständler hatte ein Overlay lizenziert und hielt das Thema für erledigt. Wir haben die Website gemeinsam mit einem Screenreader-Nutzer durchgespielt. Das Widget kündigte sich selbst wortreich an, danach kam das eigentliche Problem. Im Kontaktformular waren die Felder nur als "Eingabe" hörbar, weil Labels fehlten, und der Absende-Button war per Tastatur nicht erreichbar. Der "Screenreader-Modus" des Overlays änderte daran nichts, denn die fehlende Information stand schlicht nicht im HTML. Der Nutzer brach nach vier Minuten ab. Diese vier Minuten erlebt jeder Betroffene, der dort anfragen will. Die Konsequenz in diesem Projekt: Das Overlay wurde gekündigt, und das Budget floss in die Reparatur von Formularen und Navigation. Das klingt nach mehr Aufwand, war aber die nachhaltigere Investition. Die Probleme sind seitdem behoben statt überdeckt, und die laufende Widget-Gebühr entfällt. ## Learning 2: Eine Komponente fixen heilt hundert Seiten Der Bestand ist meist größer als gedacht, der Aufwand kleiner. Die meisten Probleme konzentrieren sich auf wenige wiederverwendete Komponenten: Navigation, Formulare, Teaser-Karten. Wer komponentenbasiert arbeitet (in Drupal wie in jedem modernen Frontend), fixt eine Komponente und heilt hundert Seiten. Ein typisches Beispiel aus einem unserer Projekte ist die Hauptnavigation. Vorher: Menüpunkte als klickbare div-Elemente, Untermenüs nur per Maus-Hover erreichbar, kein sichtbarer Fokus. Für Tastaturnutzer war damit die halbe Website unerreichbar. Nachher: echte Buttons mit aria-expanded, Untermenüs per Tastatur auf- und zuklappbar, deutlicher Fokusring. Der Umbau betraf eine einzige Komponente und brauchte wenige Entwicklungstage. Wirksam war er auf mehreren hundert Seiten gleichzeitig, weil alle dieselbe Navigation einbinden. Nach demselben Muster folgten danach Formulare und Teaser-Karten. Wichtig für die Planung: Zählt nicht Seiten, sondern Komponenten. Ein Audit-Bericht mit zweitausend Einzelbefunden schrumpft oft auf 15 bis 20 Komponenten-Tickets zusammen, und erst diese Zahl taugt als Grundlage für eine Aufwandsschätzung. ## Learning 3: Ohne automatisierte Checks rutscht es zurück Accessibility-Checks gehören in die CI-Pipeline, sonst ist der Zustand sechs Releases später wieder dahin. Bei uns läuft axe-core in Playwright-Tests gegen repräsentative Seitentypen: Startseite, Leistungsseite, Artikel, Formularstrecke. Geprüft werden unter anderem Kontraste, Formular-Labels, Alt-Texte, ARIA-Rollen und die Überschriften-Hierarchie. So sieht ein Treffer aus: Eine neue Teaser-Karten-Variante kam mit heller Schrift auf hellem Hintergrund aus der Designabstimmung. Die Pipeline meldete den Kontrastfehler direkt am Pull Request, und der Fehler war vor dem Merge behoben. Ohne den Check wäre er Monate später in einem Audit aufgetaucht, verteilt über Dutzende Seiten. Die Einrichtung solcher Checks ist überschaubar: Bei uns liefen sie nach wenigen Tagen, seitdem kostet jede Prüfung nur Rechenzeit. Das automatisierte Drittel der WCAG-Kriterien fängt genau diese häufigen Regressionen ab. Für den Rest braucht es periodische manuelle Audits, idealerweise mit Menschen, die assistive Technologien täglich nutzen. ### Gilt das BFSG auch für unsere B2B-Website? Das BFSG zielt auf Verbraucherdienstleistungen; reine B2B-Angebote sind oft ausgenommen. Aber Vorsicht bei Mischformen: Ein Webshop, Buchungs- oder Bewerbungsstrecken können die Pflicht auslösen. Unabhängig von der Pflicht gilt das Qualitätsargument. Die Einordnung klären wir im Erstgespräch. ### Reicht ein automatisierter Test für den Nachweis? Nein. Automatisierte Tools prüfen je nach Kriterium nur 30–50 % der WCAG-Anforderungen. Für eine belastbare Bewertung braucht es manuelle Prüfung, idealerweise mit Beteiligung von Menschen, die assistive Technologien täglich nutzen. ### Was prüft die Marktüberwachung wirklich? Zuständig sind die Marktüberwachungsbehörden der Länder. Nach unserer Beobachtung und Berichten aus der Branche arbeiten sie bisher überwiegend anlassbezogen, also auf Beschwerden hin, und fordern zunächst Stellungnahme und Nachbesserung statt sofortiger Sanktionen. Das Gesetz gibt ihnen aber schärfere Mittel, bis hin zu Bußgeldern und im Extremfall der Untersagung der Dienstleistung. Verlasst euch zudem nicht allein auf die Behörden: Auch Verbände können Verstöße aufgreifen. Diese Einschätzung ersetzt keine Rechtsberatung. ### Müssen PDFs auch barrierefrei sein? Wenn ein PDF Teil einer Dienstleistung ist, die unter das BFSG fällt, etwa Vertragsbedingungen oder Produktinformationen in einer Bestellstrecke, gelten die Anforderungen auch dafür. Für reine Altbestände im Archiv gilt das in der Regel nicht; im Zweifel gehört die Abgrenzung in eine juristische Prüfung. Pragmatisch hat sich bewährt: neue, relevante Dokumente barrierefrei erstellen (Stichwort PDF/UA) und Inhalte, wo möglich, gleich als HTML-Seite statt als PDF anbieten. HTML ist leichter barrierefrei zu halten und nebenbei besser auffindbar. ### Was kostet der Einstieg realistisch? Ein fundiertes Audit einer mittelgroßen Unternehmenswebsite liegt im niedrigen fünfstelligen Bereich; die Behebung hängt vom Zustand der Komponenten ab. Deutlich teurer ist der umgekehrte Weg: Accessibility nachträglich in einen laufenden Relaunch zu pressen. ## Die ersten 30 Tage: ein pragmatischer Einstieg Wenn ihr heute startet und noch kein Audit hattet, hat sich in unseren Projekten diese Reihenfolge bewährt: - **Woche 1: Bestand sichten.** Nicht alle Seiten prüfen, sondern Seitentypen und Kernstrecken: Startseite, wichtigste Leistungsseite, Kontakt- oder Bestellstrecke. Ein automatisierter Scan plus ein manueller Durchgang nur mit der Tastatur zeigt die gravierendsten Hürden. - **Woche 2: Quick Wins umsetzen.** Formular-Labels, Alt-Texte für inhaltstragende Bilder, sichtbare Fokuszustände, Kontraste über zentrale Design-Variablen. Diese Punkte betreffen die meisten Nutzer und sind ohne Redesign machbar. - **Woche 3: Komponenten priorisieren.** Die verbleibenden Befunde den Komponenten zuordnen und nach Reichweite sortieren: Navigation und Formulare zuerst, selten genutzte Elemente später. - **Woche 4: Absichern.** Automatisierte Checks in die Deployment-Pipeline aufnehmen und, falls euer Angebot unter das BFSG fällt, die Barrierefreiheitserklärung aufsetzen. Fürs Budget als Größenordnung aus unseren Projekten: Das Audit liegt im niedrigen fünfstelligen Bereich, die Quick Wins meist darunter, der Komponentenumbau hängt vom Zustand des Frontends ab. Benennt außerdem von Anfang an eine verantwortliche Person, die Befunde priorisiert und Folgearbeiten einplant. Ohne klaren Besitzer bleibt das Thema nach Woche 4 wieder liegen. Der allererste Schritt kostet nichts: Legt die Maus weg und versucht, auf eurer eigenen Website nur mit der Tab-Taste eine Anfrage abzuschicken. Was ihr dabei erlebt, ist euer Startpunkt.