Was die automatisierte Prüfung testet

Welche WCAG-Erfolgskriterien die automatisierte Prüfung abdeckt, sortiert nach den vier Prinzipien, und worauf sie dabei jeweils achtet.

Zuletzt aktualisiert: 13. Oktober 2026

Die automatisierte Prüfung im WCAG-Monitoring testet deine Seiten gegen 19 Erfolgskriterien der WCAG. Sie verteilen sich auf alle vier Prinzipien: wahrnehmbar, bedienbar, verständlich und robust.

Hier siehst du, welche Kriterien das sind und worauf die Prüfung jeweils achtet. In Klammern steht die Konformitätsstufe des Kriteriums, also A oder AA. Dazu kommen Best-Practice-Prüfungen, die zu keinem WCAG-Kriterium gehören.

Wahrnehmbar

Inhalte müssen so angeboten werden, dass alle sie wahrnehmen können, zum Beispiel auch ohne zu sehen oder zu hören.

1.1.1 Nicht-Text-Inhalt (A): Bilder, Bild-Schaltflächen, eingebettete Objekte und Elemente mit der Rolle img, zum Beispiel SVG-Grafiken, haben einen Alternativtext. Fortschritts- und Messanzeigen haben einen Namen.
1.2.2 Untertitel (voraufgezeichnet) (A): Videos haben eine Untertitelspur.
1.3.1 Informationen und Beziehungen (A): Listen, Definitionslisten und Tabellen sind im Code richtig aufgebaut. Kopfzellen einer Tabelle sind zum Beispiel ihren Datenzellen zugeordnet. ARIA-Rollen, die bestimmte Kind- oder Elternrollen brauchen, haben sie.
1.3.5 Eingabezweck identifizieren (AA): Das autocomplete-Attribut von Formularfeldern hat einen gültigen Wert.
1.4.1 Verwendung von Farbe (A): Links im Fließtext unterscheiden sich nicht nur durch ihre Farbe vom umgebenden Text.
1.4.2 Audio-Steuerung (A): Audio und Video, die von selbst starten, spielen nicht länger als drei Sekunden Ton ab, ohne dass es Bedienelemente zum Stoppen gibt.
1.4.3 Kontrast (Minimum) (AA): Text hebt sich mit genug Kontrast vom Hintergrund ab.
1.4.4 Textgröße ändern (AA): Die Viewport-Einstellung der Seite verbietet oder begrenzt das Zoomen nicht.
1.4.12 Textabstand (AA): Zeilen-, Wort- und Zeichenabstände sind nicht per Inline-Style mit !important festgeschrieben und lassen sich so anpassen.

Bedienbar

Alle müssen die Seite bedienen können, auch nur mit der Tastatur und im eigenen Tempo.

2.1.1 Tastatur (A): Scrollbare Bereiche und Inhalte in Frames sind mit der Tastatur erreichbar. Serverseitige Image-Maps kommen nicht vor.
2.2.1 Zeiteinteilung anpassbar (A): Die Seite lädt nicht zeitgesteuert per meta refresh neu und leitet so auch nicht weiter.
2.2.2 Pause, Stopp, Ausblenden (A): Die veralteten Elemente blink und marquee kommen nicht vor.
2.4.1 Blöcke umgehen (A): Wiederkehrende Bereiche lassen sich überspringen, zum Beispiel über einen Sprunglink, Überschriften oder Landmarken.
2.4.2 Seite mit Titel (A): Die Seite hat einen Titel.
2.4.4 Linkzweck (im Kontext) (A): Links und klickbare Bereiche von Image-Maps haben einen erkennbaren Namen.

Verständlich

Inhalte und Bedienung müssen verständlich sein. Dazu gehört, dass Hilfsmittel die Sprache der Seite kennen.

3.1.1 Sprache der Seite (A): Das html-Element hat ein lang-Attribut mit einem gültigen Sprachcode. Ist zusätzlich xml:lang gesetzt, stimmt es damit überein.
3.1.2 Sprache der Teile (AA): lang-Attribute innerhalb der Seite haben einen gültigen Sprachcode.
3.3.2 Beschriftungen oder Anweisungen (A): Kein Formularfeld hat mehrere Beschriftungen gleichzeitig.

Robust

Der Code muss so sauber sein, dass Browser und Hilfsmittel wie Screenreader ihn zuverlässig auswerten können.

4.1.2 Name, Rolle, Wert (A): Schaltflächen, Formularfelder, Frames und ARIA-Bedienelemente haben einen zugänglichen Namen. ARIA-Rollen und ARIA-Attribute sind gültig und an der jeweiligen Stelle erlaubt. IDs in ARIA-Bezügen sind eindeutig, mit aria-hidden versteckte Elemente sind nicht fokussierbar und Bedienelemente sind nicht ineinander verschachtelt. Für dieses Kriterium laufen mehr Einzelprüfungen als für jedes andere.

Best Practice

Einige Prüfungen gehören zu keinem WCAG-Kriterium, finden aber typische Stolpersteine. Im Prüfbericht stehen sie im Abschnitt »Best Practice«. Ein Fund dort ist kein Verstoß gegen die WCAG, aber ein guter Hinweis darauf, was du verbessern kannst.

Geprüft wird zum Beispiel, ob die Seite eine Überschrift der Ebene 1 hat, ob die Überschriften-Ebenen in der richtigen Reihenfolge aufeinander folgen, ob es genau einen main-Bereich gibt, ob alle Inhalte in Landmarken liegen und ob Überschriften oder Tabellenköpfe leer sind.

KI-Lesbarkeit

Mit »KI-Lesbarkeit« prüft sitebrunch zusätzlich, wie gut KI-Systeme und Sprachmodelle deine Seite lesen und verstehen können. Die Prüfung ist zu Beginn ausgeschaltet. Du schaltest sie in den Einstellungen deines Projekts ein. Sie besteht aus drei Teilen:

Lesbarkeit ohne JavaScript: Text, Bilder, Überschriften und Landmarken stehen schon im Quelltext und erscheinen nicht erst, nachdem JavaScript gelaufen ist.
Strukturierte Daten für KI: Das JSON-LD der Seite ist gültig. Schemas wie Organization, WebSite und BreadcrumbList sind vorhanden und ihre Pflichtfelder gefüllt.
Alt-Text-Qualität: Ein KI-Modell beurteilt für eine begrenzte Zahl von Bildern pro Seite, ob der Alternativtext den Zweck des Bildes beschreibt.

Die Ergebnisse sind Empfehlungen. Sie verändern den Score deiner Seite nicht.

Was die automatisierte Prüfung nicht abdeckt

Info

Eine bestandene Prüfung heißt nicht, dass das Kriterium erfüllt ist. Automatisiert lässt sich immer nur ein Teil eines Kriteriums prüfen.

Ein Beispiel: Die Prüfung erkennt, ob ein Bild einen Alternativtext hat. Ob der Text das Bild auch passend beschreibt, muss ein Mensch beurteilen. Das gilt für die Randfälle der Kriterien oben genauso wie für alle Kriterien, die hier nicht stehen. Wie du sie mit sitebrunch manuell prüfst, liest du im Bereich »Audits«.