HTML-Barrierefreiheit prüfen (WCAG 2.2)

Fügen Sie ein HTML-Fragment oder eine ganze Seite ein. Der Check zeigt es in einem abgeschotteten Frame an, lässt die quelloffene Engine axe-core in Ihrem Browser darüber laufen und listet die Probleme nach Auswirkung auf, jeweils mit dem fehlerhaften HTML, dem WCAG-Erfolgskriterium und einem Hinweis zur Behebung. Es wird nichts an unseren Server gesendet.

Was Sie im Ergebnis sehen

• Probleme nach Auswirkung: kritisch, schwerwiegend, mittel und gering, die häufigste Regel zuerst.
• Das Erfolgskriterium jedes Problems als Link, zum Beispiel 1.1.1 Nicht-Text-Inhalt, mit Stufe (A oder AA).
• Die betroffenen Elemente: CSS-Selektor und HTML, damit Sie die Stelle im Code finden.
• So beheben Sie es, aus unserer Regelbibliothek in der Sprache dieser Seite, mit Link zur ausführlichen Erklärung.
• „Braucht einen menschlichen Blick“: Fälle, die die Regel nicht entscheiden konnte, etwa eine Farbe auf einem Hintergrundbild. Prüfen Sie diese von Hand.

Was auf Ihrem Rechner bleibt

Ihr Browser verarbeitet das HTML und zeigt es in einem iframe mit sandbox="allow-same-origin" und strenger Content-Security-Policy: Kein Skript Ihres Fragments wird ausgeführt, Formulare lassen sich nicht absenden und Links öffnen in einem neuen Tab. Standardmäßig lädt die Vorschau keine Bilder und Styles von fremden Seiten; aktivieren Sie die Option, wenn Ihr Fragment ein externes Stylesheet braucht. axe-core wird beim ersten Klick von unserem Server geladen, die Prüfung läuft in Ihrem Browser. Ihren Code erhalten wir nicht.

Fragment oder ganze Seite

Ein Fragment ist keine Seite, deshalb sind die Regeln für die ganze Seite (Seitentitel, lang-Attribut, Landmarks, Überschrift der ersten Ebene, Sprunglink) für Fragmente ausgeschaltet. Fügen Sie ein vollständiges Dokument ein, das mit <!doctype html> oder <html> beginnt, dann werden sie mitgeprüft. Die Option „Best-Practice-Regeln einbeziehen“ ergänzt Hinweise, die WCAG nicht verlangt; schalten Sie sie ab, um nur WCAG-Probleme zu sehen.

Was eine Prüfung von eingefügtem HTML nicht findet

• Was die Seite später ergänzt. Der Quelltext enthält nicht, was Skripte danach aufbauen. Kopieren Sie das gerenderte HTML aus den Entwicklerwerkzeugen („Copy outerHTML“) oder testen Sie die Live-Adresse mit dem WCAG-Check.
• Styles, die Sie nicht eingefügt haben. Farbkontrast, Fokusrahmen und Textabstände hängen vom CSS ab. Farben prüfen Sie im Kontrastprüfer.
• Alles, was einen Menschen braucht. Ob der Alternativtext das Bild beschreibt, ob die Lesereihenfolge sinnvoll ist, ob sich die Bestellung per Tastatur abschließen lässt, wie die Seite mit einem Screenreader klingt. Siehe WCAG testen.

Es ist eine automatische Prüfung, kein vollständiges Audit und keine Rechtsberatung. Ein Ergebnis ohne Funde heißt nicht, dass das HTML barrierefrei ist.

Kein Validator im Sinne des W3C

Ein HTML-Validator prüft, ob das Markup der HTML-Spezifikation folgt. Dieses Werkzeug prüft Barrierefreiheitsregeln: Schaltflächen ohne Namen, Bilder ohne Alternativtext, Formularfelder ohne Label, falsche ARIA-Attribute. Das sind zwei verschiedene Fragen; eine Seite kann gültiges HTML sein und WCAG trotzdem nicht erfüllen, und umgekehrt. WCAG 2.2 enthält das Kriterium 4.1.1 Parsing nicht mehr; fehlerhaftes Markup zählt, wenn es Namen, Rollen oder Beziehungen zerstört (4.1.2, 1.3.1).

Wo es passt

Nutzen Sie es beim Schreiben einer Komponente oder beim Prüfen eines Templates von Kunden. Für eine Live-Seite gibt es den WCAG-Check, für Seiten hinter einem Login die Browser-Erweiterung. Weitere Werkzeuge im Vergleich: Tools zum Testen der Barrierefreiheit. Pandus führt solche Prüfungen jede Woche auf allen Seiten Ihrer Website aus und erklärt jedes Problem in der Sprache des Inhabers.

Häufige Fragen

Wird mein Code an einen Server gesendet?

Nein. Das HTML wird in Ihrem Browser angezeigt und geprüft. Von unserem Server werden nur die Seite selbst und das Prüfskript geladen; der eingefügte Code wird nirgendwohin gesendet.

Führt der Check die Skripte in meinem HTML aus?

Nein. Die Vorschau läuft in einem abgeschotteten Frame ohne Erlaubnis für Skripte, daher bewirken Inline-Skripte, Event-Handler und script-Tags nichts. Inhalte, die Skripte ergänzen würden, werden deshalb nicht geprüft.

Welche Regeln werden verwendet?

Die axe-core-Regeln für WCAG 2.0, 2.1 und 2.2 der Stufen A und AA, dazu die Best-Practice-Regeln, wenn Sie die Option eingeschaltet lassen. Die Funde werden mit unseren eigenen Regelkarten erklärt.

Ist das ein W3C-Validator?

Nein. Er prüft nicht die HTML-Syntax, sondern Regeln der Barrierefreiheit. Das ist eine andere Frage.

Kann der Check bestätigen, dass mein HTML WCAG oder den EAA erfüllt?

Nein. Automatische Regeln finden nur einen Teil der Probleme. Eine manuelle Prüfung mit Tastatur und Screenreader bleibt nötig, und das Werkzeug ist keine Rechtsberatung.