DE
English
Français
Español
ItalianoRund 41,5 Prozent aller Websites laufen auf WordPress, kein anderes System kommt auch nur in die Nähe (W3Techs, Stand Juli 2026). Für die Barrierefreiheit ist das eine gute Nachricht: WordPress bringt vieles mit, was zugängliche Seiten brauchen, vom sauberen HTML des Block-Editors bis zum Alt-Text-Feld in der Mediathek. Es garantiert aber nichts davon. Ob eine WordPress-Site zugänglich ist, hängt an Theme-Wahl, Plugins und Redaktionsalltag. Dieser Guide zeigt die Hebel, auf dem Stand von 2026: mit WCAG 2.2 als Ziel statt der 2.1 von vorgestern. Wo Ihre Site heute steht, klärt der Scan in zwei Minuten.
Website-Check
Scannt Ihre WordPress-Site gegen WCAG 2.2 und zeigt jeden Verstoß mit Fundstelle. Aus dem diffusen Thema wird eine Arbeitsliste. Kostenlos, ohne Anmeldung.
Warum WordPress-Barrierefreiheit 2026 anders aussieht
Die meisten Anleitungen zu barrierefreiem WordPress, die Sie heute finden, wurden für WCAG 2.1 geschrieben. Das war lange in Ordnung, ist aber überholt: Seit Oktober 2023 ist WCAG 2.2 die aktuelle Empfehlung des W3C, und die revidierte EN 301 549, die europäische Norm hinter BFSG und European Accessibility Act, wird mit Bezug auf WCAG 2.2 AA für 2026 erwartet. Wer jetzt saniert, zielt also besser direkt auf 2.2, sonst steht die nächste Runde schon fest. Was hinter den Konformitätsstufen A, AA und AAA steckt, erklärt unser Ratgeber zur WCAG-Konformität.
Für die Praxis heißt das: Prüfen Sie jede Anleitung, der Sie folgen, auf ihr Datum. Ein Tutorial von 2021 ist nicht falsch, aber unvollständig, und die Lücke betrifft genau die Kriterien, die ab 2026 in der Norm stehen dürften. Dieser Artikel arbeitet deshalb durchgehend mit WCAG 2.2 auf Stufe AA als Zielmarke.
Der Sprung von 2.1 auf 2.2 ist kein Neuanfang, sondern eine Handvoll neuer Erfolgskriterien. Sechs davon treffen typische WordPress-Muster ziemlich genau:
| Kriterium | Was es verlangt | Wo es in WordPress typisch klemmt |
|---|---|---|
| 2.4.11 Fokus nicht verdeckt | Das fokussierte Element darf nicht vollständig von anderen Inhalten verdeckt sein | Sticky-Header und Cookie-Banner, die den Tastaturfokus überlagern |
| 2.5.7 Ziehbewegungen | Drag-Interaktionen brauchen eine Alternative, die ohne Ziehen funktioniert | Slider und Karussells, die nur auf Wischen oder Ziehen reagieren |
| 2.5.8 Zielgröße (Minimum) | Bedienelemente mindestens 24x24 CSS-Pixel groß oder mit genug Abstand | Social-Icons, Paginierungs-Punkte und winzige Schließen-Buttons |
| 3.2.6 Konsistente Hilfe | Hilfe-Angebote wie Kontakt oder Chat auf jeder Seite an derselben Stelle | Ein Kontakt-Link, der je nach Template mal im Header, mal im Footer sitzt |
| 3.3.7 Redundante Eingabe | Bereits eingegebene Daten nicht im selben Vorgang erneut abfragen | Checkout, der die Rechnungsadresse noch einmal als Lieferadresse abtippen lässt |
| 3.3.8 Barrierefreie Authentifizierung | Login ohne kognitive Rätsel wie das Abtippen verzerrter Zeichen | Captcha-Plugins am Login- und Kommentarformular |
Auffällig an dieser Liste: Das meiste davon liegt im Theme oder in Plugins, nicht in Ihren Texten. Verantwortlich bleiben trotzdem Sie als Betreiber. Ein Scan misst Ihre Website, nicht die guten Absichten Ihres Theme-Entwicklers. Prüfen Sie deshalb nach jedem größeren Update, ob ein Plugin eines dieser Muster neu eingeschleppt hat.
Der Rechtsrahmen in drei Sätzen
Wenn Ihre WordPress-Site nur informiert, schreibt Ihnen in Deutschland derzeit kein Gesetz Barrierefreiheit vor; sie bleibt trotzdem eine gute Idee, weil jede Barriere Besucher kostet. Sobald Sie über die Site verkaufen, buchen oder Verträge abschließen lassen, typischerweise mit WooCommerce oder einem Buchungs-Plugin, greift seit Ende Juni 2025 das Barrierefreiheitsstärkungsgesetz, samt Behördenkontrollen und Bußgeldern. Wen das Gesetz genau erfasst und welche Ausnahmen wirklich gelten, steht im BFSG-Ratgeber.
WooCommerce heißt: Sie betreiben einen Onlineshop
Mit WooCommerce oder einem Buchungs-Plugin wird Ihre WordPress-Site rechtlich zur Dienstleistung im elektronischen Geschäftsverkehr, mit allen Pflichten vom Checkout bis zur Barrierefreiheitserklärung. Die Details für Shop-Betreiber, von der Kleinstunternehmen-Ausnahme bis zur B2B-Falle, sammelt der Ratgeber zum BFSG im Onlineshop.
Das Fundament: ein Theme, das nicht gegen Sie arbeitet
Barrierefreiheit beginnt in WordPress vor dem ersten Inhalt, nämlich bei der Theme-Wahl. Das Theme bestimmt Farbkontraste, Fokus-Darstellung, Skip-Links und die HTML-Struktur, die jede einzelne Seite erbt. Ein sinnvoller Startpunkt ist das offizielle Theme-Verzeichnis mit dem Filter accessibility-ready: rund hundert Themes, die eine Prüfung auf definierte Mindeststandards durchlaufen haben, statt zehntausender ungeprüfter.
„accessibility-ready“ heißt geprüft, nicht fertig
Das Tag garantiert Mindeststandards, keine volle WCAG-Konformität. Und es repariert nichts, was danach passiert: Ein einziges Plugin mit unbeschrifteten Buttons oder ein Customizer-Ausflug zu blassen Farben untergräbt das geprüfte Fundament sofort wieder. Behandeln Sie das Tag als Eintrittskarte, nicht als Abschlusszeugnis.
Premium-Themes außerhalb des Verzeichnisses tragen kein solches Tag. Dort helfen drei schnelle Tests direkt in der Demo, bevor Sie kaufen: Sind die Standardfarben ausreichend kontrastreich? Bleibt beim Durch-Tabben mit der Tastatur jederzeit sichtbar, wo der Fokus gerade steht? Und führt die erste Tab-Station über einen Skip-Link direkt zum Inhalt? Zehn Minuten Demo-Test ersparen Wochen an Flickarbeit im Live-Betrieb.
Die acht Baustellen im WordPress-Alltag
Mit dem Theme ist das Fundament gelegt, danach entscheidet die tägliche Arbeit im Editor. Diese acht Punkte decken den Großteil dessen ab, was auf WordPress-Sites regelmäßig schiefgeht:
- Theme-Basis prüfen: Kontraste, sichtbarer Fokus, Skip-Link (siehe oben). Wer hier spart, kämpft an allen folgenden Punkten gegen das eigene Fundament.
- Überschriften als Struktur begreifen: Im Block-Editor ist eine H2 eine Gliederungsebene, kein Schriftgrad. Ebenen nicht überspringen und keine H4 wählen, weil sie hübscher aussieht.
- Alt-Texte in der Mediathek pflegen: Jedes informative Bild bekommt einen Alternativtext, rein dekorative Bilder bleiben bewusst leer, damit Screenreader sie überspringen.
- Formular-Plugins mit echten Labels wählen: Ein Platzhalter im Feld ist kein Label. Die Beschriftung muss programmatisch am Feld hängen und darf beim Tippen nicht verschwinden.
- Kontraste nach jeder Farbänderung prüfen: Das zarte Grau auf Weiß, das im Customizer edel wirkt, fällt im Scan als Erstes durch.
- Tastatur-Test einplanen: Mit Tab durch die wichtigsten Seiten. Ist jedes Menü, jeder Button, jedes Feld erreichbar, und kommen Sie überall auch wieder heraus?
- Skip-Link kontrollieren: Der erste Tab-Stopp sollte ein Link direkt zum Inhalt sein. Accessibility-ready-Themes bringen ihn mit, viele andere nicht.
- Automatische Slider vermeiden oder pausierbar machen: Ein Karussell, das selbstständig weiterblättert, braucht mindestens eine Pause-Funktion. Oft ist die bessere Lösung, es ersatzlos zu streichen.
Zwei dieser Punkte verdienen einen zweiten Blick. Zuerst die Formulare: Ein unbeschriftetes Feld ist für Screenreader-Nutzer ein Blindflug, sie hören „Eingabefeld“ und sonst nichts. Ob Kontaktformular oder Checkout, tabben Sie einmal mit der Tastatur durch Ihr Formular-Plugin. Dann zeigt sich schnell, ob die Labels wirklich am Feld hängen oder nur optisch daneben stehen.
Der zweite Blick gilt den Alt-Texten, in der Praxis fast immer der größte Einzelposten. WordPress macht es leicht, sie zu vergessen: Das Feld in der Mediathek ist unscheinbar, und die Seite sieht auch ohne perfekt aus. Für Screenreader-Nutzer bedeutet ein fehlender Alt-Text dagegen: Hier ist ein Bild, und niemand verrät, was es zeigt. Wie gute Alternativtexte aussehen, beschreibt das Bild-Tutorial des W3C; bei hunderten Bestandsbildern lohnt ein Generator für den ersten Entwurf.
Alt-Text-Generator
Findet Bilder ohne Alt-Text und schlägt Formulierungen als Entwurf vor. Sie prüfen jeden Text gegen den Seitenkontext, passen an und übernehmen.
Plugins: was wirklich hilft und was nur beruhigt
Nützlich sind Plugins, die beim Erstellen prüfen: Sie warnen im Editor vor fehlenden Alt-Texten oder übersprungenen Überschriften-Ebenen, bevor der Beitrag live geht. Solche Prüf-Helfer verlagern die Qualitätssicherung an die richtige Stelle, nämlich vor die Veröffentlichung. Was es dagegen nicht gibt: das Plugin, das eine Website automatisch konform macht. Konformität entsteht aus Theme, Inhalten und Arbeitsroutinen, und keine dieser drei Zutaten lässt sich installieren.
Besonders skeptisch sollten Sie bei Overlay-Plugins sein, die per Skript ein Bedienfeld einblenden und Barrierefreiheit auf Knopfdruck versprechen. Sie können Besuchern Anzeige-Komfort bieten, mehr nicht: Unbeschriftete Formulare, kaputte Tastaturpfade und fehlende Alt-Texte bestehen darunter unverändert weiter. Warum das technisch so ist und wie Fachwelt und Behörden Overlays einordnen, steht im Ratgeber zu Accessibility-Overlays.
Testen: erst automatisch, dann von Hand
Ein automatischer Scan ist der richtige Einstieg, weil er die maschinell erkennbaren Verstöße zuverlässig und wiederholbar findet: zu schwache Kontraste, fehlende Alt-Texte, unbeschriftete Felder. Genau diese Fehler sieht auch jeder andere zuerst, der Ihre Site mit einem Tool prüft. Der Scan ist aber nicht das Ende: Ob ein Alt-Text inhaltlich passt oder das Menü zur Tastaturfalle wird, erkennt nur ein Mensch.
- Mit Tab durch Startseite, eine Inhaltsseite und das wichtigste Formular: alles erreichbar, Fokus jederzeit sichtbar?
- Skip-Link: Führt der erste Tab-Stopp wirklich zum Inhalt?
- Slider und Animationen: pausierbar, und geht die Bedienung auch ohne Ziehen?
- Fünf Bilder als Stichprobe: Sagt der Alt-Text, was das Bild an dieser Stelle leisten soll?
- Formular mit Absicht falsch ausfüllen: Wird der Fehler als Text erklärt und nicht nur rot eingefärbt?
Planen Sie das Ganze als Routine, nicht als einmalige Aktion. WordPress-Sites ändern sich ständig: ein neues Plugin, ein Theme-Update, ein neuer Redakteur, und schon steht ein winziger Button oder ein Bild ohne Alt-Text auf der Startseite. Ein wiederkehrender Scan fängt solche Rückschritte ab, bevor Besucher oder Prüfer sie finden.
Für die Farbfragen brauchen Sie dabei kein Bauchgefühl. Kontrast ist ein Messwert mit klaren Grenzwerten, und die lassen sich in Sekunden prüfen.
Kontrast-Checker
Prüft in Sekunden, ob Ihre Farbkombinationen die WCAG-Grenzwerte erfüllen. Ideal nach jeder Farbanpassung im Customizer.
Häufige Fragen zu WordPress und Barrierefreiheit
Ist ein Theme mit dem Tag „accessibility-ready“ automatisch barrierefrei?
Nein. Das Tag bestätigt, dass das Theme eine Prüfung auf definierte Mindeststandards bestanden hat, keine vollständige WCAG-Konformität. Es ist die beste Startposition, die das Theme-Verzeichnis bietet, ersetzt aber weder gepflegte Inhalte noch geprüfte Plugins. Ein accessibility-ready-Theme plus fehlende Alt-Texte ergibt trotzdem eine Site mit Barrieren.
Gibt es ein Plugin, das meine Site barrierefrei macht?
Nein, und Vorsicht vor jedem Anbieter, der genau das verspricht. Plugins können beim Prüfen helfen, etwa mit Hinweisen im Editor vor der Veröffentlichung. Die Konformität selbst entsteht in Theme, Inhalten und Prozessen. Overlay-Plugins mit Knopfdruck-Versprechen ändern an den zugrunde liegenden Fehlern nichts; die Belege dazu stehen in unserem Overlay-Ratgeber.
Meine Site erfüllt WCAG 2.1 AA. Muss ich jetzt auf 2.2 umstellen?
Sie sind gut aufgestellt, fertig sind Sie nicht. WCAG 2.2 ist seit Oktober 2023 die aktuelle W3C-Empfehlung, und die revidierte EN 301 549 mit Bezug auf 2.2 AA wird für 2026 erwartet. Die neuen Kriterien, etwa Mindest-Zielgröße und nicht verdeckter Fokus, sind überschaubar. Wer sie jetzt einplant, erspart sich die zweite Sanierungsrunde.
Gilt das BFSG für meine WordPress-Site?
Nur wenn die Site eine erfasste Dienstleistung anbietet, allen voran Verkauf oder Buchung an Verbraucher, etwa über WooCommerce. Eine reine Info-Site ohne Shop und Buchung fällt in der Regel nicht darunter. Die genauen Kriterien samt Kleinstunternehmen-Ausnahme erklärt unser BFSG-Ratgeber, die Shop-Praxis der Onlineshop-Ratgeber.
Woran erkenne ich ein brauchbares Formular-Plugin?
Am einfachsten im Test: Bauen Sie ein Formular und tabben Sie mit der Tastatur hindurch. Hat jedes Feld eine Beschriftung, die programmatisch am Feld hängt und beim Tippen sichtbar bleibt? Werden Fehlermeldungen als Text ausgegeben und nicht nur farblich markiert? Dann taugt das Plugin. Platzhalter als einzige Beschriftung sind das Ausschlusskriterium.
Braucht wirklich jedes Bild einen Alt-Text?
Jedes informative Bild ja, dekorative gerade nicht: Die bekommen ein leeres Alt-Attribut, damit Screenreader sie überspringen. Die Faustregel: Ginge beim Weglassen des Bildes Information verloren? Dann beschreibt der Alt-Text genau diese Information, kurz und im Kontext der jeweiligen Seite.
Reicht ein automatischer Scan, um auf der sicheren Seite zu sein?
Nein. Der Scan findet die maschinell messbaren Verstöße zuverlässig, und das sind die, die auch fremde Prüf-Tools zuerst sehen. Ob Alt-Texte inhaltlich stimmen, die Tastaturbedienung durchgehend funktioniert und Abläufe verständlich sind, prüfen Sie zusätzlich von Hand. Die Kombination aus beidem ist der realistische Weg.
WordPress steht Barrierefreiheit nicht im Weg, es wartet nur auf Anweisungen: Das Alt-Text-Feld existiert, die Überschriften-Ebenen existieren, geprüfte Themes existieren. Was meist fehlt, ist der Überblick, wo die eigene Site konkret hakt. Genau den liefert der Scan vom Anfang dieses Artikels: zwei Minuten, eine priorisierte Arbeitsliste, und aus dem vagen Vorhaben wird ein Projekt mit einem Ende.
Rechtlicher Hinweis
Dieser Artikel dient der allgemeinen Information und stellt keine Rechtsberatung dar. Für verbindliche Auskünfte zu Ihrem Einzelfall wenden Sie sich bitte an eine Anwältin oder einen Anwalt. Stand: Juli 2026.
Autor
Redaktion accessibility-check.ai