Barrierefreiheitstest

Automatisierte Barrierefreiheits-Tests für einzelne Seiten oder Batch-Tests für mehrere Seiten.

Im Free-Plan zeigt das Dashboard die Testabdeckung ohne Batch-Status. Automatische Weiterleitungen, Hintergrundtests und Zeitpläne werden erst ab Basic angeboten. Die Testbereiche heißen „Eine Seite testen“ und „Mehrere Seiten testen“.

Die integrierte Ausblendung enthält Anbindungen für Borlabs Cookie 2.x und 3.x; geprüfte Versionen und notwendige EZZE-Korrekturen findest du im Abschnitt zu Cookiebanner-Versionen. Sie gilt nur für Testaufrufe mit gültigem Testschlüssel; die Banner-Einstellungen für normale Besucher bleiben unverändert. Bereits gespeicherte Screenshots werden nicht nachträglich verändert: Starte nach einer Korrektur einen neuen Test. Datum und Uhrzeit in den Ergebnissen verwenden die jeweiligen Formatvorgaben der Oberfläche; das Zeitformat stammt aus WordPress unter Einstellungen → Allgemein (zum Beispiel H:i für die 24-Stunden-Anzeige).

Vor dem ersten Test: Cloud-Funktionen freischalten

Der Barrierefreiheitstest wird über den EZZE Cloud-Dienst ausgeführt. Solange die kostenlose Cloud-Verbindung noch nicht aktiviert ist, zeigt die Testseite deshalb eine vollständige Freischaltkarte statt eines startbaren Testformulars. Der Seitentitel und die Hilfe bleiben dabei verfügbar; das Hilfe-Sheet unterscheidet Free und bezahlte Tarife und erklärt passend dazu Prüfumfang und Grenzen, verfügbare Testarten, die Auswertung der Ergebnisse, typische Startprobleme sowie Cloud-Verarbeitung und URL-Kontingent. Testnavigation und Einstellungen werden erst nach der Freischaltung eingeblendet und können vorher auch nicht über einen direkten Tab-Link geöffnet werden. „Cloud-Aktivierung öffnen“ öffnet das Cloud-Funktionen-Panel im Dashboard; dort startest du die kostenlose Freemius-Aktivierung. Ein Lizenzschlüssel und Zahlungsdaten sind dafür nicht erforderlich. Bei einer erstmaligen Aktivierung bleiben Sidebar und die noch leere Ergebnisliste ausgeblendet, damit die Freischaltung klar im Fokus bleibt. Bereits gespeicherte Testergebnisse bleiben sichtbar. Wenn noch die Bestätigung per E-Mail aussteht, kannst du die Aktivierung fortsetzen oder die E-Mail erneut senden.

Was sind Barrierefreiheitstests?

Barrierefreiheitstests analysieren deine Website automatisch auf WCAG-Konformität. Im Hintergrund kommt eine browserbasierte Accessibility-Analyse (u. a. axe) zum Einsatz, wie sie auch in gängigen Entwickler-Tools verwendet wird. Die Ergebnisse werden detailliert aufgeschlüsselt und mit Lösungsvorschlägen versehen.

Sinn und Einsatzmöglichkeiten

• Automatisierte Überprüfung: Findet automatisch etwa 30-40% aller möglichen WCAG-Probleme
• Kontinuierliches Monitoring: Regelmäßige Tests zeigen Trends und Verbesserungen
• Priorisierung: Identifiziert die häufigsten und schwerwiegendsten Probleme
• Dokumentation: Test-Historie dient als Nachweis für WCAG-Bemühungen
• Qualitätssicherung: Tests vor der Veröffentlichung neuer Inhalte

Limits

• Tests pro URL: Unbegrenzt für alle Pläne (dieselbe URL kann beliebig oft getestet werden)
• Max. unterschiedliche URLs/Monat:

Wichtig: Jede normalisierte URL zählt nur einmal im Monat zum Limit, egal wie oft du sie testest. Desktop- und Mobile-Ansicht erzeugen getrennte Testergebnisse, verbrauchen für dieselbe URL aber kein zweites URL-Kontingent. Unterschiede nur bei Protokoll, Groß-/Kleinschreibung des Hosts, Standard-Port, abschließendem Slash oder reinen Tracking-Parametern erzeugen ebenfalls keinen zweiten Eintrag; fachlich relevante Query-Parameter bleiben unterscheidbar.

Cookie-Banner, Bots und Viewport-Screenshot

Der Viewport-Screenshot ist bei neuen Einstellungen standardmäßig aktiviert, auch im Free-Plan. Du kannst ihn jederzeit ausschalten; eine bereits gespeicherte Deaktivierung bleibt bei Updates erhalten. Die erforderliche Cloud-Aktivierung wird dadurch nicht ersetzt und es wird kein Test automatisch gestartet.

Wenn du in den Barrierefreiheitstest-Einstellungen den optionalen Viewport-Screenshot aktivierst, hängt die Erzeugung vom Plan ab. In Free stammt die kompakte Vorschau aus demselben PageSpeed-Lauf wie Score und Prüfungen; dafür wird zusätzlich die für das Bild erforderliche Performance-Auswertung ausgeführt und der Test kann etwas länger dauern. Ab Basic wird nach dem Speichern des Testergebnisses sofort ein eigener hochauflösender Screenshot-Auftrag an den EZZE Proxy übergeben. Das Testergebnis wartet nicht darauf: Während die getrennte Warteschlange arbeitet, erscheint an der Bildposition ein Ladezustand und die fertige Aufnahme wird anschließend im Ergebnis gespeichert.

Die Free-Vorschau gehört exakt zum geprüften Lauf. Die hochauflösende Aufnahme ab Basic ist technisch ein eigener Seitenaufruf unmittelbar danach; wenn sich die Seite in diesem kurzen Zeitraum ändert, kann sie deshalb vom geprüften Zustand abweichen. Die Warteschlange wiederholt vorübergehende Fehler begrenzt und beendet jeden Auftrag spätestens nach 15 Minuten. Bleibt die Aufnahme erfolglos, erscheint Screenshot konnte nicht erstellt werden. Die Aktion darunter wird zu Inhalt erneut testen und startet einen neuen Barrierefreiheitstest. Ein abgeschlossener oder abgelaufener Screenshot-Auftrag wird nicht zu einem beliebigen späteren Zeitpunkt wieder aufgenommen.

Das Plugin kann kein Cookie-Banner bestätigen oder Cookies vorab setzen — das steuern ausschließlich deine Website und dein Consent-Setup.

• Screenshot: Ein Cookie-Overlay kann im Bild sichtbar bleiben, auch wenn dein Consent-Tool z. B. Cookies für Bots/Crawler oder ähnliche Optionen aktiviert hat. Typische Gründe: Der erkannte User-Agent entspricht nicht dem, was dein Tool als Bot behandelt, es gibt ein zweites Overlay (Theme, Tag Manager, weitere Skripte, CMP-Version), oder der Zeitpunkt des Screenshots fällt in eine Phase, in der das Banner noch sichtbar ist.
• Audits / Score: Ein Cookie- oder Consent-Overlay kann die Testergebnisse deutlich verändern: Solange Banner oder Modale Inhalte blockieren oder überdecken, bleiben viele Bereiche der Seite für automatische Prüfungen unsichtbar oder unerreichbar — dann werden nicht alle Elemente geprüft. Das betrifft nicht nur die Optik im Screenshot, sondern auch einzelne Audits und den Barrierefreiheits-Score.
• Mögliche Schritte: Einstellungen und Doku deines Cookie-/Consent-Tools prüfen (Bots, Crawler, Mess-Tools, ggf. URL-/Vorschauparameter). Für Entwickler bietet das Plugin den Filter ezzewcag_accessibility_test_cloud_url, um nur für den Cloud-Test einen von der CMP-Doku bestätigten Query-String an die URL anzuhängen, ohne normale Besucher-URLs zu ändern.

Hinweis: Technische Anpassungen ersetzen keine Abstimmung mit deiner Datenschutz- bzw. Consent-Strategie. Wenn du Sonderregeln für Bots nutzt, kläre bei Bedarf beim Anbieter, ob Zugriffe der externen Mess-Infrastruktur (Barrierefreiheitstest in der Cloud) davon erfasst werden.

Cookie-Banner für Barrierefreiheitstests ausblenden (Einstellungen)

In den Einstellungen zum Barrierefreiheitstest kannst du Cookie-Banner bei Tests aktivieren. Das Plugin hängt dann nur für den Cloud-Lauf einen versteckten Schlüssel an die getestete URL. Deine Website erkennt diesen einen Aufruf und kann den Cookie-Banner für die automatisierte Messung ausblenden. Normale Seitenaufrufe bleiben unverändert; der Cookie-Banner selbst wird bei aktivierter Ausblendung jedoch nicht geprüft.

Unterstützte Dienste und die Fehlerbehebung lassen sich direkt in der Einstellung aufklappen. Unter Technische Einstellungen findest du den aktuellen Schlüssel. Erzeuge nur dann einen neuen Schlüssel, wenn der aktuelle bekannt geworden sein könnte.

Für gültige Testanfragen setzt das Plugin automatisch No-Cache-Header und das WordPress-Signal DONOTCACHEPAGE. Das schützt Seiten-Caches, die WordPress erreichen. Nur wenn ein vorgeschalteter Cache oder ein CDN URL-Parameter vollständig ignoriert, musst du Anfragen mit ezzewcag_cmp dort vom Cache ausschließen. Normale Besucher müssen den Testlink dafür nicht aufrufen.

Cookiebanner-Versionen und Grenzen der Unterstützung

Stand der Prüfung: 11. September 2026. Diese Angaben betreffen die Ausblendung im Barrierefreiheitstest, nicht die allgemeine Kompatibilität oder den Wartungsstatus des Cookiebanner-Anbieters. Die Ausblendung ist auch im Free-Plan verfügbar; ein kostenpflichtiger Plan behebt keine inkompatible Banner-Version.

Cookiebanner / Version	Anbindung und belegter Stand
Borlabs Cookie 2.x	Eigene Anbindung für die ältere Frontend-Struktur; mit 2.2.34 nach der EZZE-Korrektur auf einer echten Installation einschließlich neuem Ergebnis-Screenshot erfolgreich geprüft. Daraus folgt keine Prüfung aller 2.x-Versionen.
Borlabs Cookie 3.x	Separate Anbindung über die 3.x-Schnittstellen. Die Prüfung mit 2.2.34 ist kein Nachweis für eine bestimmte 3.x-Unterversion.
Borlabs Cookie 1.x	Keine dokumentierte Anbindung oder bestätigte Unterstützung. Vor einem Wechsel die vom Anbieter unterstützte Zielversion und den Migrationsweg prüfen.
Complianz, Cookiebot, Real Cookie Banner, iubenda	Mitgelieferte Anbindungen über die jeweiligen Plugin-Schnittstellen. Es liegt keine vollständige Liste geprüfter Versionsnummern und keine bestätigte numerische Mindestversion vor. Die konkrete Installation muss geprüft werden.
CookieYes / älteres GDPR Cookie Consent	Anbindung über den älteren Plugin-Hook. Keine bestätigte numerische Versionsgrenze zwischen dieser und der Web-App-Anbindung.
CookieYes mit Web-App-Anbindung	Anderer Ausblendungsweg: Entfernen des externen Ladeskripts von cdn-cookieyes.com. Lokal gehostete, veränderte oder anders nachgeladene Skripte sind damit nicht automatisch abgedeckt.

Weitere externe Loader von OneTrust, Osano, Termly, Quantcast Choice, Didomi, TrustArc, Usercentrics, CookieScript und CookieFirst werden anhand bekannter Skript-Domains entfernt. Das ist keine Zusage für jede Produktversion oder Einbindungsart. Eigene Banner und abweichende Einbindungen benötigen gegebenenfalls eine Entwickler-Anbindung wie unten beschrieben.

Banner sichtbar: Versionsprüfung und Hinweise für den Support

1. Erfasse den Cookiebanner-Namen und die exakte Version, die EZZE-Version einschließlich Korrekturstand, die betroffene URL und den Zeitpunkt des Tests. Die Anzeige „erkannt“ bestätigt die Erkennung des Plugins, nicht das erfolgreiche Ausblenden in dieser Konfiguration.
2. Prüfe, ob die Cloud-Aktivierung abgeschlossen und die Cookiebanner-Ausblendung eingeschaltet ist. Prüfe anschließend Cache/CDN und zusätzliche Banner aus Theme, Tag Manager oder weiteren Plugins.
3. Bei Borlabs 2.x muss EZZE die Korrektur für die ältere Anbindung enthalten. Das ursprünglich erzeugte Free-Paket 1.0.0 enthält diese nachträgliche Korrektur nicht; eine einzeln korrigierte Installation kann trotzdem weiterhin 1.0.0 anzeigen. Prüfe deshalb Paketstand und Änderungsprotokoll. Das am 11. September 2026 neu über Freemius erzeugte Paket 1.0.0 enthält die Korrektur (Build-Nachweis: 34634511889). Ältere Downloads derselben Versionsnummer enthalten sie nicht automatisch. Ein Wechsel auf Borlabs 3.x ist für die mit 2.2.34 geprüfte Lösung nicht erforderlich.
4. Empfiehl ein Update gezielt: Ein EZZE-Update hilft nur, wenn das verfügbare Paket die passende Korrektur enthält. Ein Cookiebanner-Update kommt bei einer nicht angebundenen Version oder einer vom Anbieter bestätigten Fehlerkorrektur infrage; Zielversion und Migrationshinweise müssen vorher geprüft werden. Für Anbieter ohne bestätigte Versionsgrenze keine Mindestversion erfinden und keinen sicheren Erfolg durch ein Update versprechen.
5. Starte danach einen neuen Test. Gespeicherte Screenshots ändern sich nicht nachträglich. Bleibt der Banner sichtbar, gib die genannten Angaben und den neuen Screenshot an den Support weiter, aber keinen geheimen Testschlüssel und keine URL mit dessen Wert.

Beispiel für eine passende Support-Antwort: „Borlabs Cookie 2.x benötigt die entsprechende EZZE-Anbindung. Die Ausblendung wurde mit Borlabs 2.2.34 und der EZZE-Korrektur geprüft. Bitte prüfe zuerst, ob deine EZZE-Installation diese Korrektur enthält, aktiviere die Cookiebanner-Ausblendung und starte einen neuen Test. Ein Wechsel auf Borlabs 3.x ist dafür nicht grundsätzlich erforderlich.“

Für Entwickler: CMP ohne feste Plugin-Unterstützung

1. URL-Parameter laut Anbieter-Doku: Wenn der Anbieter einen Query-Parameter dokumentiert, der Banner oder Overlay ausblendet (Vorschau, Messmodus, Bot-Regel …), hänge ihn mit dem Filter ezzewcag_accessibility_test_cloud_url an (Beispiel unten). Das Plugin ergänzt seinen eigenen Parameter mit Priorität 15. Nutze eine niedrigere Priorität (z. B. 10), damit beide Parameter in der URL landen, oder eine höhere (z. B. 20), wenn dein Callback die URL erst nach dem Schlüssel braucht.
2. PHP-Hooks laut Anbieter-Doku: Nutze die Action ezzewcag_accessibility_test_register_cmp_bypass. Sie läuft nur, wenn ein gültiger Bypass erkannt wurde (korrekter Schlüssel in der Abfragezeichenkette und Option aktiv). In deinem Callback registrierst du die Filter des CMP so, dass der Banner nur für diesen Request nicht geladen wird. Das Plugin feuert die Action früh auf plugins_loaded und init.
3. Eigene Erkennungslogik: Wenn Cache oder Proxy den Query-String entfernen, die Cloud-Messung aber anderweitig erkennbar ist (z. B. User-Agent), erweiterst du die Erkennung mit dem Filter ezzewcag_accessibility_test_cmp_bypass_active. Parameter: Standard-Bool und der konfigurierte Parametername.
4. Parameter umbenennen: Nur falls dein Stack es erfordert: Filter ezzewcag_accessibility_test_cmp_bypass_query_arg. Derselbe Name muss serverseitig beim Auslesen verwendet werden.

In eigenem Code prüfst du mit WCAG_Accessibility_Test_CMP_Bypass::is_bypass_request_active(), ob für den aktuellen HTTP-Request der Bypass-Kontext gilt.

Beispiel: eigenes CMP über die Plugin-Action

Ersetze die Kommentarzeile durch Filter oder Aufrufe aus der Entwickler-Doku deines CMP. Der Code ist nicht Teil des Plugins. In der functions.php deines Child-Themes reicht das in der Regel völlig aus. MU-Plugin oder kleines eigenes Plugin nur, wenn der Code theme-unabhängig bleiben soll (z. B. Theme-Wechsel ohne dauerhaftes Child-Theme).

<?php
/**
* Läuft nur bei gültigem Cloud-Test-Bypass (Schlüssel in der URL + Option aktiv).
* Registriere die Hooks deines CMP, damit der Banner nur für diesen Aufruf unterbleibt.
*/
add_action(
'ezzewcag_accessibility_test_register_cmp_bypass',
static function () {
if ( ! class_exists( 'WCAG_Accessibility_Test_CMP_Bypass' ) ||
! WCAG_Accessibility_Test_CMP_Bypass::is_bypass_request_active() ) {
return;
}
// Beispiel: add_filter( 'your_cmp_show_banner', '__return_false' );
}
);

Beispielcode (Entwickler): Query-Parameter für den Cloud-Test

Der folgende Code ist nicht Teil des Plugins — du legst ihn als MU-Plugin (empfohlen: neue Datei unter wp-content/mu-plugins/, z. B. wcag-cloud-test-consent-tweaks.php) oder in die functions.php deines Child-Themes. Vor dem Einsatz Backup anlegen und nur verwenden, wenn du die Auswirkungen verstehst.

Query-Parameter nur für den Cloud-Test (Plugin-Filter)

Nutze das, wenn dein Consent-Anbieter einen dokumentierten URL-Parameter für Vorschau, Zustimmung o. Ä. vorsieht. Ersetze DEIN_PARAMETER und DEIN_WERT durch die exakten Angaben aus der Anbieter-Doku; wenn es keinen gibt, diesen Weg nicht verwenden. Der Filter gilt für alle Cloud-Läufe des Barrierefreiheitstests, solange du nicht selbst im Callback unterscheidest.

<?php
/**
* Nur für EZZE WCAG Pro Cloud-Tests: URL vor dem Proxy-Aufruf anpassen.
*
* Anpassen: DEIN_PARAMETER / DEIN_WERT durch dokumentierte Schlüssel/Werte deines CMP.
*/
add_filter(
'ezzewcag_accessibility_test_cloud_url',
static function ( $url, $strategy, $post_id, $page_type ) {
return add_query_arg(
'DEIN_PARAMETER',
'DEIN_WERT',
$url
);
},
10,
4
);

Manuelle Batch-Tests: Tageslimit

Pro Website und Kalendertag (Zeitzone laut WordPress unter Einstellungen → Allgemein) sind maximal 10 Starts manueller Batch-Tests vorgesehen. Das schützt Server und Cloud-Infrastruktur; geplante oder automatisierte Abläufe sind davon separat geregelt.

Verfügbare Test-Modi

Einzeltest (Free):

• Teste eine einzelne Seite oder URL
• Unter Inhalt auswählen kannst Du die gruppierte Liste durchsuchen. Kategorien und Einträge scrollen gemeinsam. Mit Escape schließt Du die Liste; der Fokus kehrt zum Auswahlfeld zurück.
• Die Inhaltsauswahl zeigt Titel und URL-Pfad platzsparend in einer Zeile; die eigene Domain entfällt. Die Suche berücksichtigt auch die vollständige URL. Bei Mausberührung des Info-Symbols oder Tastaturfokus erscheint der vollständige Titel mit Permalink direkt am Info-Symbol. Auf schmalen Ansichten blendet die Liste den Pfad aus; über das Info-Symbol kannst Du die vollständige Adresse vor der Auswahl ansehen.
• Sofortige Ergebnisse
• Bricht in der Testansicht die Serverantwort ab, während der Test weiterläuft, wartet die Ansicht über kurze Statusabfragen auf genau diesen Test. Das fertige Ergebnis erscheint automatisch in der Liste, ohne Seitenrefresh oder erneuten Teststart. Die Wiederherstellung wartet höchstens zehn Minuten; bleibt sie erfolglos, kannst Du die Ergebnisliste aktualisieren. Ein tatsächlich parallel gestarteter Test wird weiterhin blockiert.
• Detaillierte Aufschlüsselung aller gefundenen Probleme
• Verfügbar direkt im Admin-Bar, im Editor oder im Plugin-Dashboard
• Kann der Cloud-Prüfdienst einen Test wegen eines vorübergehenden Transport-, Rate-Limit- oder Dienstfehlers nicht starten, wartet das Plugin kurz und versucht den Start genau einmal automatisch erneut. Erst wenn auch dieser Versuch scheitert, erklärt die Meldung, dass der Cloud-Prüfdienst vorübergehend nicht verfügbar ist. Kontingent-, Berechtigungs- und URL-Fehler werden nicht automatisch wiederholt.
• Bei aktivierter Mobilprüfung läuft der Einzeltest in zwei getrennten Schritten. Scheitert nur die mobile Prüfung an einem vorübergehenden Lade- oder Dienstfehler, versucht das Plugin sie genau einmal erneut. Bleibt sie erfolglos, bleibt das erfolgreiche Desktop-Ergebnis erhalten und wird mit einem klaren Mobilfehler angezeigt.

Batch-Tests (ab Basic):

• Teste mehrere Seiten gleichzeitig ab Basic
• Läuft im Hintergrund (WP-Cron oder Action Scheduler)
• Jeder Folgeschritt wird dauerhaft eingeplant; bleibt eine laufende Restwarteschlange ohne aktiven Worker zurück, setzt das Plugin denselben Lauf automatisch fort, ohne bereits geprüfte Seiten neu zu testen
• Wähle Post-Typen, Archive, Taxonomien oder spezielle Seiten (Frontpage)
• Ergebnisse werden in einer Tabelle gesammelt, filter- und sortierbar
• Automatisches Überschreiben bestehender Ergebnisse bei erneuten Tests
• Die Batch-Warteschlange wird vor Schätzung und Start nach derselben normalisierten URL dedupliziert; ein mit einem veröffentlichten Inhalt verknüpfter Eintrag hat dabei Vorrang vor einem reinen URL-Eintrag
• Bei fehlgeschlagenen Items (z. B. Timeouts oder vorübergehende Fehler) lassen sich alle noch fehlgeschlagenen Items eines Laufs mit einem Klick gemeinsam erneut testen – direkt aus der nach dem Lauf angezeigten Fehlerliste
• Wenn nur die Mobile-Ansicht eines gespeicherten Ergebnisses fehlgeschlagen ist, kannst du sie direkt in der Ergebnisdetailansicht einzeln erneut testen
• Die Live-Aktivität hält einen Inhalt über seine gesamte Viewport-Folge hinweg sichtbar: Nach dem Desktop-Test bleibt sein Titel stehen, der Desktop-Chip zeigt das fertige Ergebnis und der Mobil-Chip wechselt von Wird vorbereitet zum laufenden Test. Erst nach Abschluss aller aktivierten Viewports wandert der Inhalt in die Liste. Bei reinen Desktop-Läufen wird kein Mobil-Chip ausgegeben; zwischen zwei Inhalten erscheint bereits der nächste bekannte Inhalt als vorbereitet. Derselbe Zustand wird nach einem Neuladen aus den gespeicherten Worker-, Queue- und Abschlussdaten wiederhergestellt. Aktivierst du Auto-Aktualisieren nach einer Pause wieder, synchronisiert das Plugin zuerst die komplette aktuelle Ergebnisansicht und übernimmt danach neue Ergebnisse wieder fortlaufend.
• Die Liste der kürzlich abgeschlossenen Tests in der Live-Aktivität beginnt bei jedem neuen Batch leer und zeigt ausschließlich Ergebnisse dieses Laufs. Neue Ergebnisse werden ergänzt, ohne vorhandene Zeilen bei jeder Statusabfrage neu aufzubauen; der Tastaturfokus bleibt bei unveränderten Ergebnis-Chips erhalten. Nach dem Neuladen wird der gespeicherte Verlauf desselben Laufs wiederhergestellt.
• Während ein Cloud-Test noch aussteht, bleibt sein Inhalt zwischen den Statusabfragen sichtbar. Das Warten auf die nächste Statusabfrage zeigt nicht vorübergehend den folgenden Inhalt an.
• Wird vorbereitet erscheint nur, solange die Cloud die Ausführung der jeweiligen Ansicht noch nicht bestätigt hat. Während der Ausführung ist der Desktop– oder Mobil-Indikator ohne Vorbereitungstext aktiv. Abgeschlossene Ansichten zeigen ihr Ergebnis; die nächste Ansicht kann vor ihrem Start kurz Wird vorbereitet anzeigen.
• Bevor die Prüfung eines Inhalts beginnt, steht dort ausschließlich Wird vorbereitet. Die Badges Desktop und Mobil erscheinen mit Beginn der Prüfung. Bei der späteren Mobil-Vorbereitung bleibt das Desktop-Ergebnis sichtbar; Mobil · Wird vorbereitet bildet daneben eine zusammengehörige Gruppe.
• Wenn Deine Admin-Sitzung abläuft, pausieren die Hintergrundaktualisierungen während der erneuten Anmeldung. Zusätzliche Sitzungsmeldungen verdecken das WordPress-Anmeldefenster nicht mehr. Ist kein Anmeldefenster geöffnet, erscheint höchstens ein Hinweis. Nach bestätigter Anmeldung werden die Ansichten wieder aktualisiert; Start-, Lösch- und Abbruchaktionen werden nicht automatisch wiederholt. Der Batch läuft auf dem Server weiter.

Automatische Tests:

• Test automatisch nach Veröffentlichung von Beiträgen/Seiten (Standard: aus)
• Test automatisch nach Aktualisierung bereits veröffentlichter Beiträge/Seiten ab Basic (Standard: aus; beim Aktualisieren eines bereits veröffentlichten Beitrags oder einer Seite)
• Konfigurierbare Rollen für beides (Standard: Administrator, Redakteur, Autor)
• Optionale E-Mail nach Test: Publish (Standard: an), Update (Standard: aus)

Geplante Batch-Tests (ab Basic):

• Automatische regelmäßige Tests (wöchentlich, monatlich, benutzerdefiniert) ab Basic
• Konfigurierbare Intervalle
• Wähle Post-Typen, Archive, Taxonomien
• Läuft über WP-Cron oder Action Scheduler

Konfigurationsmöglichkeiten

Integrationen:

• Admin-Bar-Link: Schnellzugriff auf Tests direkt in der WordPress-Admin-Leiste (nur auf Frontend; Standard: an)
• Editor-Bereich: Im Block-Editor erscheint in der Seitenleiste der Bereich „Barrierefreiheit“ mit den letzten Desktop- und Mobile-Ergebnissen, einem Link zum Ergebnis im Plugin und einer Aktion zum Starten des Barrierefreiheitstests für die bearbeitete Seite. Im Classic Editor steht derselbe Bereich in der Veröffentlichen-Box zur Verfügung (sofern die Option in den Barrierefreiheitstest-Einstellungen aktiv ist). Er wird nur für unterstützte Inhaltstypen und testberechtigte Nutzer angezeigt. Ein Testlauf ist für veröffentlichte Inhalte möglich; bei Entwürfen weist der Editor darauf hin. (Standard: an)

Berechtigungen:

• Wer darf testen: Konfigurierbare Rollen (Standard: Administrator, Redakteur)
• Wer darf fremde Inhalte testen: Konfigurierbare Rollen (Standard: Nur Administrator)
• Wer darf Batch-Tests ausführen: Konfigurierbare Rollen (Standard: Nur Administrator)
• Wer darf Ergebnisse löschen: Konfigurierbare Rollen (Standard: Nur Administrator)

Automatische Tests:

• Automatischer Test nach Veröffentlichung: Aktivieren/deaktivieren (Standard: aus); optional E-Mail nach Test (Standard: an, wenn Auto-Test aktiv ist)
• Automatischer Test nach Aktualisierung (ab Basic): Aktivieren/deaktivieren (Standard: aus); läuft beim Aktualisieren eines bereits veröffentlichten Beitrags oder einer Seite
• E-Mail nach Update-Test: Optional (Standard: aus)
• Rollen für automatischen Test: Welche Rollen lösen automatische Tests aus? (Standard: Administrator, Redakteur, Autor; gilt für Publish und Update)
• Die Ergebnis-E-Mail fasst Status, getesteten Inhalt, Desktop-/Mobil-Scores, Zeitpunkt und direkte Links in einem responsiven Layout zusammen. Auf Smartphones stehen Kennzahlen, Details und Aktionen untereinander; zusätzlich ist eine Klartextversion enthalten.

Geplante Batch-Tests (ab Basic):

• Interval: Wöchentlich, monatlich, benutzerdefiniert (Tage)
• Post-Typen: Welche Post-Typen sollen getestet werden? (z.B. post, page)
• Archive: Welche Archive sollen getestet werden?
• Taxonomien: Welche Taxonomie-Seiten sollen getestet werden?
• Spezielle Seiten: Frontpage, etc.
• Optionale E-Mail nach jedem manuellen oder geplanten Batch-Lauf: Unterscheidet klar zwischen abgeschlossen, fehlgeschlagen und abgebrochen und zeigt nur relevante Angaben wie verarbeitete Seiten, Probleme, Dauer, Testart, Viewport, Starter und Zeitpunkte. Wiederholungen und Fehlerbeispiele erscheinen nur, wenn sie vorliegen. Limit-Hinweise nennen Grund, geplanten Umfang und nächste Schritte.

Support-ID bei Problemen mit einem Batchlauf

Wenn ein Batchlauf ungewöhnlich lange dauert, keinen Fortschritt mehr zeigt, fehlschlägt oder unerwartet abbricht, gib bei Deiner Supportanfrage seine vollständige Support-ID an. Damit kann der Support genau diesen Lauf zuordnen. Ergänze kurz, was passiert ist und welchen Fortschritt oder welche Fehlermeldung Du gesehen hast.

Öffne auf der Seite Barrierefreiheitstest den Button Batch-Verlauf direkt neben der Hilfe. Am Desktop öffnet sich ein Seitenpanel, auf dem Smartphone ein Bottom Sheet. Der neueste Lauf ist aufgeklappt; ältere Läufe kannst Du einzeln aufklappen. Jeder Lauf enthält seine eigene Zusammenfassung mit Status, Seitenzahl, Start, Ende, Dauer, Wiederholungen, Testumfang und Testfehlern sowie den gespeicherten Angaben zu Testtyp, Viewport und Starter. Bei älteren Läufen können noch nicht gespeicherte Angaben fehlen. Das kleine Kopier-Symbol direkt an der Support-ID kopiert nur diese ID. Über Diagnosedaten herunterladen kannst Du die Diagnose speichern. Wenn Du eine Abschluss-E-Mail erhältst, steht die ID auch dort. Kopiere immer die vollständige Zeichenfolge mit EW-B-.

Die Support-ID bleibt beim Fortsetzen desselben Laufs gleich. Ein neu gestarteter Batchlauf bekommt eine neue ID. Das Kopieren der ID oder Herunterladen der Diagnose erstellt noch keine Supportanfrage.

Melde Probleme möglichst zeitnah: Laufzusammenfassungen und Diagnoseereignisse werden 90 Tage aufbewahrt und anschließend automatisch gelöscht. Für Läufe vor Einführung der Support-ID gibt es keine nachträglich erzeugte ID; nenne in diesem Fall Deine Website sowie Datum und Startzeit des betroffenen Laufs.

Ergebnisanzeige

Die Testergebnisse werden detailliert aufgeschlüsselt:

• Gesamtscore: Accessibility-Score von 0-100
• Score-Ampel in der Ergebnisliste: 90–100 grün, 50–89 gelb und 0–49 rot. Der Zahlenwert bleibt immer sichtbar, sodass die Bewertung nicht ausschließlich über Farbe vermittelt wird.
• Kategorien: Aufschlüsselung nach WCAG-Bereichen
• Weiterleitungen: Das Plugin prüft den Weiterleitungsweg, bevor ein Cloud-Test startet. Ein Einzeltest zeigt zunächst die angeforderte URL und stellt ein auflösbares Ziel mit WordPress-Titel, lokalisiertem Inhaltstyp und verlinkter URL dar, ohne einen Score anzulegen. Bei einem internen Ziel startet Weiterleitungsziel testen einen separat bestätigten Test; externe Ziele werden nie geprüft. Ein abgeschlossenes Zielergebnis gehört zum Ziel, während die angeforderte URL als Herkunft sichtbar bleibt und für Erneut testen verwendet wird.
• Ergebnisfilter: Kombiniere Inhaltstyp, Seitentyp, Inhaltsstatus, Problemstatus, Score, Testalter und Testquelle. Der Inhaltsstatus „Verwaiste Ergebnisse“ zeigt gespeicherte Tests, deren verknüpfter WordPress-Inhalt nicht mehr veröffentlicht ist, etwa weil er im Papierkorb liegt, als Entwurf gespeichert oder endgültig gelöscht wurde. Solche Zeilen tragen das sichtbare Kennzeichen „Verwaist“ und können einzeln oder gesammelt gelöscht werden. Reine URL-, Archiv- und Taxonomie-Ergebnisse mit post_id = 0 bleiben gültig. Hinweis und Filter zählen dieselben zusammengefassten Einträge; ältere gespeicherte Tests desselben Inhalts erhöhen die Zahl nicht zusätzlich. „Ohne Probleme“ zeigt nur Einträge, deren Desktop- und Mobil-Ergebnis zusammen keine Probleme enthalten. Aktive Filter erscheinen als einzeln entfernbare Chips und bleiben während der Sitzung erhalten. Mobil öffnet der kombinierte Filter als Bottom Sheet; Anwenden übernimmt den Entwurf, während Abbrechen, Schließen, Escape, Hintergrund oder Herunterwischen die angewendeten Filter unverändert lassen.
• Responsive Detailansicht: Auf Smartphones öffnet sich das Ergebnis als fokussiertes Bottom Sheet, das links, rechts und unten bündig am Viewport anliegt und nur oben abgerundete Ecken besitzt. Kopf- und Schließbereich bleiben fixiert. Der obere Griff kann zum Schließen mit dem Daumen nach unten gezogen werden; die Ansicht fährt nach unten, während die Abdunklung ausblendet und die Webseite sichtbar bleibt. Auf größeren Ansichten bleibt sie in der Ergebnisliste eingebettet.
• Aktueller Score und Dashboard: Nur Ergebnisse veröffentlichter WordPress-Inhalte sowie gültige reine URL-Ergebnisse fließen in die aktuellen Kennzahlen, Analytics, AI Insights und Berichte ein. Papierkorb-, Entwurfs- und gelöschte Inhalte beeinflussen den aktuellen Score nicht. Ihre Laufhistorie bleibt zur historischen Nachvollziehbarkeit gespeichert und wird bei einer erneuten Aggregation nicht wieder in den aktuellen Scope aufgenommen.
• Cleanup: Beim Löschen aktueller oder verwaister Ergebnisse entfernt das Plugin auch die dazugehörigen Findings, Erklärungen und gespeicherten Audit-/WCAG-Outcomes. Historische Laufdatensätze bleiben erhalten; Ergebnisse anderer aktueller Viewports oder Nutzer werden nicht versehentlich mitgelöscht.
• Desktop/Mobil-Umschalter: Score, Screenshot, Problemzahl und Prüfungsdetails beziehen sich immer nur auf die aktuell ausgewählte Ansicht.
• Prüfgruppen: Nicht bestandene, manuelle, bestandene und nicht anwendbare Prüfungen werden jeweils mit Anzahl ausgegeben und lassen sich einzeln aufklappen. Neue Testergebnisse enthalten in den manuellen, bestandenen und nicht anwendbaren Gruppen auch die jeweiligen lokalisierten Prüfungsnamen und Beschreibungen. Nicht anwendbare Prüfungen machen nachvollziehbar, warum zwei Seiten unterschiedlich viele automatisch bewertete Prüfungen haben können.
• Barrierefreiheits-Inspektor: Die ergebnisweite Aktion Inspektor öffnen öffnet alle betroffenen Elemente auf der getesteten Seite; das Hut-und-Brille-Symbol öffnet denselben Inspektor direkt beim ausgewählten Finding. Mit Zurück, Weiter und Übersicht navigierst du durch alle betroffenen Elemente. Mehrere Findings desselben DOM-Ziels bleiben einzeln auswählbar. Der nicht modale Inspektor unterscheidet sichtbare, im DOM ausgeblendete, strukturelle Elemente ohne eigene sichtbare Box, fehlende und mehrdeutige Selektoren. Er zeigt Element/Rolle, Größe, Sichtbarkeitsursache und eine bestmögliche Einschätzung zum Accessibility-Baum. Sichtbare Elemente werden rot eingerahmt; bei Elementen ohne eigene Box dient der orange sichtbare Kindkontext nur der Orientierung. Auf dem Desktop liegt der Inspektor zunächst bündig am oberen, rechten und unteren Rand des verfügbaren Viewports und bleibt unter einer sichtbaren WordPress-Adminbar. Ein kompakter Icon-Button öffnet die Auswahl zum Andocken rechts, links, oben oder unten; ein eigener Augen-aus-Button blendet den Inspektor aus. Diese Auswahl wird ausschließlich im Browser gespeichert. Seitliche Docks bieten eine nummerierte Navigation durch alle betroffenen Elemente; oben und unten stehen Navigation, Elementkontext und Behebung nebeneinander. Smartphones bleiben beim festen Bottom-Dock ohne Positionsauswahl. Beim Ausblenden wird das Dock auf einen beschrifteten Rand-Button reduziert; Auswahl, Markierung und eine aktive Browser-Vorschau bleiben erhalten und lassen sich darüber wieder öffnen. Es gibt keine dauerhafte Schließen-Aktion, und Escape lässt den ergebnisbezogenen Inspektor geöffnet. Alle Tarife können den AI-Element-Fix öffnen oder innerhalb ihres Kontingents generieren. Eine Browser-Vorschau ist nur für erlaubte Accessible-Name-Attribute, streng begrenzte Text- und Hintergrundfarben bei Kontrast-Findings sowie eine dauerhafte Unterstreichung bei link-in-text-block verfügbar. Die Link-Vorschau darf zusätzlich genau eine sechsstellige Textfarbe enthalten; Farbe allein reicht nicht. Bei einer Farbvorschau zeigt der Inspektor die Farben und Kontrastwerte vorher und nachher, berechnet den passenden Grenzwert und kennzeichnet das Ergebnis schriftlich als erfüllt, nicht erfüllt oder nicht zuverlässig prüfbar. Komplexe Hintergründe bleiben eine manuelle Anleitung. Kann kein sicherer Patch abgeleitet werden, kennzeichnet der Inspektor den Vorschlag ausdrücklich als manuelle Anleitung. Jede Vorschau ist klar als temporär markiert und wird beim Rückgängigmachen oder Navigieren entfernt; Ausblenden, Wiederherstellen und erneutes Andocken erhalten sie. Inhalte und Styles werden nie gespeichert. Beliebiges KI-HTML, JavaScript oder CSS wird nicht angewendet. Die kostenlose Hilfe „Erklärung & Lösung“ am Befund benötigt keine KI-Anfrage. Bei reduzierter Bewegung entfallen Animation und weiches Scrollen.
• Inspektor-Navigation und Schweregrad: In einem seitlichen Dock steht Übersicht als erste Rail-Aktion über den nummerierten betroffenen Elementen. Der farbige Schweregradpunkt jeder Nummer wird im zugänglichen Namen der Aktion, im Übersichtseintrag und beim aktiven Finding als lokalisierter Text wiederholt; die Bedeutung hängt damit nicht allein von Farbe ab.
• Inspektor-Vorschauaktionen: Zunächst ist nur Vorschau anwenden verfügbar. Nach erfolgreicher Anwendung wird die Aktion durch Vorschau rückgängig machen ersetzt, ohne die Scrollposition des Inspektor-Bereichs zurückzusetzen.
• Inspektor-Darstellung: Muss ein Bereich im Inspektor gescrollt werden, bleibt die native Bedienung per Mausrad, Touch und Tastatur erhalten; sichtbar ist eine schmale, überlagerte Scrollbar. Beim Andocken oben oder unten lassen sich Elementkontext und Behebung unabhängig voneinander scrollen und erhalten bei Überlauf jeweils eine eigene Scrollbar. Auf Smartphones bilden Griffzone und Kopfbereich eine durchgehend eingefärbte Fläche; ein bewusster Wisch nach unten am Griff oder auf einer nicht interaktiven Stelle des Kopfbereichs blendet den Inspektor aus, ohne die Prüfsitzung zu beenden. Bei Links und anderen Inline-Elementen mit Zeilenumbruch markiert der Inspektor jedes sichtbare Zeilenfragment einzeln, statt den dazwischenliegenden Fließtext in eine große rechteckige Markierung einzuschließen. Ist ein ausgewähltes Element nur wegen einer erkannten Einblendanimation unsichtbar, scrollt der Inspektor gezielt zu diesem Element, wartet begrenzt auf seine Einblendung und bewertet es erneut. Absichtlich geschlossene Menüs, Dialoge, Details oder Tabs werden nicht geöffnet. Existiert ein lazy erzeugter Zielknoten noch nicht, wird zuerst sein nächster vorhandener Selektor-Vorfahre angescrollt; nur danach folgt ersatzweise ein begrenzter Seitendurchlauf, der bei einem Treffer stoppt und bei Misserfolg zur Ausgangsposition zurückkehrt.
• AI-Element-Fix-Kontingent: Im Inspektor sehen alle Nutzer das verbleibende Kontingent für AI-Element-Fixes; früher verbrauchte KI-Erklärungen bleiben angerechnet. Der Zähler wird nach einer neuen Generierung automatisch aktualisiert; Lade- und Fehlerzustände werden ausdrücklich angezeigt.
• Metadaten: Getestete URL, ausführender Benutzer und Auslöser (z. B. Manuell, Batch oder Geplant) bleiben kompakt sichtbar. Auf schmalen Bildschirmen werden lange URLs zunächst gekürzt und lassen sich bei Bedarf vollständig aufklappen; der separate Link-Button öffnet die Seite in einem neuen Tab.

Umgang mit Weiterleitungen

• Einzeltest: Beim Anzeigen des Weiterleitungshinweises wird kein Testkontingent verbraucht. Ein internes Ziel wird erst nach ausdrücklicher Bestätigung geprüft. Der Server löst das Ziel bei dieser Aktion erneut auf, damit der Browser kein geändertes oder externes Ziel einschleusen kann.
• Batch-, geplante, Veröffentlichungs- und Aktualisierungstests: Interne Weiterleitungsziele automatisch testen ist in den Einstellungen des Barrierefreiheitstests standardmäßig deaktiviert. Ist die Option aus, werden weitergeleitete Einträge ohne Score oder Findings als übersprungen gemeldet. Ist sie an, werden ausschließlich Ziele derselben Domain automatisch geprüft.
• Zuordnung: Ein abgeschlossener Zieltest wird ausschließlich für die endgültige Ziel-URL und den zugehörigen WordPress-Inhalt gespeichert. Die Quell-URL ist Metadatum und kein zweites Ergebnis.
• Sicherheit und Duplikate: Externe Ziele werden nach ihrer Weiterleitungsantwort nicht angefordert. Schleifen, ungültige Ziele, fehlende Zielangaben, nicht erreichbare URLs und zu lange Weiterleitungsketten sind Fehler. Führen mehrere Quell-URLs in einem Batch zum selben Ziel, wird dieses Ziel nur einmal geprüft.

Anwendungsbeispiele

Beispiel 1: Neue Website testen

Führe Batch-Tests für alle Seiten durch, um einen Überblick über die Barrierefreiheit zu erhalten. Priorisiere die häufigsten Probleme und behebe sie systematisch.

Beispiel 2: Vor Veröffentlichung testen

Aktiviere automatische Tests nach Veröffentlichung. So werden neue Beiträge automatisch getestet und du erhältst sofort Feedback zu Problemen.

Beispiel 3: Regelmäßiges Monitoring

Richte geplante Batch-Tests ein (z.B. monatlich), um kontinuierlich den Stand der Barrierefreiheit zu überwachen. Kombiniere dies mit Analytics, um Trends zu erkennen.

Beispiel 4: Entwicklungsteam

Gib Redakteuren die Berechtigung, einzelne Tests durchzuführen. So können sie ihre veröffentlichten Beiträge testen und sicherstellen, dass sie barrierefrei sind.

Tipps

• Wichtig: Automatisierte Tests finden nur etwa 30-40% aller möglichen WCAG-Probleme. Manuelle Tests durch Experten sind essentiell.
• Nutze die Test-Historie, um Verbesserungen zu verfolgen
• Konzentriere dich zunächst auf kritische und schwerwiegende Probleme
• Bei Limit-Erreichung: Upgrade auf einen höheren Plan oder priorisiere wichtige Seiten
• Alle Tests laufen im Hintergrund und stören nicht den normalen Betrieb
• Kombiniere Einzeltests (für neue oder aktualisierte Seiten) mit geplanten Batch-Tests (für regelmäßige Überprüfung aller Inhalte)

Hinweis: Automatisierte Tests können nur einen Teil der WCAG-Probleme finden. Für vollständige WCAG-Konformität sind manuelle Tests durch Experten unerlässlich.

Verfügbar für: Konfigurierbare Rollen (Standard: Administrator) Free

Batch-Tests: ab Basic

Geplante Tests: ab Basic

Eine Schritt-für-Schritt-Anleitung zur Element-Karte, zum Accessibility-Baum und zur Vorschau findest du hier: Barrierefreiheits-Inspektor: Bedienung und Anzeigen verstehen.