BFSG-Praxisleitfaden für WordPress

Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt seit dem 28. Juni 2025. Für eine WordPress-Website heißt das: Wer Produkte oder Dienstleistungen an Verbraucher:innen richtet, muss die Seite so bauen, dass sie auch mit Screenreader, nur mit Tastatur und bei eingeschränktem Kontrastsehen nutzbar ist. Technischer Maßstab ist die WCAG 2.1 auf Stufe AA. Das ist abarbeitbar – wenn man es in der richtigen Reihenfolge angeht.

Wer betroffen ist – und wer nicht

Betroffen sind Websites, über die Verbraucher:innen Geschäfte abschließen: Onlineshops, Buchungsstrecken, Konten, Verträge, digitale Dienstleistungen. Eine reine Broschüren-Website ohne Transaktion fällt in der Regel nicht darunter – die Grenze verläuft aber unschärfer, als vielen lieb ist, sobald aus einem Kontaktformular eine Terminbuchung wird oder aus einem Newsletter ein Vertragsangebot.

Für Dienstleistungen gibt es eine Ausnahme für Kleinstunternehmen: weniger als 10 Beschäftigte und höchstens 2 Millionen Euro Jahresumsatz oder Bilanzsumme. Für Produkte gilt diese Ausnahme nicht. Wer unsicher ist, sollte die Einordnung nicht raten.

Die fünf Fehler, die wir am häufigsten finden

Bevor es an die Checkliste geht: Fünf Probleme tauchen in fast jedem Audit auf, das wir machen. Wer die vermeidet, hat den größten Teil der vermeidbaren Verstöße schon erledigt.

• Fehlende Alt-Texte. Bilder ohne Alternativtext sind für Screenreader unsichtbar. Dekorative Bilder bekommen ein leeres alt="", alles andere eine kurze Beschreibung.
• Zu schwache Kontraste. Text, der sich kaum vom Hintergrund abhebt. Mindestens 4,5:1 für normalen Text, 3:1 für große Schrift und Bedienelemente.
• Kein sichtbarer Fokus. Wer mit der Tastatur navigiert, muss sehen, wo er gerade steht. outline: none ohne Ersatz ist der Klassiker.
• Formulare ohne verknüpfte Labels. Platzhalter statt Label, Fehlermeldungen nur über Farbe, Pflichtfelder nur mit Sternchen – für Screenreader unbrauchbar.
• Nicht bedienbare Navigation und Pop-ups. Dropdowns, Slider und Overlays, die sich nicht per Tab erreichen und nicht per ESC schließen lassen.

Die Praxis-Checkliste

Diese Reihenfolge hat sich bei unseren Projekten bewährt – von der größten Wirkung zur Feinarbeit.

1. Semantisches HTML zuerst. Überschriften in logischer Hierarchie, echte Buttons und Links statt geklickter div-Container, Landmarken (header, nav, main, footer). Das trägt den größten Teil der Barrierefreiheit – und viele Page-Builder brechen genau hier.
2. Tastaturbedienung. Jede Funktion muss ohne Maus erreichbar sein: Menüs, Slider, Akkordeons, Pop-ups, Cookie-Banner. Wenn der Fokus in einem Overlay verschwindet, ist die Seite für Screenreader-Nutzer:innen an dieser Stelle zu Ende.
3. Sichtbarer Fokus. Das Element, auf dem die Tastatur gerade steht, muss deutlich erkennbar sein. Kein outline: none ohne Ersatz.
4. Kontraste. Text zu Hintergrund mindestens 4,5:1, große Schrift und Bedienelemente mindestens 3:1. Das betrifft oft die Markenfarben – besser jetzt klären als im Relaunch.
5. Formulare. Jedes Feld mit sichtbarem, verknüpftem Label. Fehlermeldungen im Text, nicht nur über Farbe. Pflichtfelder benannt, nicht nur mit Sternchen.
6. Alt-Texte. Jedes inhaltstragende Bild braucht eine Beschreibung, dekorative Bilder ein leeres Alt-Attribut. Das ist die Aufgabe, die im Redaktionsalltag am zuverlässigsten liegen bleibt.
7. Medien. Videos mit Untertiteln, Audio mit Transkript, keine automatisch startenden bewegten Inhalte ohne Stopp-Möglichkeit.
8. Linktexte. „Hier klicken“ sagt weder Screenreader-Nutzer:innen noch Suchmaschinen etwas. Der Linktext soll beschreiben, wohin er führt – „Mehr zu unseren Leistungen“ statt „mehr“.

Schnellcheck: Wo steht eure Seite?

Fünf Fragen zum Selbsttest. Jedes „Nein“ ist ein Punkt für die Liste oben.

• Lässt sich die ganze Seite nur mit der Tab-Taste bedienen, inklusive Menü, Formularen und Cookie-Banner?
• Ist immer sichtbar, wo der Tastatur-Fokus gerade steht?
• Haben alle inhaltstragenden Bilder einen Alt-Text, alle dekorativen ein leeres Alt-Attribut?
• Erreicht der Text den Kontrast 4,5:1, große Schrift und Buttons mindestens 3:1?
• Hat jedes Formularfeld ein sichtbares, verknüpftes Label, und stehen Fehler im Text – nicht nur in Rot?

Was ein Audit findet – und was ein Relaunch braucht

Ein Audit prüft den Ist-Zustand gegen die WCAG-Kriterien: automatisiert für das Messbare (Kontraste, fehlende Labels, Struktur), manuell für alles andere – und der manuelle Teil findet die Probleme, die wirklich blockieren. Am Ende steht eine priorisierte Liste: Was ist ein Verstoß, was ist Risiko, was ist Komfort. Ein Punkt, der in vielen Audits fehlt: eingebettete PDFs, Verträge, Datenblätter – dafür gilt derselbe Maßstab: Barrierefreie PDFs – so machen Sie Ihre Dokumente BFSG-konform.

Womit man automatisiert prüft: Lighthouse in den Chrome DevTools für die schnelle Ersteinschätzung, die WAVE-Browsererweiterung, die Barrieren direkt auf der Seite markiert – auch für Redakteur:innen brauchbar –, und axe DevTools für die tiefere, WCAG-genaue Analyse. Kontrastfragen klärt der WebAIM Contrast Checker einzeln. Manuell dazu: einmal komplett nur mit der Tab-Taste durch die Seite und ein Screenreader-Durchlauf mit NVDA (Windows) oder VoiceOver (Mac) – und, wo möglich, ein Test mit Menschen, die täglich mit assistiver Technik arbeiten.

Wenn diese Liste lang wird und die Ursachen im Theme oder im Page-Builder liegen, ist Nachbessern teurer als neu bauen. Ein barrierefreier Relaunch heißt: semantisches Template, ein Komponenten-Satz, der von Anfang an tastaturbedienbar ist, und ein Redaktionsworkflow, der die Pflege leicht macht statt sie zu kontrollieren. Der Unterschied, den eine Agentur macht, liegt nicht im Prüfen – Prüf-Tools gibt es kostenlos. Er liegt darin, die Befunde in eine Bau-Entscheidung zu übersetzen und die Seite so aufzustellen, dass sie auch nach zwei Jahren Redaktionsarbeit noch konform ist. Bei Online-Shops kommt eine zusätzliche Ebene dazu – Checkout, Produktbilder, Zahlungsmethoden: Barrierefreiheit in Online-Shops – so profitieren eure Kunden davon.

Was einen Relaunch nicht ersetzt: Overlay- oder Toolbar-Plugins, die per Widget Schriftgröße, Kontrast und Vorlesefunktion anbieten. Sie ändern nichts am darunterliegenden Code, bringen die Seite nicht in WCAG-Konformität und schaffen für Screenreader-Nutzer:innen oft neue Probleme. Einzelne Helfer-Plugins – etwa für Skip-Links – sind in Ordnung, als Ergänzung, nicht als Lösung. Genauso die automatischen Prüf-Tools: gut für den ersten Überblick, kein Ersatz für die manuelle Kontrolle.

Die zwei Aufgaben, die liegen bleiben

Nach dem Livegang sind es fast immer dieselben zwei Themen, die verrutschen: zu große Bilder und fehlende Alt-Texte. Beides lässt sich automatisieren. Warum Alt-Text Pflicht ist und wie eine Beschreibung aussieht, die etwas taugt, steht hier: Muss ich meine Bilder auf der Website beschreiben?. Wie sich Bildkompression und KI-gestützte Alt-Texte DSGVO-konform direkt in WordPress lösen lassen – ohne dass Bilder in eine fremde Cloud wandern –, zeigt dieser Beitrag: DSGVO-konforme Bildoptimierung mit KI-Alt-Texten.

Der Anfang

BFSG wirkt groß, solange man es als Ganzes betrachtet. Zerlegt in die acht Punkte oben und begonnen bei der Seitenstruktur, ist es eine Projektaufgabe wie andere auch. Der teuerste Weg ist, zu warten, bis die erste Beschwerde kommt.

Zuletzt geprüft: 04.09.2026. Dieser Beitrag ist eine praktische Orientierung und ersetzt keine Rechtsberatung.

Beitragsbild: Charles Deluvio / Unsplash