BFSG-Barrierefreiheit mit WordPress

WordPress selbst kann barrierefrei sein — die meisten Barrieren stecken in Themes, Seitenbaukästen und Plugins. Ein Scan zeigt, was auf Ihrer konkreten Installation tatsächlich anliegt.

Typische Barrieren bei WordPress

Das sind die Stellen, an denen wir bei WordPress zuerst nachsehen:

• Theme-Farbschemata mit zu geringem Kontrast bei Text und Buttons
• Formular-Plugins (z. B. Contact Form 7) mit fehlenden verknüpften Labels
• Slider und Karussells, die sich nicht per Tastatur steuern lassen
• Seitenbaukasten-Elemente ohne korrekte Überschriften- und Landmark-Struktur

Wo diese Fehler bei WordPress auftreten

Bei WordPress kommen die sechs selten aus dem Kern, sondern aus Theme und Plugins: Seitenbaukästen erzeugen leere Links um verlinkte Bilder, Formular-Plugins setzen Platzhalter statt Labels, und die Farbwerte des Themes bestimmen den Kontrast, ohne dass Sie sie je bewusst gewählt haben.

Wie häufig diese Fehler insgesamt sind, hat die WebAIM Million 2026 an einer Million Startseiten gemessen: Sechs Fehlerarten machen 96 % aller Verstöße aus, und alle sechs sind maschinell erkennbar. Die vollständige Tabelle steht im Ratgeber „Wie Sie Ihre Website auf Barrierefreiheit testen“.

Gilt das BFSG für WordPress?

Das BFSG richtet sich nach dem, was Ihre Website tut — nicht nach dem CMS. Ein Verbraucherangebot auf WordPress unterliegt denselben Anforderungen wie auf jeder anderen Technik.

Wer genau betroffen ist und welche Ausnahmen gelten, erklärt unser Ratgeber „Gilt das BFSG für meine Website?“.

Warum WordPress-Seiten so unterschiedlich abschneiden

WordPress selbst erzeugt sauberes Markup. Was Ihre Besucher sehen, entsteht aber aus drei Schichten darüber: dem Theme, dem Editor oder Page-Builder, mit dem die Seiten gebaut wurden, und den Plugins für Formulare, Slider, Cookies und Popups. Jede dieser Schichten kann Barrieren einführen, und keine davon wird von den anderen kontrolliert.

Der praktische Effekt: Zwei Seiten mit derselben WordPress-Version und demselben Theme können in einer Prüfung weit auseinanderliegen — je nachdem, wer die Inhalte gepflegt hat. Bei WordPress ist Barrierefreiheit deshalb zu einem großen Teil eine Redaktionsfrage, nicht nur eine Entwicklungsfrage.

Wo WordPress-Seiten konkret durchfallen

Überschriften als Schriftgrößen

Der häufigste redaktionelle Fehler und einer der wenigen, die vollständig maschinell erkennbar sind. Im Block-Editor und in jedem Page-Builder lässt sich die Überschriftenebene frei wählen — und sie wird nach Optik gewählt: Eine H2 wirkt zu groß, also nimmt man eine H4. Für sehende Leser ändert das nur die Größe. Für Screenreader-Nutzer, die eine Seite über die Überschriftenliste erschließen, zerfällt damit die Gliederung.

Dazu kommt die zweite H1: Viele Themes setzen die Seitenüberschrift automatisch als H1, und der Redakteur beginnt den Inhalt noch einmal mit einer H1.

Page-Builder-Markup

Elementor, Divi, WPBakery und ähnliche Werkzeuge erzeugen tief verschachtelte <div>-Strukturen ohne Landmarks. Typische Folgen:

• Verlinkte Boxen ohne Text. Eine „Karte“ aus Bild und Hyperlink, bei der nur das Bild verlinkt ist und die Überschrift daneben reiner Text bleibt — ein leerer Link.
• Icon-Buttons. Hamburger-Menü, Suchlupe, Schließen-Kreuz und Slider-Pfeile kommen häufig ohne zugänglichen Namen.
• Akkordeons und Tabs, die per Maus funktionieren, aber nicht per Tastatur erreichbar sind.
• Fokusindikatoren, die aus optischen Gründen per outline: none entfernt wurden.

Formular-Plugins

Kontaktformulare sind auf einer Unternehmensseite die wichtigste Interaktion und gleichzeitig die häufigste Fundstelle. Die verbreiteten Plugins können barrierefreie Formulare erzeugen — tun es aber nur, wenn die Felder entsprechend angelegt sind.

• Platzhaltertext statt Label: verschwindet beim Tippen und wird von vielen Screenreadern nicht als Beschriftung gewertet.
• Pflichtfelder nur mit Sternchen markiert, ohne Erklärung und ohne aria-required.
• Fehlermeldungen erscheinen visuell, werden aber nicht angekündigt und erhalten keinen Fokus.
• Datenschutz-Checkbox ohne klickbares, verknüpftes Label.
• Captchas ohne nicht-visuelle Alternative.

Mediathek und Inhalte

Alt-Texte pflegen Sie in der Mediathek pro Bild. Zwei Muster fallen in Prüfungen auf: Bei Importen tragen alle Bilder den Dateinamen als Alt-Text — schlimmer als kein Alt-Text, weil „IMG_4821-1.jpg“ vorgelesen wird. Und dekorative Bilder tragen einen Alt-Text, obwohl sie ein leeres alt="" haben sollten, damit Screenreader sie überspringen.

Ebenfalls typisch für Unternehmensseiten: Öffnungszeiten, Preislisten oder Kontaktdaten als Grafik eingebunden, und PDF-Downloads (Formulare, Merkblätter, Speisekarten), die nicht getaggt sind.

WCAG-Checkliste für WordPress

Sortiert nach den Rollen, die an einer WordPress-Seite arbeiten. Markiert ist, was ein automatischer Scan zuverlässig erkennt.

Für die Redaktion

• Genau eine H1 pro Seite, keine übersprungenen Ebenen (automatisch prüfbar)
• Überschriftenebene nach Gliederung wählen, Größe über das Theme regeln
• Alt-Text je Inhaltsbild, dekorative Bilder mit leerem alt (Vorhandensein automatisch prüfbar)
• Linktexte aus sich heraus verständlich — nicht „hier“ oder „mehr“
• Kein Text in Grafiken für Öffnungszeiten, Preise, Kontaktdaten
• PDFs getaggt oder als HTML-Alternative angeboten

Für Theme und Page-Builder

• Landmarks vorhanden: header, nav, main, footer (automatisch prüfbar)
• Sprachauszeichnung lang="de" gesetzt (automatisch prüfbar)
• Aussagekräftiger <title> je Seite (automatisch prüfbar)
• Kontrast von Fließtext, Links und Buttons geprüft (automatisch prüfbar)
• Sichtbarer Fokusindikator, nicht per CSS entfernt
• „Zum Inhalt springen“-Link vorhanden
• Menü, Akkordeons und Tabs vollständig per Tastatur bedienbar
• Verlinkte Karten: der Text ist verlinkt, nicht nur das Bild (leere Links automatisch prüfbar)
• Icon-Buttons mit zugänglichem Namen (automatisch prüfbar)

Für Plugins

• Alle Formularfelder mit <label for>, nicht nur Platzhalter (automatisch prüfbar)
• Fehlermeldungen im Text benannt und angekündigt
• Datenschutz-Checkbox mit klickbarem Label (automatisch prüfbar)
• Cookie-Banner per Tastatur bedienbar, kein Fokusfang
• Slider ohne Autoplay oder mit Pausieren-Möglichkeit
• Eingebettete Videos mit Untertiteln, kein Ton-Autoplay
• Nach jedem Plugin-Update erneut geprüft

Gilt das BFSG für eine reine Info-Website?

Nicht automatisch. Das BFSG erfasst bestimmte Dienstleistungen an Verbraucher — der elektronische Geschäftsverkehr gehört dazu, eine reine Visitenkarten-Seite ohne Transaktion nicht zwingend. Sobald Ihre Seite jedoch Buchungen, Bestellungen, Konten oder vergleichbare Vorgänge anbietet, verschiebt sich die Einschätzung deutlich.

Für Kleinstunternehmen gilt bei Dienstleistungen zudem eine Ausnahme. Welche Kriterien im Einzelnen gelten, erklärt der Ratgeber „Gilt das BFSG für meine Website?“ — er führt Sie in drei Fragen durch die Prüfung.

Was die Marktüberwachung ansieht

Nach ihrer veröffentlichten Strategie setzt die zuständige Stelle der Länder bei webbasierten Diensten auf automatisierte Vorprüfungen mit technischer Prüfsoftware. Vorrang haben allerdings Beschwerden — nach § 32 BFSG kann jede Verbraucherin einen Antrag auf Marktüberwachungsmaßnahmen stellen. Bei der aktiven Prüfung zählt vor allem die Reichweite eines Angebots und seine Bedeutung für die selbstständige Lebensführung. Die Einzelheiten stehen im Ratgeber „So prüft die Marktüberwachung nach dem BFSG“.

So prüfen Sie Ihre WordPress-Website — kostenlos

Der kostenlose Einzelseiten-Check zeigt in Sekunden die ersten Barrieren — ohne Anmeldung. Automatisierte Tests finden dabei ehrlich nur rund 30–57 % der WCAG-Probleme; den Rest markieren wir zur manuellen Prüfung, statt „100 % konform“ zu versprechen.

Für die ganze Website gibt es den vollständigen automatischen Report ab €14 — günstiger als die üblichen deutschen Tools.