Barrierefreiheit im Web: Was das BFSG für dich als Entwickler bedeutet

Barrierefreiheit war für die meisten deutschen Webprojekte jahrelang ein Thema, das man “auch noch machen könnte”. Seit dem Barrierefreiheitsstärkungsgesetz ist es für einen Teil der Projekte eine Pflicht mit Behördenaufsicht — und für dich als Entwickler eine Frage, die dir Kunden inzwischen im Erstgespräch stellen.

Vorab die übliche Einordnung: Ich bin Entwickler, kein Anwalt. Das hier ist die technische und praktische Sicht auf ein Gesetz, dessen Detailauslegung im Zweifel juristisch geklärt gehört.

Wen es betrifft — und wen nicht

Das BFSG setzt den European Accessibility Act in deutsches Recht um und gilt seit dem 28. Juni 2025. Es betrifft nicht pauschal jede Website, sondern bestimmte Produkte und Dienstleistungen im Verkehr mit Verbraucherinnen und Verbrauchern. Für Webentwickler ist vor allem der Bereich elektronischer Geschäftsverkehr relevant: Wenn über die Seite ein Vertragsabschluss mit Endkunden möglich ist — Shop, Buchung, Ticketverkauf, Online-Abschluss von Verträgen — fällt sie in den Anwendungsbereich.

Wichtig ist die Ausnahme für Kleinstunternehmen bei Dienstleistungen: Betriebe unterhalb der Kleinstunternehmensschwelle sind bei Dienstleistungen ausgenommen. Für Produkte gilt diese Ausnahme nicht. Die reine Firmen-Visitenkartenseite ohne Vertragsabschluss ist ebenfalls nicht automatisch erfasst. Öffentliche Stellen wiederum unterliegen ohnehin schon länger eigenen Regeln über die Barrierefreie-Informationstechnik-Verordnung.

In der Praxis heißt das für Agenturprojekte: Bei jedem Kundenprojekt mit Verkaufs- oder Buchungsfunktion gehört die Frage geklärt, ob das BFSG greift — und wenn ja, ob der Kunde die Ausnahme in Anspruch nehmen kann. Das ist eine Kundenentscheidung mit rechtlicher Tragweite, keine, die du nebenbei für ihn triffst. Deine Aufgabe ist, sie überhaupt zu stellen und schriftlich festzuhalten.

Der technische Maßstab

Hinter dem Gesetz steht die europäische Norm EN 301 549, die für Webinhalte im Kern auf die Web Content Accessibility Guidelines verweist, Konformitätsstufe AA. Das ist die gute Nachricht: Der Maßstab ist kein deutsches Sonderkonstrukt, sondern der internationale Standard, für den es seit Jahren Werkzeuge, Dokumentation und Community-Wissen gibt.

Die WCAG sind entlang von vier Prinzipien aufgebaut: Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein. Das klingt abstrakt, wird aber sehr schnell konkret, wenn man es auf einen Checkout-Prozess anwendet.

Die Fehler, die in fast jedem Projekt stecken

Aus den Projekten, die ich mir angeschaut habe, wiederholen sich dieselben Punkte — und die meisten davon sind keine Design-, sondern Umsetzungsfehler:

• Kontraste. Hellgraue Fließtexte auf Weiß sind seit Jahren Designmode und fallen fast immer durch. Genauso Platzhaltertexte in Formularen, die als Beschriftung missbraucht werden, und deaktivierte Buttons mit kaum sichtbarem Text.
• Formulare ohne echte Labels. Ein Eingabefeld braucht ein programmatisch verknüpftes Label, nicht nur ein visuell danebenstehendes Wort. Fehlermeldungen müssen dem Feld zugeordnet und für Screenreader ankündbar sein — eine rote Umrandung allein ist keine Fehlermeldung.
• Tastaturbedienung. Alles, was mit der Maus geht, muss mit der Tastatur gehen. Modale Dialoge, die den Fokus nicht einfangen, Dropdowns aus reinen div-Elementen, Karussells ohne Steuerung: Das sind die Klassiker. Und der Fokus muss sichtbar sein — den Fokusring pauschal wegzustylen ist einer der schädlichsten Einzeiler, die in CSS-Dateien stehen.
• Struktur. Überschriftenebenen als Designwerkzeug statt als Gliederung, Landmarken, die fehlen, Listen, die als Absätze gebaut sind. Screenreader-Nutzer navigieren über genau diese Struktur.
• Bilder und Icons. Alternativtexte, die den Dateinamen wiederholen, sind schlimmer als keine. Dekorative Bilder gehören leer ausgezeichnet, informative brauchen eine Beschreibung dessen, was sie aussagen, nicht dessen, was darauf zu sehen ist.
• Dynamische Inhalte. Wenn sich nach einem Klick etwas ändert, ohne dass die Seite neu lädt, erfährt ein Screenreader das nur, wenn du es ihm sagst. Warenkorb-Zähler, Filterergebnisse, Ladezustände.

Erklärung zur Barrierefreiheit und Feedback-Kanal

Was in technischen Artikeln oft untergeht: Das Gesetz verlangt nicht nur eine barrierefreie Umsetzung, sondern auch Informationen darüber. Für betroffene Dienstleistungen gehören Angaben zur Barrierefreiheit in die allgemeinen Geschäftsbedingungen oder an eine vergleichbar auffindbare Stelle, und Nutzer müssen einen Weg haben, Mängel zu melden.

Für dich als Umsetzer heißt das: Plane eine eigene Seite dafür ein, verlinkt aus dem Fußbereich, mit einer Beschreibung des Stands, den bekannten Einschränkungen und einer erreichbaren Kontaktadresse. Bekannte Einschränkungen ehrlich zu benennen ist dabei kein Eingeständnis von Pfusch — es ist bei umfangreichen Anwendungen der Normalfall und deutlich besser als eine Behauptung vollständiger Konformität, die bei der ersten Prüfung fällt.

Für die Aufsicht ist in Deutschland die Marktüberwachungsstelle der Länder für die Barrierefreiheit von Produkten und Dienstleistungen zuständig. Sie wird typischerweise auf Hinweise hin tätig — der wahrscheinlichste Auslöser ist also nicht eine Routineprüfung, sondern ein Nutzer, der nicht weiterkam und sich beschwert hat. Genau deshalb ist der Feedback-Kanal nicht nur Pflicht, sondern auch im eigenen Interesse: Es ist deutlich angenehmer, wenn eine Beschwerde bei dir landet statt bei einer Behörde.

Overlays lösen das Problem nicht

Es gibt Anbieter, die ein Skript versprechen, das eine Seite per Klick barrierefrei macht. Diese Overlay-Werkzeuge legen eine Bedienleiste über die Seite und versuchen, Mängel zur Laufzeit zu reparieren. In der Barrierefreiheits-Community werden sie überwiegend abgelehnt, und zwar von den Menschen, für die sie angeblich gedacht sind: Sie kollidieren häufig mit den Hilfsmitteln, die Nutzer ohnehin schon eingerichtet haben, und sie beheben strukturelle Mängel nicht.

Wenn dich ein Kunde darauf anspricht, ist die ehrliche Antwort: Ein Overlay ersetzt keine ordentliche Umsetzung. Es kaschiert bestenfalls, und im schlechtesten Fall verschlechtert es die Bedienbarkeit für genau die Zielgruppe.

Wie du das im Alltag verankerst

Automatisierte Prüfwerkzeuge finden nach verbreiteter Einschätzung nur einen Teil der Probleme — aber diesen Teil finden sie zuverlässig und billig. Deshalb gehört ein Accessibility-Linter in die Entwicklungsumgebung und ein automatisierter Check in die Pipeline. Damit fängst du Kontrastfehler, fehlende Alternativtexte und kaputte Formularbeschriftungen ab, bevor sie ins Projekt einsickern.

Den Rest findest du nur manuell, und das geht schneller, als die meisten glauben. Leg die Maus weg und bediene die wichtigsten Abläufe deiner Seite mit Tabulator und Enter. Schalte einmal einen Screenreader ein — auf dem Mac ist VoiceOver eingebaut, unter Windows ist NVDA kostenlos — und versuche, ein Formular abzuschicken. Diese zwanzig Minuten sagen dir mehr über die Bedienbarkeit deiner Anwendung als jeder Report.

Der wirtschaftlich wichtigste Punkt zum Schluss: Barrierefreiheit nachträglich einzubauen ist deutlich teurer, als sie von Anfang an mitzudenken, weil sie Komponenten, Markup und teils das Design betrifft. Wenn du Kundenprojekte kalkulierst, ist sie deshalb kein Zusatzposten am Ende, sondern eine Eigenschaft der Bauweise. Und ganz nebenbei: Sauberes semantisches Markup, sichtbarer Fokus und funktionierende Formulare machen eine Seite für alle besser — nicht nur für die Gruppe, wegen der ein Gesetz existiert.

Wenn du wissen willst, wie andere das in ihren Projekten geregelt haben, ohne es zum Riesenprojekt zu machen: Im Discord der Community läuft das Thema regelmäßig.