WordPress auf Barrierefreiheit testen: Theme, redaktionelle Inhalte und Erweiterungen auseinanderhalten
6 Min. Lesezeit · DACH
Bei einem WordPress-Auftritt ist die erste Frage nach einem Befund nicht, wie man ihn behebt, sondern wer ihn verursacht hat. Dieselbe fehlende Beschriftung kann aus dem Theme kommen, aus einem Beitrag, den jemand im Editor geschrieben hat, oder aus einer Erweiterung, die ein Formular ausgibt. Wer das nicht trennt, repariert an der falschen Stelle, und beim nächsten Update ist der Befund wieder da. Dieser Artikel beschreibt das Vorgehen; er gilt unabhängig vom Land und ist keine Rechtsberatung.
Redaktion Zugangscheck, veröffentlicht am . Wer dahintersteht
Keine Rechtsberatung. Quellen am Ende des Artikels.
Drei Quellen, drei Zuständigkeiten
Woher ein Befund in einem WordPress-Auftritt stammen kann und wer ihn behebt
| Quelle | Typische Befunde | Behoben von |
|---|---|---|
| Theme | Überschriftenfolge im Gerüst, Kontraste der Farbpalette, Fokusring, Navigation, Sprungmarke zum Inhalt, Fusszeile | Wer das Theme pflegt; bei einem gekauften Theme: melden, Kindtheme oder Ersatz |
| Redaktionelle Inhalte | Fehlende Alternativtexte, Überschriften als fetter Text, Linktexte wie «hier», Tabellen ohne Kopfzeile, eingebettete Videos ohne Untertitel | Die Redaktion, im Editor, ohne eine Zeile Code |
| Erweiterungen | Formulare ohne Beschriftung, Bildergalerien ohne Tastaturbedienung, Einwilligungsfenster, Schieberegler, Chatfenster | Wer die Erweiterung ausgewählt hat: Einstellung ändern, melden oder ersetzen |
Die dritte Zeile ist die unangenehmste, weil dort am wenigsten in der eigenen Hand liegt. Das Theme-Handbuch von WordPress nennt als Prüfhilfen ausdrücklich axe und WAVE und hält fest, dass die Sicherstellung der Barrierefreiheit ein wesentlicher Teil verantwortungsvoller Theme-Entwicklung ist, mit Tastaturbedienung, Verträglichkeit mit Vorleseprogrammen und richtigem Einsatz von ARIA-Rollen.
Welche Seiten geprüft werden
Ein WordPress-Auftritt hat wenige Vorlagen und viele Seiten. Geprüft werden die Vorlagen, nicht die Seiten, und dazu jede Stelle, an der Nutzerinnen etwas eingeben. Sechs Ansichten decken die meisten Auftritte ab:
- Startseite, weil dort die meisten Bausteine zusammenkommen.
- Eine Übersicht, etwa das Blog oder ein Archiv, mit Blättern und Filtern.
- Ein Beitrag mit Bildern, Zitaten, Listen und einem eingebetteten Video.
- Eine Seite mit Formular, meistens Kontakt oder Anmeldung.
- Die Suche mit einem Treffer und die Suche ohne Treffer.
- Die Fehlerseite 404, die oft aus einer eigenen Vorlage kommt und selten jemand ansieht.
Für die Inhaltsprüfung gibt es einen Kniff aus der Theme-Entwicklung: Die offiziellen Theme Unit Test Data sind eine importierbare Datei mit Beiträgen, Seiten, Kommentaren und Medien, die Randfälle abdeckt, etwa sehr lange Titel, Bilder in verschiedenen Grössen und verschachtelte Kommentare. Wer ein Theme prüft, sieht damit in einer Stunde Fälle, die im eigenen Bestand erst in einem Jahr auftauchen.
Einen Befund der richtigen Schicht zuordnen
Die Zuordnung geschieht durch Ausschluss, auf einer Kopie der Website, nie auf dem laufenden Auftritt. Vier Schritte reichen in fast allen Fällen:
- Die Stelle im ausgelieferten Quelltext suchen. Steht der fragliche Ausschnitt innerhalb des Inhaltsbereichs, den der Editor füllt, ist es ein redaktioneller Befund.
- Den Beitrag im Editor öffnen. Ist die Überschrift dort ein Absatz mit fetter Schrift, ist die Sache erledigt, ohne dass jemand Code anfasst.
- Auf der Kopie alle Erweiterungen abschalten und die Seite erneut ansehen. Ist der Befund weg, einzeln wieder einschalten, bis er zurückkommt.
- Ist der Befund auch ohne Erweiterungen da, auf ein Standard-Theme umstellen. Verschwindet er, liegt er im Theme; bleibt er, liegt er in den Inhalten oder in der Konfiguration.
Für die Theme-Seite gibt es zwei offizielle Hilfen: die Erweiterung Theme Check, die ein Theme gegen die Richtlinien der Theme-Prüfung misst, und den Monster Widget, der die eingebauten Widgets in einem einzigen zusammenfasst, damit man sie auf einmal testen kann. Beide prüfen nicht auf Barrierefreiheit im Ganzen, decken aber Lücken im Gerüst auf.
Ein Befund, kommentiert
Der folgende Fall ist für diesen Artikel gebaut und zeigt, wie unterschiedlich die Antwort ausfällt, je nachdem, welche Schicht den Befund verursacht hat.
Kommentierter Befund an einem selbst erstellten Beispielauftritt
| Teil | Inhalt |
|---|---|
| Stelle | Beitragsübersicht, Vorschaubild jedes Beitrags, darunter der Titel als Link |
| Ausschnitt | <a href=...><img src=... alt=></a> gefolgt von <a href=...>Weiterlesen</a> zum selben Ziel |
| Auswirkung | Das Vorleseprogramm liest zwei Links hintereinander zum selben Ziel; der erste hat keinen Namen, der zweite heisst bei jedem Beitrag gleich. In einer Linkliste steht zehnmal «Weiterlesen» ohne Unterschied. |
| Zuordnung | Der Ausschnitt steht ausserhalb des Editor-Inhalts und bleibt nach dem Abschalten aller Erweiterungen bestehen: ein Befund aus der Vorlage des Themes, nicht aus der Redaktion. |
| Korrektur | Das verlinkte Vorschaubild als Schmuckbild behandeln und aus dem Fokusweg nehmen oder dem Link den Beitragstitel als Namen geben; den Text «Weiterlesen» um den Titel ergänzen, sichtbar oder für Vorleseprogramme. |
| Nachprüfung | Übersicht mit der Tastatur durchgehen und die Linkliste des Vorleseprogramms öffnen: Jeder Eintrag muss für sich verständlich sein. |
Was der Tag «accessibility-ready» aussagt
Im offiziellen Theme-Verzeichnis gibt es die Kennzeichnung «accessibility-ready». Die Theme-Prüfung von WordPress ist bei ihrer Bedeutung sehr deutlich: Der Tag bedeutet nicht, dass das Theme die WCAG-Richtlinien auf Stufe AA erfüllt; er bedeutet, dass das Theme die Mindeststandards erreicht, die das Prüfteam gesetzt hat. Dazu kommt der Hinweis, dass die WCAG auch Massstäbe für Inhalte sind und sich nicht auf ein Theme allein anwenden lassen.
Die Anforderungsliste hinter dem Tag ist trotzdem eine brauchbare Prüfliste für jedes Theme: Sprungmarke zum Inhalt, sinnvolle Landmarken mit Namen, vollständige Tastaturbedienung, Bedienelemente mit Name, Rolle und Zustand, beschriftete Formularfelder, eine logische Überschriftenstruktur, unterstrichene Links im Fliesstext, eindeutige Linktexte, ausreichender Kontrast von Text und Bedienelementen, Alternativtexte, zugängliche Medien, Umfliessen bei Zoom und verändertem Textabstand, keine unerwarteten Wechsel, keine ungefragt geöffneten Fenster und eine Erklärung zu den Barrierefreiheitsmerkmalen des Themes.
Hinweis: Ein Theme mit dem Tag ist ein besserer Ausgangspunkt, keine erfüllte Pflicht. Die Inhalte und die Erweiterungen entscheiden mit, und sie machen bei einem gewachsenen Auftritt den grösseren Teil der Befunde aus.
Was die Redaktion allein erledigen kann
Ein erheblicher Teil der Befunde verlangt keinen Entwickler. Alternativtexte an Bildern, Überschriften über die Blocktypen statt über fette Schrift, Linktexte, die das Ziel nennen, Tabellen mit Kopfzeile, Untertitel an Videos, keine Textbilder: Das alles steht im Editor zur Verfügung und ist eine Frage der Gewohnheit.
Darum lohnt sich eine kurze, schriftliche Regel für die Redaktion und eine Prüfung vor dem Veröffentlichen statt danach. Das W3C erinnert bei seinen einfachen Prüfungen daran, dass sie nur wenige Punkte abdecken und schnell gemeint sind, nicht abschliessend; eine Seite könne sie scheinbar bestehen und trotzdem erhebliche Barrieren haben. Für die Redaktion sind sie genau deshalb richtig: Sie fangen die häufigsten Fälle, bevor sie online gehen.
Ihre Website jetzt prüfen
Der Gratis-Check prüft bis zu fünf Seiten und die verlinkten PDFs im echten Browser und zeigt die wichtigsten Verstösse mit Beispiel und Anleitung. Kein Konto, kein Siegel, keine Rechtsberatung.
Häufige Fragen
Macht ein Barrierefreiheits-Plugin die Website zugänglich?
Nein. Eine Erweiterung, die der Seite ein Bedienfeld für Kontrast und Schriftgrösse hinzufügt, behebt die Ursachen nicht: Ein Bild ohne Alternativtext bleibt ohne Alternativtext. Nützlich sind dagegen Erweiterungen, die im Editor auf fehlende Alternativtexte oder leere Linktexte hinweisen, also dort helfen, wo der Befund entsteht.
Woran erkenne ich, ob das Theme schuld ist?
Auf einer Kopie der Website alle Erweiterungen abschalten und danach auf ein Standard-Theme umstellen. Verschwindet der Befund beim Themewechsel, liegt er im Theme. Bleibt er, liegt er in den Inhalten oder in der Konfiguration. Ein Blick in den Editor klärt den Rest.
Was ist mit einem gekauften Theme, das Befunde hat?
Erst den Befund genau festhalten, mit Stelle und Kriterium, und beim Anbieter melden. Kleinere Dinge lassen sich in einem Kindtheme überschreiben, ohne dass das Update sie überschreibt. Wenn Grundlegendes fehlt, etwa Tastaturbedienung oder Fokussichtbarkeit, ist ein Wechsel meist billiger als die dauerhafte Pflege der Korrekturen.
Reicht der Tag «accessibility-ready» als Nachweis?
Nein. Die Theme-Prüfung von WordPress schreibt selbst, dass der Tag nicht bedeutet, dass das Theme die WCAG auf Stufe AA erfüllt, sondern dass es die Mindeststandards des Prüfteams erreicht. Er ist ein guter Ausgangspunkt für die Auswahl, kein Ergebnis einer Prüfung des eigenen Auftritts.
Wie oft muss ich nach einem Update prüfen?
Nach jedem Update des Themes und der Erweiterungen zumindest die Vorlagen, die davon betroffen sind, und nach jeder grösseren Änderung am Auftritt alle sechs oben genannten Ansichten. Wie man das als laufenden Ablauf einrichtet, beschreibt der Artikel «Barrierefreiheit nach Updates überwachen».
Quellen
Abgerufen am 22.09.2026. Jeder Link öffnet ein neues Fenster.
- WordPress Theme Handbook: Testing (Theme Unit Test Data, Theme Check, Monster Widget) (developer.wordpress.org, neues Fenster)
- WordPress Theme Review: Accessibility (Bedeutung des Tags accessibility-ready) (make.wordpress.org, neues Fenster)
- WordPress Accessibility Team: Theme accessibility guidelines (wpaccessibility.org, neues Fenster)
- W3C WAI: Easy Checks, a First Review of Web Accessibility (w3.org, neues Fenster)
Weiterlesen
- Barrierefreiheit testen: was Werkzeuge finden, was nur Menschen sehen
Wie man eine Website auf Barrierefreiheit prüft: automatisch, mit Tastatur, Vorleseprogramm und Zoom. Mit Checkliste und dem, was Software nicht kann.
- Cookie-Banner und Dialoge mit der Tastatur prüfen: Erreichbarkeit, Beschriftung, Fokusführung
Wie man ein Einwilligungsfenster mit der Tastatur prüft, warum ein gehaltener Fokus im Dialog erlaubt ist und wo die Tastaturfalle beginnt. Mit Beispiel.
- Barrierefreiheit im laufenden Betrieb überwachen: Scans, menschliche Prüfungen, Zuständigkeiten
Warum behobene Barrieren zurückkommen und wie ein Ablauf aus wiederkehrenden Scans, anlassbezogenen Prüfungen und klaren Zuständigkeiten das verhindert.
- Barrierefreiheit-Checker im Überblick: axe, WAVE, Lighthouse, Accessibility Insights, PAC und Zugangscheck
Welche Werkzeuge Websites und PDFs auf Barrierefreiheit prüfen, was sie messen, was sie kosten und wo jedes seine Stärke hat. Sachlich, ohne Rangliste.
Stand der Rechtslage: 22.09.2026. Dieser Artikel erklärt, was in Gesetz, Verordnung und Norm steht, und ersetzt keine Rechtsberatung. Bei Zweifeln hilft die Bundesfachstelle Barrierefreiheit oder eine Anwältin.