Warum WCAG 4.1.1 Parsing gestrichen wurde

Das Erfolgskriterium 4.1.1 Parsing wurde mit WCAG 2.2 im Oktober 2023 ersatzlos gestrichen und gilt seither auch in WCAG 2.1 und 2.0 für HTML-Inhalte als immer erfüllt. Der Grund ist technischer Natur: Assistive Technologien lesen HTML längst nicht mehr selbst, sondern übernehmen das Ergebnis des Browsers – und die Fehlerbehandlung des Browsers ist im HTML-Standard vollständig festgelegt. Was von dem Kriterium inhaltlich übrig bleibt, decken 1.3.1 und 4.1.2 ab.

Die Frage taucht in Audits regelmäßig auf, und sie hat einen berechtigten Kern: Wenn ein Prüfbericht von 2022 noch einen 4.1.1-Befund enthält und die maßgebliche Norm in der EU weiterhin auf WCAG 2.1 verweist – gilt das Kriterium jetzt oder nicht? Die Antwort ist eindeutiger, als die Ausgangslage vermuten lässt.

Das Wichtigste in Kürze

• 4.1.1 Parsing verlangte vollständige Tags, korrekte Verschachtelung, keine doppelten Attribute und eindeutige id-Werte. Stufe A, seit WCAG 2.0 (2008).
• Gestrichen mit WCAG 2.2 (5. Oktober 2023) – nicht ersetzt, sondern entfernt.
• Rückwirkend als erfüllt: Das W3C hat es 2023 auch in WCAG 2.1 und 2.0 als überholt gekennzeichnet; für HTML- und XML-basierte Inhalte gilt es dort als immer erfüllt.
• Begründung: Hilfsmittel parsen HTML nicht mehr selbst, und die Fehlerbehandlung der Browser ist standardisiert.
• Doppelte id-Werte sind kein eigener Verstoß mehr – aber weiterhin einer, sobald sie eine for- oder ARIA-Referenz zerstören.
• Für Prüfungen heißt das: kein Prüfschritt mehr, auch nicht im BITV-Test, auch nicht bei einer Prüfung gegen WCAG 2.1.
• HTML-Validierung bleibt sinnvoll – als Aufräumschritt, nicht als Konformitätsnachweis.
• Stand August 2026, keine Rechtsberatung.

Was 4.1.1 verlangte

Der Normtext war ungewöhnlich technisch für ein WCAG-Kriterium. Sinngemäß: In Inhalten, die mit Auszeichnungssprachen umgesetzt sind, haben Elemente vollständige Start- und End-Tags, sind gemäß ihrer Spezifikation verschachtelt, enthalten keine doppelten Attribute, und alle id-Werte sind eindeutig – außer wo die Spezifikation etwas anderes zulässt.

Vier Anforderungen also, und alle vier beschreiben Markup-Hygiene, nicht Wahrnehmung oder Bedienung. Das war schon 2008 ungewöhnlich: Jedes andere Kriterium beschreibt, was Nutzende erleben. 4.1.1 beschrieb, wie die Datei aussieht.

Genau daraus entstand über die Jahre das praktische Problem. Weil sich Verstöße maschinell finden lassen, meldeten Prüfwerkzeuge zuverlässig große Mengen an 4.1.1-Befunden – ein nicht geschlossenes <div> hier, ein doppeltes class-Attribut dort. Aufwand und Nutzen standen in keinem Verhältnis: Berichte füllten sich mit Meldungen, die für keinen einzigen Menschen eine Barriere darstellten, während die tatsächlich problematischen Fälle darin untergingen.

Warum es gestrichen wurde

Die Begründung der W3C-Arbeitsgruppe lässt sich in einem Satz zusammenfassen: Assistive Technologien haben keinen Anlass mehr, HTML selbst zu parsen – die Probleme existieren deshalb entweder nicht mehr oder werden von anderen Kriterien erfasst.

Dahinter stehen zwei Entwicklungen, die beide vor 2008 noch nicht abgeschlossen waren.

Erstens hat sich die Architektur geändert. Frühe Screenreader lasen teilweise den HTML-Quelltext selbst aus, weil die Schnittstellen der Browser unzuverlässig waren. Heute ist der Weg festgelegt: Der Browser baut aus dem Markup den DOM, daraus den Accessibility Tree, und erst den lesen die Hilfsmittel. Wie diese Kette funktioniert, steht unter Screenreader-Grundlagen. Fehler im Markup wirken sich also nur noch aus, soweit sie den Baum verändern.

Zweitens ist die Fehlerbehandlung standardisiert. Der HTML-Standard beschreibt genau, wie ein Parser mit unvollständigen Tags und falscher Verschachtelung umgeht. Alle gängigen Browser tun daraufhin dasselbe – aus demselben kaputten Markup entsteht überall derselbe DOM. Der ursprüngliche Sorge von 4.1.1, verschiedene Programme könnten dasselbe Dokument verschieden interpretieren, ist damit der Boden entzogen.

Was übrig bleibt, war nie das Markup selbst, sondern seine Wirkung: Wenn eine falsche Verschachtelung dazu führt, dass eine Tabelle ihre Struktur verliert, ist das ein Verstoß gegen 1.3.1 Info und Beziehungen. Wenn ein Attributfehler den zugänglichen Namen eines Bedienelements zerstört, ist es 4.1.2 Name, Rolle, Wert. Beide Kriterien gab es die ganze Zeit.

Gilt das auch für Prüfungen nach WCAG 2.1?

Das ist die Frage, die in Deutschland zählt – denn die harmonisierte EN 301 549 verweist in der maßgeblichen Fassung V3.2.1 auf WCAG 2.1, und dort steht 4.1.1 formal noch. Ein Audit gegen BFSG oder BITV 2.0 prüft also gegen eine Fassung, die das Kriterium noch enthält.

Die Antwort ist trotzdem eindeutig: Das W3C hat 2023 auch die älteren Fassungen angepasst und 4.1.1 dort als überholt gekennzeichnet – mit dem ausdrücklichen Hinweis, dass es für HTML- und XML-basierte Inhalte als immer erfüllt gilt. Ein Prüfer, der gegen WCAG 2.1 testet, hakt es also ab, ohne zu prüfen.

Praktisch ist das längst nachvollzogen. Der BITV-Test führt keinen entsprechenden Prüfschritt mehr, und auch die verbreiteten Prüfwerkzeuge haben nachgezogen: axe-core hat die allgemeine Regel zu doppelten id-Werten zurückgezogen und prüft nur noch die Fälle, in denen eine ARIA-Referenz betroffen ist. Wer einen älteren Prüfbericht in der Hand hält, kann 4.1.1-Befunde also streichen – und sollte die darin genannten Stellen trotzdem einmal ansehen, weil sie oft auf echte Probleme zeigen.

Doppelte IDs: der Fall, der geblieben ist

Von den vier Teilanforderungen ist eine praktisch relevant geblieben, nur unter anderer Nummer. Ein doppelter id-Wert ist heute kein Verstoß gegen 4.1.1 mehr, aber er zerstört zuverlässig jede Beziehung, die über eine ID-Referenz läuft:

<!-- Zwei Felder, dieselbe id: das zweite Label zeigt ins Leere -->
<label for="email">E-Mail (privat)</label>
<input type="email" id="email">

<label for="email">E-Mail (geschäftlich)</label>
<input type="email" id="email">

Ein Browser ordnet beide for-Verweise dem ersten passenden Element zu. Das zweite Feld bleibt damit ohne verknüpftes Label – ein klarer Verstoß gegen 4.1.2, und praktisch ein Formular, das mit dem Screenreader nicht ausfüllbar ist.

Dieselbe Mechanik trifft aria-labelledby, aria-describedby und aria-controls. Der Unterschied zu früher ist also keiner der Wirkung, sondern der Zählweise: Gemeldet wird nicht mehr die doppelte ID, sondern der fehlende Name. Das ist präziser – und es sortiert die harmlosen Fälle aus, in denen eine doppelte ID nur im CSS auftaucht.

Alte 4.1.1-Befunde einsortieren

Wer einen Prüfbericht von vor 2024 übernimmt, steht vor einer Liste, die je nach Werkzeug dutzende 4.1.1-Positionen enthalten kann. Die lassen sich in drei Gruppen sortieren, und nur eine davon macht Arbeit:

Gruppe 1 – erledigt. Nicht geschlossene Tags, doppelte Attribute, falsche Verschachtelung ohne Strukturwirkung, doppelte id-Werte, auf die nichts verweist. Diese Befunde entfallen ersatzlos. Sie waren nie eine Barriere, sie waren ein Formfehler.

Gruppe 2 – umzuetikettieren. Doppelte IDs, auf die ein for, aria-labelledby, aria-describedby oder aria-controls zeigt. Diese Fälle bleiben Befunde, nur unter 4.1.2. Sie sind meist schnell zu finden: In der Regel erzeugt ein wiederverwendetes Template oder eine Komponente, die zweimal auf derselben Seite steht, den Konflikt.

Gruppe 3 – ebenfalls umzuetikettieren, aber schwerer zu sehen. Verschachtelungsfehler, die Struktur zerstören: eine <li> außerhalb einer Liste, eine Tabellenzeile außerhalb der Tabelle, ein Absatz, der eine Überschrift umschließt. Der Browser repariert das Markup zwar, aber nicht immer so, wie es gemeint war – und dann stimmt die vermittelte Struktur nicht mehr mit der sichtbaren überein. Zuständig ist 1.3.1.

Der pragmatische Weg: Gruppe 1 streichen, Gruppen 2 und 3 mit dem Nu Html Checker neu erheben und die verbliebenen Fälle gegen den Accessibility Tree prüfen. Das dauert eine Stunde und ersetzt eine lange Diskussion darüber, ob der alte Bericht noch gilt.

Was HTML-Validierung heute noch bringt

Die naheliegende Schlussfolgerung – „Validierung ist jetzt egal“ – wäre falsch. Sie ist nur kein Konformitätsnachweis mehr:

• Sie findet doppelte IDs, bevor sie eine ARIA-Referenz brechen.
• Sie findet falsche Verschachtelungen, die Struktur zerstören – ein <div> in einem <p>, eine <li> ohne Liste.
• Sie findet erfundene oder falsch geschriebene ARIA-Attribute, die still wirkungslos bleiben.
• Sie ist der billigste Aufräumschritt vor jedem manuellen Test, weil sie das Rauschen entfernt.

Wie du sie einsetzt und welche Meldungen sich getrost ignorieren lassen, steht unter HTML validieren. Wo der Schritt in einen vollständigen Prüfdurchlauf gehört, zeigt Barrierefreiheit selbst testen.

Häufiger Fehler in der Praxis

Aus der Streichung „Markup ist egal“ machen. Das ist die häufigste Überreaktion. Die Streichung betrifft ein Prüfkriterium, nicht die Wirkung schlechten Markups – und die verbliebenen Kriterien 1.3.1 und 4.1.2 sind strenger zu prüfen, weil sie eine inhaltliche Bewertung verlangen statt einer maschinellen.

Die Streichung für einen deutschen Sonderweg halten. Sie kommt vom W3C und gilt für jede Prüfung nach WCAG, unabhängig vom Rechtsraum.

Ein altes Prüfwerkzeug weiterlaufen lassen. Wer eine ältere axe- oder Pa11y-Version im CI hat, bekommt weiterhin duplicate-id-Meldungen und diskutiert sie in jedem Sprint neu. Die Version einmal zu aktualisieren, erspart die Diskussion dauerhaft.

Den Befund still schließen. Wenn in einem Ticket „4.1.1“ steht, gehört ein Satz dazu, warum es entfällt – sonst taucht dieselbe Diskussion beim nächsten Audit wieder auf.

Häufige Fragen

Muss ich alte Prüfberichte korrigieren?

Nein, aber du solltest 4.1.1-Befunde bei der Nachverfolgung als erledigt behandeln. Für eine Barrierefreiheitserklärung sind sie kein zu benennender Mangel mehr.

Wurde 4.1.1 durch ein neues Kriterium ersetzt?

Nein. WCAG 2.2 hat neun Kriterien ergänzt, aber keines davon tritt an die Stelle von 4.1.1 – siehe Neu in WCAG 2.2. Der Inhalt geht in 1.3.1 und 4.1.2 auf, die es vorher schon gab.

Gibt es im Prinzip „robust“ jetzt nur noch zwei Kriterien?

Ja: 4.1.2 Name, Rolle, Wert und 4.1.3 Statusmeldungen, beide in der Kriterien-Referenz. Ein AAA-Kriterium gibt es dort ohnehin keines, siehe WCAG Stufe AAA.

Heißt das, ungültiges HTML ist unproblematisch?

Für die Konformität nach WCAG: meistens ja. Für die Wartbarkeit, für konsistentes Verhalten in Browsern und für Suchmaschinen: nein. Ein <img> im <head> etwa beendet für Googles Parser den Kopfbereich – mit allen Folgen für Canonical und Meta-Angaben, siehe HTML validieren.

Verwandte Themen

• 4.1.2 Name, Rolle, Wert – das Kriterium, das die relevanten Fälle heute abdeckt
• Neu in WCAG 2.2 – die neun Neuzugänge derselben Fassung
• WCAG 2.1 & 2.2: Versionen, Aufbau und Nummerierung – warum Nummern über Versionen hinweg stabil bleiben
• HTML validieren – der Aufräumschritt, der bleibt

Quellen

• WCAG 2.2, Abschnitt 4.1.1 Parsing (Obsolete and removed) (W3C – Streichung samt Begründung)
• What's New in WCAG 2.2 (W3C WAI – Übersicht der Änderungen)
• HTML Standard: Parsing HTML documents (WHATWG – die standardisierte Fehlerbehandlung)
• Nu Html Checker (W3C – der Validator, der die praktischen Fälle weiterhin findet)