BFSG nach dem Start: Warum Barrierefreiheit jetzt ein laufender Website-Check ist

Barrierefreiheit ist kein hübsches Extra mehr, das man nach dem Relaunch noch „irgendwann“ einplant. Seit dem 28. Juni 2025 gelten in Deutschland die Regelungen des Barrierefreiheitsstärkungsgesetzes für bestimmte Produkte und Dienstleistungen. Dahinter steht die europäische Richtlinie 2019/882, besser bekannt als European Accessibility Act.

Für Website-Betreiber, Agenturen und kleine Produktteams ist die wichtigste Konsequenz: Accessibility ist kein einmaliger Design-Task. Sie ist ein laufender Qualitätsprozess.

Wen betrifft das Thema praktisch?

Nicht jede Website ist automatisch in gleichem Umfang betroffen. Besonders relevant wird Barrierefreiheit aber bei digitalen Dienstleistungen, E-Commerce, Buchungsstrecken, Kundenportalen, Apps, Self-Service-Bereichen und digitalen Verkaufsprozessen.

Auch wenn ein Projekt nicht eindeutig in den Pflichtbereich fällt, ist ein Accessibility-Check sinnvoll. Denn viele Probleme sind keine Spezialfälle, sondern normale UX-Schäden:

• Buttons ohne klare Beschriftung,
• Formulare ohne verständliche Fehlermeldungen,
• zu geringer Farbkontrast,
• fehlende Tastaturbedienbarkeit,
• unlogische Überschriftenstruktur,
• fehlende Alternativtexte,
• Cookie-Banner, die per Tastatur kaum bedienbar sind.

Das sind keine „Nischenthemen“. Das sind Conversion-Killer mit Rechtsrisiko im Trenchcoat.

Warum Accessibility in die Wartung gehört

Viele Websites sind beim Launch halbwegs sauber und driften danach auseinander. Neue Landingpages, neue Tracking-Skripte, neue Cookie-Tools, neue Formulare, neue Plugins, neue Pop-ups — und plötzlich ist die Bedienbarkeit wieder kaputt.

Deshalb sollte Barrierefreiheit in drei Prozesse eingebaut werden:

1. Design Review: Kontraste, Fokuszustände, Schriftgrößen, Struktur und mobile Bedienung prüfen.
2. Development QA: Tastaturbedienung, Semantik, Labels, Fehlermeldungen und ARIA nur dort einsetzen, wo es wirklich hilft.
3. Content Pflege: Überschriften, Linktexte, Alternativtexte und PDF-Dokumente nicht vergessen.

Gerade kleine Teams müssen dafür kein riesiges Accessibility-Programm starten. Ein wiederholbarer Check reicht oft als Anfang.

Was Website-Pflichtencheck dabei prüfen kann

Ein technischer Website-Check kann Accessibility nicht vollständig juristisch bewerten. Aber er kann typische technische Risiken sichtbar machen:

• Gibt es klare Überschriftenhierarchien?
• Haben Formulare Labels und verständliche Fehlermeldungen?
• Sind interaktive Elemente per Tastatur erreichbar?
• Sind Fokuszustände sichtbar?
• Sind Kontrastprobleme erkennbar?
• Sind Cookie-Banner und Consent-Flows bedienbar?
• Werden Bilder sinnvoll mit Alternativtexten gepflegt?
• Gibt es PDF- oder Download-Inhalte, die zusätzlich geprüft werden sollten?

Das Ergebnis ist kein Zertifikat. Es ist eine Arbeitsgrundlage. Und genau die fehlt vielen Projekten.

Der beste Start: kleine, feste Checkliste

Für kleine Unternehmen und Agenturen lohnt sich ein pragmatischer Rhythmus:

• vor jedem Relaunch,
• nach größeren Designänderungen,
• nach Austausch von Cookie- oder Tracking-Tools,
• nach neuen Formularen oder Checkout-Schritten,
• quartalsweise bei aktiven Websites.

Das klingt weniger glamourös als ein großes Accessibility-Audit. Aber es verhindert, dass Probleme monatelang unbemerkt wachsen.

Fazit

Das BFSG macht digitale Barrierefreiheit sichtbarer. Für Website-Teams ist die praktische Antwort nicht Panik, sondern Prozess: regelmäßig prüfen, dokumentieren, verbessern und Änderungen nicht blind deployen.

Barrierefreiheit ist gute Technik, bessere UX und sauberere Wartung in einem Paket. Oder weniger trocken: Wenn die Website nur für Menschen funktioniert, die mit Maus, perfektem Sehvermögen und göttlicher Geduld geboren wurden, ist sie nicht fertig.

Quellen

• European Commission: European Accessibility Act
• Directive (EU) 2019/882 on accessibility requirements for products and services
• BMAS: Barrierefreiheitsstärkungsgesetz

Hinweis: Dieser Beitrag ist eine technische Einordnung und keine Rechtsberatung.