Barrierefreiheit Websites 2025: BFSG/EAA Anforderungen [Leitfaden]

1) Was regeln BFSG & EAA – und wen betrifft das?

Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt den European Accessibility Act (EAA) in Deutschland um. Es adressiert vor allem verbrauchergerichtete digitale Produkte und Dienste: E-Commerce-Websites/Apps, E-Book-Leser, Banking, Kommunikationsdienste, Selbstbedienungsterminals u. a. Ziel ist, Barrieren abzubauen, damit Menschen mit Behinderungen digitale Angebote gleichberechtigt nutzen können – ohne Speziallösungen. Für neue Produkte und Dienste gelten die Anforderungen ab dem 28. Juni 2025; es gibt Übergangsregelungen für ältere Verträge/Bestandsgeräte.

Für Website-Betreiber heißt das: Wer Verbraucher adressiert, muss Barrierefreiheits-Anforderungen erfüllen. In der Praxis orientiert man sich an EN 301 549 und den WCAG-Erfolgskriterien. Die Details hängen vom Angebot ab – doch die Grundprinzipien (wahrnehmbar, bedienbar, verständlich, robust) sind übertragbar.

2) WCAG/EN 301 549 in der Praxis: Was bedeutet „AA-Niveau“ konkret?

Die WCAG strukturieren Barrierefreiheit in Prinzipien und Erfolgskriterien. Für Websites heißt AA grob: gute Kontraste (Text/Bilder), skalierbare Textgrößen, Tastaturbedienung ohne Fallen, sichtbare Fokus-Stati, verständliche Formulare (Labels, Fehlermeldungen, Hilfen), Alternativen für Medien (Alt-Texte, Untertitel, Transkripte) und robustes HTML (semantische Elemente, sinnvolle ARIA). Dazu kommen Anforderungen wie reflow, timeouts, orientation und – in WCAG 2.2 – focus appearance und dragging.

Wichtig ist der Prozess: Barrierefreiheit ist kein Sprint, sondern Teil der Produktentwicklung. Styleguide/Design-Tokens, Komponentenbibliothek, Code-Reviews, Test-Setups und Schulungen sorgen dafür, dass Standards nicht nur einmalig, sondern dauerhaft eingehalten werden.

3) Accessibility-by-Design: Rollen, Abläufe, Dokumentation

Setze Barrierefreiheit bereits im Briefing auf die Agenda. Definiere Rollen (Produkt, Design, Dev, QA), vereinbare Definition of Done mit A11y-Kriterien und pflege einen lebenden Styleguide. Bibliotheken mit zugänglichen Komponenten (Buttons, Form Controls, Dialoge, Tabs, Tabellen) sind der Turbo: Einmal sauber gebaut, überall sicher genutzt. Dokumentiere Muster (Keyboard-Flow, Fokusreihenfolgen, ARIA-Zustände) und halte sie in Code-Beispielen fest.

Plane Schulungen für Redaktion/Support: Alternativtexte, Überschriften, Tabellen, Linktexte, Untertitel/Transkripte. Gute Inhalte sind ein A11y-Hebel – schon vor dem ersten Zeile Code.

4) Quick Wins: Semantik, Formulare, Medien

Semantik: Nutze echte HTML-Elemente (h1–h6, p, ul/ol/li, table, button). Überschriften-Hierarchie muss logisch sein; keine Sprünge. Formulare: Jedes Input benötigt ein , Fehler müssen verständlich und programmatisch erkennbar sein (ARIA-Deskriptoren), Hilfetexte gehören in die Nähe des Felds. Medien: Sinnvolle Alt-Texte (keine Keyword-Füllung), Untertitel/Transkripte für Videos, Audio-Beschreibungen, falls nötig.

Keyboard: Fokusreihenfolge logisch, sichtbare Fokus-Stati, keine „Keyboard-Fallen“. Kontraste: Tokens in der Design-System-Palette definieren, damit kein „grau auf hellgrau“ passiert. Tabellen: Kopfzellen mit scope auszeichnen, Zusammenfassungen/Caption sinnvoll nutzen.

5) E-Commerce & Spezialfälle: Filter, Produktinfos, Checkout

Filter/Facetten: Steuerung per Tastatur, States programmatisch erkennbar (ARIA-Pressed/Selected), Live-Regionen für Ergebnisänderungen. Produktseiten: Strukturierte Infos (Preis, Varianten, Lieferzeiten), eindeutige Buttons (Add to Cart), sinnvolle Alternativtexte, Zoom/Ansicht ohne Maus nutzbar. Checkout: klare Reihenfolge, evidente Labels, Fehlerhinweise in Klartext (nicht kryptisch), Eingaben persistent halten, wenn ein Schritt fehlschlägt, und ausreichend Zeit geben.

Bonuspunkte: Wunschlisten/Später-kaufen, barrierearme Promotions (keine animierten Overlays ohne Steuerung), performante Seiten (CWV helfen auch A11y), und transparente Kundenkommunikation (z. B. Versand/Retouren).

6) Dokumente & PDFs: Häufiger Knackpunkt – so löst du ihn

PDFs sind oft nicht barrierefrei. Lösungswege: Web-First (Content als HTML), nur wenn nötig PDF – dann mit Tags, Lese-Reihenfolge, Alternativtexten, richtigen Überschriften und Formularfeldern. Für bestehende PDFs: priorisiere die „kritischen“ (z. B. Preisinformationen), stelle Übergangsweise HTML-Versionen bereit und plane mittelfristig eine Reduktion der PDF-Flut.

Denke an Medien-Alternativen (Untertitel/Transkripte) und an barrierearme Downloads (Dateinamen, Größen, Format-Hinweise). Dokumentiere, was schon compliant ist – und was wann umgestellt wird.

7) Test-Stack: Automatisiert, manuell, Assistive Technologien

Automatisiert: Linter/Build-Checks (HTML-Validität), Lighthouse/Axe für schnelle Hinweise. Manuell: Tastatur-Rundgang, Fokus-Verfolgung, Screenreader-Smoke-Tests (NVDA, VoiceOver). Assistive Technologien: Tests in typischen Browser/AT-Kombinationen. Wichtig: keine Checkbox-Mentalität – die Kriterien sind Leitplanken, entscheidend ist die reale Nutzbarkeit.

Dokumentiere Tests als lebende Artefakte (Checklisten, Screencasts, Tickets) und verknüpfe sie mit deiner Komponentenbibliothek. So bleibt Wissen im Team – und neue Kolleg:innen sind schneller produktiv.

8) Recht, Risiko & Kommunikation: So bleibst du gelassen

Halte fest, was du tust: Konzept, Styleguide, Komponenten, Testprotokolle, Release Notes. Transparenz hilft intern wie extern. Kommuniziere Verbesserungen auch öffentlich (Change-Logs, A11y-Seite) – das baut Vertrauen auf und motiviert dein Team. Bei unvermeidlichen Übergangsphasen (z. B. PDF-Altlasten) hilft ein Plan mit Terminen.

Rechtliche Beratung ersetzt das nicht – aber eine solide Dokumentation und sichtbare Fortschritte senken das Risiko deutlich. Und: Barrierefreiheit ist kein „Pflichtprogramm“. Sie verbessert die User Experience insgesamt – und macht deine Seite schneller, klarer und inklusiver.

9) 30/60/90-Tage-Plan: Struktur statt Stress

30 Tage: Audit (Kontraste, Tastatur, Formulare, Medien), Quick-Wins, Styleguide-Tokens, Komponenten-Prioritäten, PDF-Bestandsaufnahme.

60 Tage: Komponenten hart machen (Dialoge, Tabs, Tabellen), Schulungen, Test-Stack (autom./manuell/AT) einführen, E-Commerce-Spezialfälle anpacken.

90 Tage: PDFs reduzieren/nachrüsten, Monitoring etablieren, A11y in DoD integrieren, öffentlich kommunizieren (A11y-Seite/Changelog).

Häufige Fragen (FAQ)