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