WordPress barrierefrei machen: BFSG-Checkliste für WP-Seiten

WordPress und Barrierefreiheit: Der Status Quo

WordPress betreibt über 40 % aller Webseiten weltweit. Das CMS bringt von Haus aus solide Barrierefreiheits-Grundlagen mit: korrektes HTML5, ARIA-Landmarks im Admin-Bereich und eine aktive Accessibility-Arbeitsgruppe im Core-Team.

Aber: Das Endergebnis hängt stark vom Theme, den Plugins und den Inhalten ab. Ein schlecht programmiertes Theme oder falsch konfigurierte Plugins können alle Grundlagen zunichtemachen. Seit dem BFSG (Barrierefreiheitsstärkungsgesetz), das gemäß § 1 Abs. 2 Dienstleistungen im elektronischen Geschäftsverkehr erfasst, müssen WordPress-Betreiber aktiv werden.

WordPress Core: Was bringt das CMS bereits mit?

WordPress hat in den letzten Jahren viel für Barrierefreiheit getan. Diese Features sind bereits im Core enthalten:

• Skip-Links im Admin – der Admin-Bereich hat Skip-Navigation (das Frontend hängt vom Theme ab).
• ARIA-Landmarks – role="navigation", role="main" und role="complementary" im Admin.
• Alt-Text-Feld – jedes Bild in der Mediathek hat ein dediziertes Alt-Text-Feld.
• Fokus-Management – modale Dialoge im Admin halten den Fokus korrekt.
• Überschriften-Struktur – der Block-Editor erzeugt semantisch korrekte Heading-Elemente.

Das Problem: Diese Features betreffen oft nur das Backend. Im Frontend entscheidet das Theme über Skip-Links, Landmarks und Fokus-Styles. Deshalb ist die Theme-Wahl der wichtigste erste Schritt. Weitere Informationen finden Sie im BFSG-Glossar.

Theme-Auswahl: Das accessibility-ready Tag

WordPress.org markiert Themes mit dem Tag „accessibility-ready“ – diese wurden vom Theme-Review-Team auf grundlegende Barrierefreiheit geprüft. Die Prüfung umfasst:

• Skip-Links vorhanden und funktional
• Tastatur-Navigation für alle interaktiven Elemente
• Korrekte ARIA-Attribute und Landmarks
• Ausreichende Farbkontraste (mindestens 4,5:1 gemäß WCAG SC 1.4.3)
• Sichtbare Fokus-Indikatoren (WCAG SC 2.4.7)

Empfehlenswerte accessibility-ready Themes: flavor flavor flavor flavor flavor flavor. Vermeide Themes mit exzessiven Animationen, versteckter Navigation und festen Schriftgrößen.

Prüfe bei jedem Theme: Kann ich das Menü per Tastatur bedienen? Gibt es Skip-Links? Sind Fokus-Styles sichtbar? Nutze dafür unseren kostenlosen BFSG-Scanner.

Block-Editor (Gutenberg): Barrierefreiheit beim Erstellen von Inhalten

Der Gutenberg-Editor bringt gute Voraussetzungen für barrierefreie Inhalte mit – wenn man ihn richtig nutzt:

• Überschriften-Block – erzeugt semantische <h2> bis <h6>-Elemente. Halte die Hierarchie ein: H1 nur einmal (Seitentitel), dann H2, H3 usw.
• Bild-Block – bietet ein Alt-Text-Feld direkt in den Block-Einstellungen. Nutze es bei jedem Bild (WCAG SC 1.1.1).
• Listen-Block – erzeugt korrekte <ul>/<ol>-Elemente statt Absätze mit Bindestrichen.
• Tabellen-Block – unterstützt Header-Zeilen. Aktiviere immer die Option „Kopfzeilenbereich“ (WCAG SC 1.3.1).
• Spalten-Block – nutzt CSS Grid statt Tabellen-Layout – semantisch korrekt.

Achtung: Gutenberg verhindert nicht, dass du leere Alt-Texte oder falsche Überschriften-Hierarchien erstellst. Die Verantwortung bleibt bei den Redakteuren.

Plugin-Empfehlungen: Was wirklich hilft

Diese Plugins unterstützen dich bei der Barrierefreiheit – ersetzen aber keine inhaltliche Arbeit:

• WP Accessibility – fügt Skip-Links hinzu, repariert fehlende Fokus-Styles, bietet eine Kontrast-Toolbar und erzwingt Alt-Text-Felder beim Upload.
• Sa11y – prüft Inhalte direkt im Editor auf Barrierefreiheit. Zeigt Warnungen bei fehlenden Alt-Texten, falscher Überschriften-Hierarchie und leeren Links. Ideal für Redakteure ohne technisches Wissen.
• One Click Accessibility – ermöglicht Nutzern, Schriftgröße, Kontrast und Animationen anzupassen.

Warnung vor Overlay-Plugins: Plugins wie AccessiBe, UserWay oder ähnliche „Accessibility Overlay“-Lösungen sind keine valide BFSG-Lösung. Sie versuchen, Barrierefreiheit per JavaScript aufzusetzen – das funktioniert nicht zuverlässig. Screenreader-Nutzer berichten regelmäßig von zusätzlichen Problemen durch Overlays. Die Barrierefreiheit muss im Code und Inhalt verankert sein.

Child-Theme und functions.php: Technische Anpassungen

Barrierefreiheits-Fixes sollten immer in einem Child-Theme erfolgen – sonst gehen Änderungen beim nächsten Theme-Update verloren. Wichtige Anpassungen für die functions.php deines Child-Themes:

• Skip-Link erzwingen – falls dein Theme keinen hat, kannst du per wp_body_open-Hook einen einfügen.
• Sprachattribut sicherstellen – language_attributes() im <html>-Tag sorgt für korrektes lang="de" (WCAG SC 3.1.1).
• Fokus-Styles nachrüsten – viele Themes entfernen :focus-Styles per outline: none. Im Child-Theme CSS: *:focus { outline: 2px solid #1e40af; outline-offset: 2px; }
• Alt-Text-Pflicht – mit einem Filter auf image_send_to_editor kannst du verhindern, dass Bilder ohne Alt-Text eingefügt werden.

Tipp: Dokumentiere alle Barrierefreiheits-Anpassungen in einer README im Child-Theme-Ordner – so gehen sie bei Team-Wechseln nicht verloren.

Content-Checkliste für Redakteure

Die besten technischen Grundlagen nützen nichts, wenn die Inhalte nicht barrierefrei sind. Hier die wichtigsten Regeln für jeden, der Inhalte in WordPress pflegt:

• Alt-Texte – bei jedem Bild-Upload setzen. Beschreibe, was das Bild zeigt, nicht „Bild“ oder den Dateinamen (SC 1.1.1).
• Überschriften-Hierarchie – H1 nur einmal (Seitentitel). Dann H2 für Hauptabschnitte, H3 für Unterabschnitte. Keine Ebene überspringen (SC 1.3.1).
• Link-Texte – aussagekräftig benennen. „Hier klicken“ oder „mehr“ sind für Screenreader nutzlos (SC 2.4.4).
• Listen – als HTML-Listen formatieren, nicht als Absätze mit Bindestrichen.
• Videos – mit Untertiteln einbetten. YouTube bietet automatische Untertitel, die du nachbearbeiten kannst (SC 1.2.2).
• Tabellen – mit Kopfzeilen versehen. Im Block-Editor die Option „Kopfzeilenbereich“ aktivieren (SC 1.3.1).

WordPress-spezifische BFSG-Fallen

Diese WordPress-Komponenten sind besonders häufig nicht barrierefrei:

• Kontaktformulare (Contact Form 7, WPForms) – Labels prüfen. Jedes Eingabefeld braucht ein sichtbares <label>-Element, nicht nur Placeholder-Text (SC 3.3.2). Fehlermeldungen müssen klar zugeordnet sein (SC 3.3.1).
• Slider und Karussells (Revolution Slider, Slider Revolution) – oft nicht tastaturbedienbar (SC 2.1.1). Autoplay-Animationen müssen pausierbar sein (SC 2.2.2).
• Lightbox-Galerien – müssen per Escape schließbar sein und den Fokus korrekt verwalten (SC 2.1.2).
• Cookie-Banner – muss per Tastatur bedienbar sein und darf nicht den Fokus fangen. Der „Ablehnen“-Button muss gleichwertig erreichbar sein.
• WooCommerce – Checkout-Seite separat prüfen. Warenkorb-Updates müssen per aria-live kommuniziert werden.
• Page Builder (Elementor, Divi) – erzeugen oft übermäßig verschachteltes HTML. Prüfe die generierten Strukturen auf semantische Korrektheit.

Schritt für Schritt: WordPress BFSG-konform machen

1. Scan durchführen: Starte mit dem bf-check BFSG-Scanner für eine automatisierte Erstanalyse.
2. Theme prüfen: Hat dein Theme das accessibility-ready Tag? Falls nicht: Migration auf ein barrierefreies Theme planen.
3. Child-Theme erstellen: Alle Barrierefreiheits-Fixes im Child-Theme umsetzen.
4. Plugins ausmisten: Overlay-Plugins entfernen. WP Accessibility und Sa11y installieren.
5. Alt-Texte nachrüsten: Alle bestehenden Bilder in der Mediathek durchgehen und Alt-Texte ergänzen.
6. Formulare testen: Jedes Formular per Tastatur durchklicken. Labels, Fehlermeldungen und Pflichtfeld-Kennzeichnung prüfen.
7. Tastatur-Test: Gesamte Seite per Tab-Taste durchnavigieren. Fokus muss immer sichtbar sein.
8. Screenreader-Test: Mit NVDA (Windows, kostenlos) oder VoiceOver (Mac) die wichtigsten Seiten testen.

Hinweis: Dieser Artikel dient der allgemeinen Information und ersetzt keine individuelle Rechtsberatung. Plugin-Empfehlungen basieren auf dem Stand April 2026 – prüfe vor der Installation immer die aktuelle Kompatibilität und Bewertungen.

Häufig gestellte Fragen

WooCommerce barrierefrei einrichten

Läuft dein Shop auf WordPress mit WooCommerce, kommen zu den allgemeinen CMS-Anforderungen die typischen Shop-Probleme dazu: Warenkorb, Produktvarianten und Checkout müssen für Tastatur- und Screenreader-Nutzer nachvollziehbar bleiben. Die Standard-Templates von WooCommerce sind eine solide Grundlage, aber Theme und zusätzliche Plugins verändern das Verhalten oft stärker, als auf den ersten Blick sichtbar ist.

Prüfe zuerst die Produktseite: Lässt sich die Mengenauswahl per Tastatur bedienen, und meldet sich eine Rückmeldung, wenn ein Produkt zum Warenkorb hinzugefügt wurde? Viele Themes zeigen dafür nur eine kurze, farbliche Animation, die für Screenreader-Nutzer unsichtbar bleibt. Ergänze in diesem Fall eine textliche Statusmeldung, die per aria-live-Bereich automatisch vorgelesen wird, sobald sich der Warenkorb-Inhalt ändert.

Bei Produkten mit Varianten – etwa Größe oder Farbe – achte darauf, dass jede Auswahlmöglichkeit ein eigenes, sprechendes Label hat und nicht nur als Farbfläche ohne Textalternative dargestellt wird. Im Warenkorb selbst müssen sich Menge ändern und Artikel entfernen komplett per Tastatur bedienen lassen, und die aktualisierte Summe muss nach jeder Änderung angesagt werden. Im Checkout gilt dieselbe Sorgfalt wie bei jedem anderen Formular: klare Labels, verständliche Fehlermeldungen direkt am betroffenen Feld und eine Tab-Reihenfolge, die der sichtbaren Anordnung der Felder entspricht. Prüfe zusätzlich die Bezahlmethoden-Auswahl: Radio-Buttons für Zahlungsarten müssen per Pfeiltasten oder Tab erreichbar sein, und die zugehörigen Zusatzfelder – etwa für Kreditkartendaten – dürfen erst dann in die Tab-Reihenfolge eingebunden werden, wenn die passende Zahlungsart tatsächlich ausgewählt ist. Sonst tabben Nutzer durch leere, ausgeblendete Felder, ohne zu verstehen, warum.

Formulare mit Contact Form 7 und Co. barrierefrei konfigurieren

Kontaktformulare gehören zu den WordPress-Bausteinen, bei denen kleine Konfigurationsfehler große Wirkung haben. Plugins wie Contact Form 7, WPForms oder Gravity Forms bringen zwar grundsätzlich barrierefreie Bausteine mit, überlassen die konkrete Umsetzung aber weitgehend dir – vor allem, wenn du Formularfelder per HTML-Snippet oder Shortcode selbst zusammenstellst.

Achte darauf, dass jedes Feld ein sichtbares Label hat, das über das for-Attribut mit der passenden Feld-ID verknüpft ist. Ein Platzhaltertext im Feld selbst ersetzt kein Label – er verschwindet, sobald der Nutzer zu tippen beginnt, und wird von manchen Screenreadern gar nicht als Feldbeschriftung erkannt. Markiere Pflichtfelder zusätzlich zur farblichen Kennzeichnung im sichtbaren Text, damit die Information nicht allein von der Farbwahrnehmung abhängt.

Bei Fehlermeldungen nach dem Absenden reicht eine rote Umrandung des betroffenen Feldes nicht aus. Die Meldung muss als Text erscheinen, dem fehlerhaften Feld eindeutig zugeordnet sein und im besten Fall automatisch vorgelesen werden, sobald sie erscheint. Verzichte außerdem auf Captchas, die ausschließlich visuell lösbar sind – biete stattdessen eine alternative Prüfung an, etwa eine einfache Rechenaufgabe mit Textfeld oder einen unsichtbaren Spam-Schutz im Hintergrund, der den Nutzer gar nicht erst einbezieht.

Barrierefreiheitserklärung für deine WordPress-Seite veröffentlichen

Zur BFSG-Pflicht gehört neben den technischen Anpassungen auch eine veröffentlichte Barrierefreiheitserklärung. Lege dafür eine eigene Seite an, statt sie in einen bestehenden Text einzubetten, und verlinke sie fest im Footer-Menü, damit sie von jeder Unterseite aus erreichbar ist – am besten direkt neben Impressum und Datenschutzerklärung.

Beschreibe konkret, welche Bereiche deiner Seite noch nicht vollständig barrierefrei sind, statt einen allgemeinen Vorbehalt zu formulieren. Bei WordPress betrifft das häufig ältere Blogbeiträge mit fehlenden Alt-Texten, eingebettete Drittanbieter-Inhalte wie Videos oder Karten, oder ein Theme-Feature, das noch nicht angepasst wurde. Ergänze eine funktionierende Kontaktmöglichkeit für Rückmeldungen zu Barrieren sowie einen Hinweis auf die zuständige Schlichtungsstelle für den Fall, dass eine Meldung nicht zufriedenstellend beantwortet wird.

Da sich bei WordPress mit jedem Plugin-Update, jedem neuen Blogbeitrag und jeder Theme-Anpassung der tatsächliche Stand der Barrierefreiheit ändern kann, sollte die Erklärung kein einmaliges Dokument bleiben. Trage dir feste Zeitpunkte ein, an denen du sie gegen den aktuellen Zustand der Seite prüfst, und aktualisiere das Datum der letzten Überarbeitung jedes Mal, wenn sich etwas geändert hat. Eine veraltete Erklärung, die längst behobene oder neu entstandene Probleme nicht mehr korrekt beschreibt, wirkt bei einer Prüfung unglaubwürdiger als eine kurze, aber aktuelle Fassung.