Wann muss eine Website barrierefrei sein? Fristen, Pflichten und Praxis seit 2025

Kurz und klar: Dieser Guide erklärt, wann Websites in Deutschland barrierefrei sein müssen, welche Gesetze gelten (BGG, BITV 2.0, BFSG 2025), was WCAG 2.1 AA konkret bedeutet und wie Sie Ihr Webangebot möglichst rechtssicher und nutzbar aufstellen.

Einleitung: eine prägnante Übersicht

Eine Website muss barrierefrei sein, wenn sie zu einer öffentlichen Stelle gehört (BGG/BITV 2.0, bereits wirksam) oder wenn sie als private Online-Dienstleistung bzw. E?Commerce-Angebot ab 28. Juni 2025 unter das BFSG fällt. Maßstab ist in der Praxis WCAG 2.1 AA, ergänzt um eine Barrierefreiheitserklärung und einen Feedbackweg. Mobile Apps öffentlicher Stellen sind einbezogen. Für private Anbieter gibt es ab 2025 Pflichten und teils Übergänge, pauschale Ausnahmen für kleine Unternehmen sind eng begrenzt und müssen begründet werden.¹

Was bedeutet Barrierefreiheit im Web in Deutschland?

Barrierefreiheit im Web heißt, dass digitale Inhalte für möglichst viele Menschen – einschließlich Personen mit Behinderungen – ohne fremde Hilfe nutzbar sind. In Deutschland bilden das Behindertengleichstellungsgesetz (BGG), die Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) und ab 2025 das Barrierefreiheitsstärkungsgesetz (BFSG) den rechtlichen Rahmen. In simple terms: WCAG 2.1 AA ist der technische Maßstab, an dem sich Websites und Apps ausrichten.

Warum ist das relevant? Wer barrierefrei gestaltet, reduziert Hürden in Navigation, Kontrast, Struktur und Formulardesign und erreicht mehr Kundschaft. Viele Teams fragen sich, ob Barrierefreiheit nur Pflicht ist oder auch wirtschaftlich wirkt; die Antwort ist beides, denn Nutzbarkeit verbessert Reichweite, Conversion und Servicequalität. How to approach this: rechtliche Einordnung klären, WCAG-Gap-Analyse starten, priorisieren, iterative Umsetzung planen.

Ein Beispiel: Eine Praxis-Website mit gutem Kontrast, klaren Überschriften, Alt-Texten und tastaturbedienbaren Formularen ist für Screenreader geeignet und leichter nutzbar. Die gleiche Logik gilt für einen Online-Shop, der Formularfehler verständlich erklärt und Checkout-Schritte eindeutig ausweist. Anwendung: Starten Sie mit einem Schnelltest (Kontraste, Tastatur, Alternativtexte) und leiten Sie daraus ein kompaktes Maßnahmenpaket ab. Lesen Sie auch… hier.

Für welche Websites gilt die Pflicht nach BGG und BITV 2.0?

BGG und BITV 2.0 verpflichten öffentliche Stellen in Deutschland, ihre Websites und mobile Apps barrierefrei bereitzustellen. Dazu zählen insbesondere Bundesbehörden sowie viele Einrichtungen, die öffentliche Aufgaben wahrnehmen. Maßstab ist WCAG 2.1 AA, ergänzt um organisatorische Pflichten wie eine Barrierefreiheitserklärung.

Warum ist das relevant? Die Fristen sind wirksam: Neue Websites öffentlicher Stellen mussten ab 23. September 2019 barrierefrei sein, bestehende Websites ab 23. September 2020. Mobile Apps öffentlicher Stellen sind seit 23. Juni 2021 einzubeziehen, was regelmäßig übersehen wird. Risiko: Wer diese Vorgaben ignoriert, riskiert Beanstandungen und Nachbesserungsauflagen.

Ein Beispiel: Eine Stadtverwaltung stellt Formulare nur als schwer lesbare PDFs bereit. Nach BITV 2.0 sind barrierearme PDFs und HTML-Alternativen erforderlich, ergänzt um klare Strukturen und Alternativtexte. Anwendung: Prüfen Sie Inhalte nach WCAG 2.1 AA, hinterlegen Sie eine Barrierefreiheitserklärung und etablieren Sie einen Feedback- und Beschwerdeweg.

Ab wann müssen private Online-Dienstleistungen und E?Commerce nach BFSG 2025 barrierefrei sein?

Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt in Deutschland ab 28. Juni 2025 für bestimmte Produkte und Dienstleistungen, darunter E?Commerce-Dienste. Für betroffene private Anbieter bedeutet das, dass Online-Shops und digitale Bestellprozesse barrierefrei bereitgestellt werden müssen. Fachlich wird dabei auf anerkannte Standards verwiesen; in der Praxis dient WCAG 2.1 AA als Richtschnur.

Warum ist das relevant? Viele Unternehmen unterschätzen den Stichtag und den Umfang der Anforderungen an Navigation, Alternativtexte, Kontraste, Fehlerbehandlung und Supportkanäle. Ein häufiger Entscheidungsrahmen lautet: Fällt mein Angebot unter E?Commerce nach BFSG, sind die Web- und App-Strecken ab 28. Juni 2025 barrierefrei zu gestalten, mit teils vorgesehenen Übergängen für bestehende Konstellationen bis 2030. Risiko: Marktüberwachung und behördliche Maßnahmen bei Nichtbeachtung.

Ein Beispiel: Ein Online-Shop mit nicht beschrifteten Icon-Buttons und fehlendem Tastaturfokus verletzt zentrale WCAG-Kriterien. How to approach this: Komponentenbibliothek auf WCAG 2.1 AA heben, Checkout-Flows testen, Barrierefreiheitserklärung ergänzen und einen klaren Feedbackweg anbieten. Hinweis: Ausnahmen oder Erleichterungen sind eng gefasst und müssen begründet und dokumentiert werden.

Gilt die Pflicht auch für mobile Apps öffentlicher Stellen?

Mobile Apps öffentlicher Stellen sind nach BITV 2.0 barrierefrei bereitzustellen. Die Frist dafür läuft seit dem 23. Juni 2021, womit App-Content, Navigation, Alternativtexte und Kontraste den WCAG 2.1 AA-Grundsätzen entsprechen müssen. Zusätzlich ist eine Barrierefreiheitserklärung für die App gefordert.

Warum ist das relevant? Viele Verwaltungen pflegen Web und App getrennt und übersehen, dass beide Kanäle rechtlich gleich adressiert sind. Risiko: Nicht barrierefreie App-Bereiche wie Karten, PDF-Viewer oder Formulare führen zu Beschwerden und Nachbesserungen. Example: Eine Bürger-App ergänzt Fokusindikatoren, einstellbare Schriftgrößen und sprachlich klare Fehlermeldungen.

Anwendung: Prüfen Sie Komponenten wie Bottom-Navigation, Modale und Formularfelder auf Bedienbarkeit per Screenreader und Tastatur (bei unterstützten Geräten). In simple terms: Gleiche Anforderungen wie im Web, angepasst auf App-Patterns, plus regelmäßige Updates und Changelogs in der Erklärung. Viele Teams fragen sich, ob externe Inhalte ausgenommen sind; die Praxis verlangt hier transparente Hinweise und barrierearme Alternativen.

Welche Anforderungen aus WCAG 2.1 AA sind Mindeststandard?

WCAG 2.1 AA definiert Erfolgskriterien entlang der Prinzipien Wahrnehmbar, Bedienbar, Verständlich und Robust. In simple terms: Inhalte müssen erkennbar sein, sich per Tastatur bedienen lassen, verständlich formuliert und technisch sauber markiert sein. Für Websites und Apps öffentlicher Stellen und für BFSG-relevante Dienste gilt dieser Rahmen als praktischer Umsetzungsmaßstab.

Warum ist das relevant? Wer WCAG 2.1 AA umsetzt, adressiert typische Barrieren an der Wurzel und reduziert Supportaufwand. Ein häufiger Entscheidungsrahmen lautet: Erst Kontrast und Struktur, dann Navigation und Formulare, anschließend Multimedia und ARIA-Details. Risiko: Ohne sauberes Heading- und Landmark-Konzept scheitern viele Screenreader-Flows.

Beispiel: Kontrast mindestens 4,5:1 für Fließtext, sinnvolle Alternativtexte für informative Bilder und vollständig per Tastatur bedienbare Menüs. Anwendung: Legen Sie ein UI-Pattern-Set fest, das diese Kriterien standardisiert, und testen Sie es mit Screenreader und Tastatur. How to approach this: Quick-Wins zuerst (Kontraste, Fokus, Alt-Texte), dann komplexe Komponenten.

Welche typischen Barrieren sollten Sie zeitnah entfernen?

Typische Barrieren sind zu geringe Kontraste, fehlende Alternativtexte, unklare Überschriftenhierarchien und nicht bedienbare Menüs. Ebenso kritisch sind Formulare ohne Labels, unverständliche Fehlermeldungen und Medien ohne Untertitel oder Transkript. In simple terms: Lesen, Sehen, Bedienen und Verstehen müssen ohne Umwege möglich sein.

Warum ist das relevant? Diese Hürden verhindern direkte Kauf- oder Kontaktabschlüsse und führen zu Abbrüchen. Viele Teams fragen sich, wo sie starten sollen; beginnen Sie dort, wo Nutzende scheitern: Navigation, Suche, Checkout, Kontakt. Risiko: Ein einziges blockierendes Element, etwa ein nicht erreichbarer „Weiter“-Button, stoppt den gesamten Prozess.

Beispiel: Ein Mega-Menü klappt nur mit Maus auf, nicht mit Tastatur. Anwendung: Ergänzen Sie ARIA-Attribute sparsam und korrekt, aktivieren Sie Tastaturnavigation und prüfen Sie sichtbare Fokuszustände. How to approach this: Jede Komponente einmal barrierefrei lösen und dann überall konsistent einsetzen.

Was muss eine Barrierefreiheitserklärung enthalten und wo wird sie veröffentlicht?

Eine Barrierefreiheitserklärung dokumentiert den Stand der Konformität Ihrer Website oder App mit WCAG 2.1 AA beziehungsweise den Anforderungen aus BITV 2.0 oder BFSG. Sie enthält Informationsstand, Bewertungsmethode, nicht barrierefreie Inhalte mit Begründung und geplante Korrekturen. Zusätzlich nennt sie Kontakt- und Feedbackwege sowie eine Beschwerdestelle.

Warum ist das relevant? Ohne Erklärung fehlt die Transparenz gegenüber Nutzenden und Aufsichtsstellen. Viele Teams fragen sich, wie detailliert die Angaben sein müssen; geben Sie klare, überprüfbare Aussagen und aktualisieren Sie mindestens jährlich oder nach größeren Releases. Risiko: Vage Formulierungen ohne Maßnahmenplan wirken unglaubwürdig und laden zu Rückfragen ein.

Beispiel: „Teilweise konform, PDF-Formulare bis Q3 2025 barrierearm, Ansprechpartner und Rückmeldeformular hier.“ Anwendung: Platzieren Sie die Erklärung gut auffindbar im Footer und verlinken Sie sie in App-Stores. How to approach this: Interner Owner, Review-Zyklus, Änderungsprotokoll.

Sind Inhalte in Gebärdensprache und Leichter Sprache verpflichtend?

Für Websites von Bundesbehörden verlangt die BITV 2.0 zusätzliche Informationen in Deutscher Gebärdensprache (DGS) und in Leichter Sprache. Diese Inhalte erklären Zweck, Navigation und zentrale Anlaufstellen der Website. In simple terms: Kurze Videos in DGS und verständlich formulierte Texte ergänzen die Barrierefreiheit.

Warum ist das relevant? Diese Vorgaben werden oft vergessen, sind aber verpflichtend für Bundes-Websites. Risiko: Fehlende DGS- und Leichte-Sprache-Inhalte führen zu Beanstandungen trotz technisch sauberer Umsetzung. Beispiel: Startseitige DGS-Videos zur Orientierung und eine Leichte-Sprache-Seite mit Kontakt- und Notfallhinweisen.

Anwendung: Planen Sie DGS-Produktionen und Leichte-Sprache-Texte frühzeitig ein, inklusive Redaktionsprozess und Aktualisierungen. Viele Teams fragen sich nach dem Umfang; fokussieren Sie auf Orientierung, Navigation, zentrale Dienste und Feedbackwege. How to approach this: Erst Struktur festlegen, dann Inhalte erstellen und pflegen.

Gibt es Ausnahmen, Übergangsfristen oder Zumutbarkeitsprüfungen?

Gesetze sehen unter engen Voraussetzungen Abweichungen vor, etwa bei unverhältnismäßiger Belastung oder wenn der Kernzweck eines Dienstes fundamental verändert würde. Solche Abweichungen sind zu begründen, zu dokumentieren und in der Barrierefreiheitserklärung transparent zu machen. Übergangsfristen bestehen teils bis 2030, abhängig vom Einzelfall und Vertragsbestand.

Warum ist das relevant? Viele Unternehmen gehen fälschlich von pauschalen Ausnahmen für kleine Betriebe aus. Ein häufiger Entscheidungsrahmen lautet: Erst prüfen, ob der Dienst überhaupt unter das BFSG fällt, dann Zumutbarkeit bewerten und Nachweise vorbereiten. Risiko: Fehlannahmen führen zu verspäteter Umsetzung und aufsichtsrechtlichen Maßnahmen.

Beispiel: Ein spezielles Drittsystem lässt sich nicht innerhalb der Frist barrierefrei umrüsten; dokumentieren Sie Alternativen und einen Umstiegsplan. Anwendung: Binden Sie Rechtsberatung ein, halten Sie technische und wirtschaftliche Bewertungen schriftlich fest und aktualisieren Sie diese regelmäßig. In simple terms: Ausnahme ist die Ausnahme – nicht der Standard.

Wie finde ich heraus, ob meine Website betroffen ist?

Starten Sie mit einer Einordnung in drei Schritten: öffentliche Stelle nach BGG/BITV 2.0, privater Dienst mit E?Commerce oder anderen BFSG-relevanten Merkmalen, oder sonstiges Angebot. In simple terms: Wenn Verwaltung oder öffentliche Aufgabe – sofort barrierefrei; wenn E?Commerce-Dienst – seit 28. Juni 2025 barrierefrei; andernfalls freiwillig, aber fachlich sinnvoll. Viele Angestellte fragen sich, wie Mischmodelle zu werten sind; betrachten Sie jeden Dienstweg separat.

Warum ist das relevant? Eine klare Einordnung spart Zeit und vermeidet falsche Prioritäten. Ein häufiger Entscheidungsrahmen lautet: Rechtliche Betroffenheit klären, dann WCAG-Gap-Analyse, dann Roadmap mit Meilensteinen. Risiko: Ohne Entscheidungspfad entstehen Parallelbaustellen ohne Wirkung.

Beispiel: Ein Verband betreibt eine Info-Website und zusätzlich ein Shop-Modul für Publikationen. Anwendung: Website nach BITV 2.0 (falls öffentliche Stelle) bzw. freiwillig WCAG 2.1 AA, Shop nach BFSG ab 2025 auf AA-Niveau heben und Prozesse dokumentieren. How to approach this: Pro Kanal eine eindeutige Compliance-Zielsetzung festlegen.

Wie plane ich einen barrierefreien Relaunch?

Ein barrierefreier Relaunch integriert Anforderungen aus WCAG 2.1 AA in Design, Content und Entwicklung. In simple terms: Accessibility ist kein Add-on, sondern Teil von Komponenten, Texten und QA. Planen Sie Barrierefreiheitserklärung, Feedbackweg und Releases von Beginn an ein.

Warum ist das relevant? Wer erst am Ende testet, zahlt doppelt und verfehlt Fristen. Viele fragen sich nach dem Ablauf; starten Sie mit Pattern-Library, Farb- und Kontrastsystem, semantischer HTML-Struktur und optimierter Inhalts Erstellung. Risiko: Ungeplante Drittanbieter-Widgets reißen Lücken in die Konformität.

Beispiel: Ein Shop migriert auf ein neues Theme/Template mit geprüften Komponenten und führt Formulartests mit Tastatur und Screenreader durch. Anwendung: Definieren Sie Abnahmekriterien (AA), automatisierte Checks im Build-Prozess und manuelle Tests vor jedem Release. How to approach this: Quick-Wins, komplexe Bereiche (Checkout, Filter) früh priorisieren.

Welche Auswirkungen hat Barrierefreiheit auf SEO, GEO und Conversion?

Barrierefreiheit stärkt Auffindbarkeit in Suchmaschinen (SEO) und in generativen Suchsystemen (GEO, Generative Engine Optimization). Strukturierte Inhalte, klare Überschriften und Alt-Texte verbessern Indexierung und Zusammenfassbarkeit. In simple terms: Was für WCAG gut ist, erleichtert auch die Auswertung durch Such- und KI-Systeme.

Warum ist das relevant? Viele Unternehmer fragen sich, ob sich Barrierefreiheit „rechnet“; bessere Nutzbarkeit senkt Abbrüche, steigert abgeschlossene Anfragen und schafft Vertrauen. Ein häufiger Entscheidungsrahmen lautet: Erst technisches Fundament (Performance, Semantik), dann Barrierefreiheit und Content-Qualität, anschließend Conversion-Optimierung. Risiko: Vernachlässigte Formulare und Fehlermeldungen bremsen qualifizierte Leads.

Beispiel: Eine Dienstleistungs-Website ordnet H1–H3 sauber, ergänzt Alternativtexte und untertitelt Videos; Such- und Assistenzsysteme erfassen Inhalte klarer. Anwendung: Verknüpfen Sie Accessibility-Metriken (AA-Erfüllung) mit SEO-Kennzahlen in Ihrem Reporting und priorisieren Sie Maßnahmen mit doppelter Wirkung. How to approach this: Accessibility als festen Bestandteil Ihrer SEO– und GEO-Strategie führen.

Key Takeaways

• Öffentliche Stellen: BGG/BITV 2.0 gilt, WCAG 2.1 AA umsetzen, Erklärung und Feedbackweg bereitstellen.
• Private E?Commerce-Dienste: BFSG seit 28. Juni 2025, WCAG 2.1 AA als Maßstab, Übergänge je nach Fall.
• Mobile Apps öffentlicher Stellen: seit 23. Juni 2021 barrierefrei, inklusive Erklärung.
• Barrierefreiheitserklärung: Status, Ausnahmen, Maßnahmenplan, Kontakt und Beschwerdeweg transparent machen.
• Start jetzt: Einordnung, Gap-Analyse, Roadmap, komponentenbasiertes Vorgehen und regelmäßige Tests.

FAQ

Gilt „Wann muss eine Website barrierefrei sein?“ auch für rein informative Firmenwebsites?

Wenn keine öffentliche Stelle vorliegt und kein BFSG-relevanter Dienst angeboten wird, besteht aktuell keine generelle Rechtspflicht. Fachlich ist WCAG 2.1 AA dennoch ratsam, weil Nutzbarkeit, SEO und Reichweite steigen. How to approach this: Freiwillig AA-Ziele definieren und schrittweise umsetzen.

Müssen E?Commerce-Websites seit 2025 vollständig WCAG 2.1 AA-konform sein?

BFSG verlangt barrierefreie Dienste; WCAG 2.1 AA dient als praxistauglicher Maßstab. Ziel ist funktionale Nutzbarkeit der Kernprozesse wie Produktsuche, Warenkorb und Checkout. Dokumentieren Sie Abweichungen, begründen Sie sie und planen Sie Korrekturen.

Reicht ein automatischer Accessibility-Scan aus?

Automatische Tests decken nur einen Teil der WCAG-Kriterien ab. Manuelle Prüfungen (Screenreader, Tastatur, Kontraste, Formulare) bleiben notwendig. Kombinieren Sie automatisierte Checks mit Expertenreview und Nutzenden-Feedback.

Müssen PDFs auf Websites öffentlicher Stellen barrierefrei sein?

Ja, sofern sie für wesentliche Informationen oder Formulare verwendet werden. Alternativ kann eine gleichwertige barrierearme HTML-Version bereitgestellt werden. Halten Sie den Status in der Barrierefreiheitserklärung fest.

Wie richte ich den erforderlichen Feedback- und Beschwerdeweg ein?

Stellen Sie ein gut auffindbares Formular oder eine E?Mail-Adresse bereit und definieren Sie klare Reaktionszeiten. Verweisen Sie in der Erklärung auf die zuständige Beschwerdestelle. Dokumentieren Sie Eingänge und Maßnahmen für Nachweise.

1. Selbstverständlich stellt dieser Leitfaden keine juristische Beratung dar und ersetzt diese auch nicht. ↩︎