WordPress-Barrierefreiheit: ein praktischer Leitfaden für die Einhaltung der Vorschriften 2026

Wenn ein Nutzer Ihren Text nicht lesen, eine Schaltfläche nicht anklicken oder schlicht nicht erkennen kann, wohin ein Link führt, verlässt er die Seite. Nicht, weil der Inhalt schlecht ist. Sondern weil die Seite nicht mit ihm kommuniziert.

Seit Juni 2025 ist der European Accessibility Act (EAA) verpflichtend. In Deutschland gilt das Barrierefreiheitsstärkungsgesetz (BFSG). Bußgelder, Compliance-Verfügungen, verlorene Reichweite. Doch hinter dem rechtlichen Druck steht eine einfache Wahrheit: Laut WHO leben rund 16% der Menschen weltweit, also einer von sechs, mit einer Form von Behinderung. Sie zu ignorieren bedeutet, jeden sechsten Besucher zu verlieren.

WordPress ist hier weder Ausnahme noch Todesurteil. Das CMS liefert ein solides Fundament, aber echte Barrierefreiheit entsteht durch bewusste Entscheidungen des Entwicklers oder Seitenbetreibers. Dieser Leitfaden ist eine Schritt-für-Schritt-Anleitung: von der Überschriftenstruktur über die Tastaturnavigation bis hin zur Theme-Auswahl und automatisierten Prüfungen. Kein Ballast, nur das, was Sie heute umsetzen können. 💡 Kurzüberblick:

Wahrnehmbarkeit prüfen: aussagekräftiger Alternativtext für jedes Bild, aria-label für Icons, eindeutiger Ankertext für jeden Link.
Ein Kontrastverhältnis von 4,5:1 für normale Schrift und 3:1 für große Schrift erreichen, geprüft mit dem WebAIM Contrast Checker.
Eine Überschriftenhierarchie aufbauen: eine H1 pro Seite, dann H2 und H3 ohne übersprungene Ebenen.
Tastaturzugänglichkeit sicherstellen: Alles, was mit der Maus klickbar ist, muss per Tab und Enter funktionieren.
Formulare prüfen: ein explizites Label für jedes Eingabefeld; ein Platzhalter ist kein Ersatz für eine Beschreibung.
WAVE oder Lighthouse einsetzen: Ein automatisierter Audit findet die meisten Probleme in einer halben Minute.

Was Web-Barrierefreiheit ist und warum sie 2026 verpflichtend ist

Web-Barrierefreiheit bedeutet, Websites so zu gestalten und zu entwickeln, dass sie von Menschen mit jeglichen körperlichen und kognitiven Fähigkeiten genutzt werden können. Screenreader für blinde Nutzer, Tastaturnavigation für Menschen mit motorischen Einschränkungen, ausreichender Kontrast für sehbehinderte Nutzer, Untertitel für gehörlose Nutzer.

Der De-facto-Standard ist WCAG 2.2 (Web Content Accessibility Guidelines) des W3C-Konsortiums. Drei Stufen: A (Minimum), AA (das Ziel für die meisten) und AAA (höchste). Die EU- und US-Gesetzgebung fordert Stufe AA.

Der European Accessibility Act (EU-Richtlinie 2019/882) trat am 28. Juni 2025 in Kraft und erfasst E-Commerce, Bankwesen, Verkehr und Medien. In Deutschland gilt parallel das BFSG. Die Bußgelder variieren: bis zu 100.000 € in Deutschland, bis zu 250.000 € in Frankreich. WordPress-Seiten gewerblicher Unternehmen fallen direkt unter die Regelung.

Wahrnehmbarkeit: Wie Sie Inhalte für Screenreader verständlich machen

Der Ausgangspunkt für Barrierefreiheit: Informationen müssen so dargeboten werden, dass der Nutzer sie über mindestens einen Kanal wahrnehmen kann: Sehen, Hören, Tasten.

Bilder und Alternativtext. Jedes img-Tag muss ein alt-Attribut haben. Bei aussagekräftigen Bildern eine Beschreibung dessen, was darauf geschieht (5-8 Wörter, ohne „Bild" oder „Foto"). Bei dekorativen Bildern alt="" (leer, aber vorhanden). Der Screenreader überspringt ein leeres alt und lenkt den Nutzer nicht ab.

1 /* functions.php — forced alt for post thumbnails */
2 add_filter('wp_get_attachment_image_attributes', function($attr, $attachment) {
3     if (empty($attr['alt'])) {
4         $attr['alt'] = get_the_title($attachment->ID);
5     }
6     return $attr;
7 }, 10, 2);

Leere Links und Schaltflächen. Ein Lupen-Icon ohne Text ist für einen Screenreader ein Rätsel. Fügen Sie Icon-Schaltflächen immer ein aria-label hinzu:

1 <button aria-label="Open search">
2     <span class="dashicons dashicons-search"></span>
3 </button>

Title-Attribute. Nützlich für zusätzlichen Kontext, aber duplizieren Sie darin nicht den Linktext; der Screenreader würde dasselbe zweimal vorlesen. WordPress dupliziert standardmäßig den Linktext im title; das sollte deaktiviert werden.

Farbkontrast: Grundwerte und Prüfwerkzeuge

Ungenügender Kontrast zwischen Text und Hintergrund ist das am weitesten verbreitete Problem. Laut WebAIM Million 2025 wurde auf 81% der gescannten Seiten ein zu geringer Kontrast festgestellt.

Mindestanforderungen WCAG 2.2 AA:

Normale Schrift (kleiner als 18pt): Kontrast 4,5:1
Große Schrift (18pt und größer oder 14pt fett): Kontrast 3:1
Icons und UI-Elemente: Kontrast 3:1

Prüfen Sie das in einer Minute mit dem WebAIM Contrast Checker: Geben Sie die Text- und Hintergrundfarben in HEX ein und erhalten Sie ein Urteil: Bestanden / Nicht bestanden für jede Stufe.

Typische Problemzonen in WordPress: graue Schrift auf weißem Hintergrund im Footer, helle Schaltflächen mit weißer Beschriftung, Text über Fotos ohne abdunkelnde Überlagerung. Behebung durch CSS-Anpassung, meist indem der Text um ein paar Nuancen abgedunkelt wird.

Überschriftenstruktur: Eine Hierarchie, die jeder versteht

Screenreader erstellen aus Überschriften ein „Inhaltsverzeichnis" der Seite; der Nutzer springt durch H2- und H3-Überschriften und umgeht die Navigation. Ist die Hierarchie gestört, bricht die Navigation.

Regeln:

Eine H1 pro Seite, üblicherweise der Beitragstitel
H2 für Hauptabschnitte, H3 für Unterabschnitte innerhalb einer H2
Überschriften überspringen keine Ebenen: H2 → H4 (unter Auslassung von H3) ist ein Fehler
Verwenden Sie h*-Tags nicht nur für die Schriftgröße; nutzen Sie dafür CSS

Ein typisches Problem in WordPress: Plugins und Themes, die H2/H3 für eigene Blöcke einfügen (Slider mit Überschrift, Anmeldeformular, Sidebar-Widgets). Drei Lösungen: die Tag-Einstellung im Plugin finden, die Ausgabe per Filter anpassen oder zu einem sorgfältigeren Plugin wechseln. Eine gestörte Hierarchie in Kauf zu nehmen, „weil es gut aussieht", ist keine Option.

HTML5-Landmarks geben dem Screenreader eine Karte der Seite. Vier zentrale Tags: header für den Kopfbereich, nav für die Navigation, main für den Hauptinhalt und footer für den Fußbereich. Der Nutzer drückt eine Tastenkombination und springt direkt zum Hauptinhalt.

1 <header role="banner">
2 <nav role="navigation">
3 <main role="main">
4 <footer role="contentinfo">

Die Rolle role="main" muss genau einmal pro Seite vorkommen. Die meisten modernen WordPress-Themes setzen diese Tags standardmäßig ein; prüfen Sie dies mit WAVE: Der Abschnitt „Structure" zeigt alle Landmarks an.

Ein weiteres erforderliches Element, „Zum Inhalt springen", ist ein unsichtbarer Link als erstes Element der Seite, der Nutzern erlaubt, das Menü zu überspringen und direkt zum Inhalt zu gelangen. In WordPress wird er über einen Filter oder ein Barrierefreiheits-Plugin eingefügt.

Formulare ohne Barrieren

Kontaktformular, Newsletter-Anmeldung, Checkout: Jedes Feld muss beschriftet und per Tastatur erreichbar sein.

*Jedes input benötigt sein eigenes label (explizit oder via aria-label):*

1 <label for="user-email">Email</label>
2 <input id="user-email" name="email" type="email">

Ein Platzhalter ersetzt kein Label; er verschwindet bei der Eingabe und wird von Screenreadern schlecht vorgelesen. Verwenden Sie placeholder nur als Formathinweis, nicht als Feldbezeichnung.

Gruppierung: Fassen Sie Radio-Buttons und Checkboxen in einem <fieldset> mit einer <legend> zusammen. Pflichtfelder: Kennzeichnen Sie diese mit dem Text „(erforderlich)", nicht nur mit einem Sternchen oder einer Farbe.

Tastaturnavigation: Ihre Seite ohne Maus

Manche Nutzer verwenden nie eine Maus: Tremor, Spastik, Lähmungen. Alles muss per Tab, Shift+Tab, Enter, Escape und den Pfeiltasten funktionieren.

Schnelltest: Öffnen Sie die Seite und navigieren Sie ausschließlich mit der Tab-Taste. Jedes interaktive Element muss eine sichtbare Fokusmarkierung erhalten. Ein Modal muss sich mit Escape schließen lassen. Ein Dropdown-Menü muss sich mit Enter öffnen.

Typische Fehler bei WordPress-Seiten:

Eigene Dropdowns ohne tabindex und aria-expanded
outline: none im CSS (entfernt die Fokusmarkierung; tun Sie das nicht)
Endlose Fokusfalle in Popups
Slider, die nicht per Tastatur bedienbar sind

Deaktivieren Sie niemals den standardmäßigen :focus-Stil vollständig. Wenn Ihnen der Browser-Outline nicht gefällt, ersetzen Sie ihn durch einen eigenen :focus-visible-Stil mit einem kontrastreichen Ring.

Zoom: Verhindern Sie nicht, dass Nutzer Text vergrößern

Viele mobile Versionen von WordPress-Seiten blockieren das Pinch-Zoom über ein Meta-Tag:

1 <!-- INCORRECT — do not do this -->
2 <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
3  
4 <!-- CORRECT -->
5 <meta name="viewport" content="width=device-width, initial-scale=1">

Die WCAG 2.2 verlangt die Möglichkeit, auf 200% zu zoomen, ohne Verlust von Inhalt oder Funktionalität; dies ist das Erfolgskriterium 1.4.4. Prüfen Sie, ob Text beim Zoomen abgeschnitten wird oder andere Blöcke überlappt.

WordPress-Themes und Barrierefreiheit: Worauf Sie bei der Auswahl achten sollten

Kein Theme ist „out of the box vollständig barrierefrei", zu viel hängt von Inhalten und Einstellungen ab. Aber die Ausgangsbasis ist entscheidend.

Achten Sie bei der Theme-Auswahl auf Folgendes:

Die Beschreibung enthält den Hinweis „accessibility ready", das ist ein Tag auf WordPress.org, der grundlegende Konformität mit den Anforderungen signalisiert
Korrekte HTML5-Struktur mit Landmarks
Navigationsmenüs als natives <nav> mit <ul>, nicht als Div-Konstruktion mit JS
Vorhandensein von :focus-Stilen für Links und Buttons
Kein maximum-scale=1.0 im Viewport

Die Standard-WordPress-Themes (Twenty Twenty-Four, Twenty Twenty-Five) sind ein solider Ausgangspunkt. Kommerzielle Themes mit visuellen Buildern sind eine Risikozone: Je mehr visuelle „Magie", desto höher die Wahrscheinlichkeit einer mangelhaften Barrierefreiheit.

Werkzeuge für die Prüfung: vom Schnellcheck zum professionellen Test

WAVE Evaluation Tool. Eine Browser-Erweiterung WAVE von WebAIM, die Icons direkt auf der Seite einblendet: rot für Fehler, gelb für Warnungen, grün für in Ordnung. Ideal für eine erste Prüfung. Sie zeigt Kontraste, Alternativtexte, Überschriftenstruktur und ARIA-Attribute an.

Google Lighthouse. In Chrome DevTools integriert (F12 → Lighthouse → Barrierefreiheit). Liefert eine numerische Bewertung von 0-100 und eine Liste konkreter zu behebender Elemente. Praktisch für die regelmäßige Überwachung.

Accessibility Checker (Equalize Digital). Ein WordPress-Plugin, Accessibility Checker prüft Inhalte direkt im Editor (Gutenberg und Classic). Die kostenlose Version scannt einen Beitrag vor der Veröffentlichung, Pro ergänzt einen vollständigen Site-Audit.

WP Accessibility. Ein Veteran unter den Barrierefreiheits-Plugins, WP Accessibility von Joe Dolson. Es fügt Skip-Links und ARIA-Landmarks hinzu, entfernt doppelte Link-Title-Attribute, korrigiert :focus-Stile, entfernt tabindex aus Formularen und target aus Links. Kein Allheilmittel, aber es schließt ein Dutzend typischer Probleme auf einen Schlag.

One Click Accessibility. Ein Plugin mit einer Toolbar, One Click Accessibility erlaubt dem Nutzer, Kontrast umzuschalten, die Schriftgröße zu erhöhen und Links eigenständig zu unterstreichen. Das ist kein Ersatz für native Barrierefreiheit, sondern eine zusätzliche Ebene für diejenigen, die spezifische Einstellungen benötigen.

NVDA. Ein kostenloser Screenreader für Windows, NVDA. Gehen Sie Ihre Seite bei ausgeschaltetem Monitor durch. Sie hören, was ein blinder Nutzer hört. VoiceOver (in macOS/iOS integriert) ist das Äquivalent für das Apple-Ökosystem.

Zehn Schritte zu einer barrierefreien WordPress-Site

Hier die destillierte Essenz aus dem gesamten Leitfaden, eine Checkliste. Gehen Sie sie nach jedem Redesign oder neuen Projekt-Launch durch.

Schreiben Sie Alternativtexte für jedes Bild. Füllen Sie in der WordPress-Mediathek das Feld „Alternativer Text" aus. Verwenden Sie für dekorative Bilder alt="".
Beschreiben Sie Links. Der Linktext sollte vermitteln, wohin er führt. „Hier klicken" und „Weiterlesen" sind schlechte Anker. „Das Accessibility-Checker-Plugin herunterladen" ist ein guter.
Ordnen Sie Überschriften hierarchisch. Eine H1, dann H2 und H3 innerhalb von H2. Prüfen Sie in WAVE: Struktur → Überschriftenstruktur.
Bringen Sie den Kontrast auf 4,5:1. Lassen Sie den WebAIM Contrast Checker über die Hauptfarben des Themes laufen: Text, Überschriften, Buttons, Links, Footer.
Aktivieren Sie sichtbaren Fokus. Stellen Sie sicher, dass :focus nicht ohne Ersatz auf outline: none gesetzt ist. Individueller Fokus wird über :focus-visible realisiert.
Prüfen Sie die Tastaturnavigation. Tabben Sie durch alle Links und Buttons, Enter zum Aktivieren, Escape zum Schließen von Modalen. Wenn Sie stecken bleiben, ist das ein Fehler.
Beschriften Sie Formulare. Jedes Feld benötigt sein eigenes <label>. Pflichtfelder brauchen einen Textindikator. Gruppen gehören in ein <fieldset>.
Unterbinden Sie den Zoom nicht. Viewport ohne maximum-scale und user-scalable=no. Prüfen Sie bei 200% Zoom, Inhalte dürfen nicht abgeschnitten werden.
Fügen Sie einen Skip-Link hinzu. Ein „Zum Inhalt springen"-Link als erstes Element des <body>. WP Accessibility erledigt das automatisch.
Führen Sie WAVE oder Lighthouse aus. Ein automatisierter Audit ersetzt keinen manuellen Test, findet aber die allermeisten Probleme in einer Minute.

⁉️🤔 Häufige Fragen

Muss meine WordPress-Website die WCAG einhalten?

Wenn Ihre Website ein Unternehmen in der EU repräsentiert, ja, ab Juni 2025. Der European Accessibility Act erfasst E-Commerce, Finanzwesen, Verkehr und Medien. In den USA gelten ähnliche Anforderungen: ADA und Section 508 für Behörden und deren Auftragnehmer. Ein privater Blog ist formal nicht zur Einhaltung verpflichtet, aber ein erheblicher Anteil der Nutzer hat Einschränkungen, ein starkes kommerzielles Argument.

Ja, kommerzielle Websites in der EU müssen ab dem 28. Juni 2025 gemäß dem European Accessibility Act WCAG 2.2 AA einhalten. Die Bußgelder werden von den Mitgliedstaaten festgelegt: Die Beträge können je nach Rechtsordnung Hunderttausende Euro erreichen. In den USA gelten über den ADA und Section 508 ähnliche Anforderungen. Für private, nicht-kommerzielle Blogs besteht keine gesetzliche Pflicht, aber Barrierefreiheit vergrößert die Reichweite.

Reicht die Installation eines Plugins wie One Click Accessibility aus?

Ein Toolbar-Plugin ist eine unterstützende Ebene, keine Lösung. Es ermöglicht dem Nutzer, Kontrast oder Schriftgröße zu ändern, behebt aber keine fehlenden Alternativtexte, keine fehlerhafte Überschriftenhierarchie und keine per Tastatur unzugänglichen Popups. Beginnen Sie mit nativer Barrierefreiheit in Code und Inhalt, fügen Sie die Toolbar als letzten Feinschliff hinzu.

Nein. Eine Toolbar (One Click Accessibility, UserWay) ist nur ein zusätzliches „Overlay". Sie ersetzt keine native Barrierefreiheit: Sie behebt keine Alternativtexte, Überschriftenhierarchien, Tastaturfallen oder unbeschriftete Formularfelder. Beginnen Sie mit der Behebung von Code und Inhalt, die Toolbar ist der letzte Schliff.

Wie teste ich eine Website, ohne teure Tools zu kaufen?

Ein vollständiger Zyklus mit kostenlosen Werkzeugen: WAVE Extension (erster Schnellscan) → Google Lighthouse (numerischer Score und Fehlerliste) → manueller Tastaturdurchlauf (Tab/Enter/Escape) → NVDA unter Windows oder VoiceOver auf dem Mac (die Website bei ausgeschaltetem Monitor durchgehen). Das genügt, um die allermeisten Probleme zu adressieren.

Kostenloser Zyklus: WAVE Extension für den Browser → Google Lighthouse in den Chrome DevTools → manueller Tastaturdurchlauf → NVDA (Windows) oder VoiceOver (macOS/iOS) für den Screenreader-Test. Diese vier Werkzeuge decken 90% der Aufgaben ab. Kostenpflichtige Dienste sind nur für regelmäßige Audits großer Projekte erforderlich.

Kann eine mit einem visuellen Builder (Elementor, WPBakery) erstellte Website barrierefrei gemacht werden?

Das ist möglich, aber aufwändiger. Builder generieren HTML dynamisch, und einige Widgets durchbrechen die Überschriftenhierarchie oder fügen div-Wrapper ohne Semantik ein. Prüfen Sie jeden Block einzeln mit WAVE. Elementor Pro Version 3.15+ hat Einstellungen für ARIA-Attribute bei Widgets hinzugefügt, nutzen Sie diese.

Das ist möglich, erfordert aber mehr manuelle Arbeit. Visuelle Builder neigen dazu, die Überschriftenhierarchie zu durchbrechen und übermäßig viele div-Wrapper zu erzeugen. Prüfen Sie das Ergebnis nach jeder Änderung mit WAVE. Elementor Pro (3.15+) erlaubt das Setzen von ARIA-Attributen für Widgets, was das Problem teilweise löst.

Wie oft sollte ich die Barrierefreiheit einer Website erneut prüfen?

Nach jedem größeren Update: ein neues Theme, ein neues Plugin, ein Redesign, eine umfangreiche Inhaltsveröffentlichung. Mindestzyklus: Einmal pro Quartal Lighthouse ausführen und die wichtigsten Seiten mit der Tastatur durchgehen. Automatisiertes Monitoring per Accessibility Checker Pro ist für Websites mit regelmäßigen Inhalten gerechtfertigt.

Mindestens nach jeder größeren Änderung (Theme-Wechsel, neues Plugin, Redesign) und quartalsweise als vorbeugende Maßnahme. Für Websites mit regelmäßigen Veröffentlichungen ist automatisiertes Monitoring per Accessibility Checker Pro gerechtfertigt. Ein Screenreader-Test ist einmal alle sechs Monate ausreichend, wenn sich die Codebasis nicht geändert hat.

Was Sie jetzt für die Barrierefreiheit Ihrer WordPress-Website tun sollten

Warten Sie nicht auf den perfekten Zeitpunkt. WCAG 2.2 AAA ist ein Ziel, kein Ausgangspunkt. Beginnen Sie noch heute mit drei Maßnahmen:

Lassen Sie WAVE über Ihre Startseite laufen. Beheben Sie die roten Fehler (in der Regel 5 bis 10), sie beseitigen die schwerwiegendsten Barrieren.
Navigieren Sie die Website mit der Tastatur. Tab, Tab, Tab. Wenn Sie steckenbleiben, beheben Sie es. Wenn der Fokus nicht sichtbar ist, fügen Sie :focus-visible hinzu.
Prüfen Sie den Kontrast von drei Farben: Textfarbe, Schaltflächenfarbe, Linkfarbe. Bringen Sie sie auf 4,5:1.

Diese drei Schritte, eine halbe Stunde Arbeit, und der Löwenanteil des Ergebnisses. Den Rest, Plugins, Screenreader, ARIA, gehen Sie schrittweise an.

Wenn die Website kommerziell ist und in der EU betrieben wird, schieben Sie es nicht auf. Der EAA gibt den Aufsichtsbehörden ab 2025 echte Handhabe. Es ist besser, einem Audit mit einem grünen Lighthouse-Score entgegenzutreten als mit einem Schreiben einer Regulierungsbehörde.

♿ Barrierefreiheit von WordPress-Websites: ein vollständiger Leitfaden 2026