Zurück zu den WCAG

WCAG 2.1 - 4.1.1

Parsing

In Inhalten, die mit Auszeichnungssprachen implementiert sind, haben Elemente vollständige Start- und End-Tags, sind Elemente gemäß ihren Spezifikationen geschachtelt, enthalten Elemente keine doppelten Attribute, und alle IDs sind eindeutig, es sei denn, die Spezifikationen erlauben diese Merkmale.

Inhalt

Was steht in den Guidelines zum Success Criterium 4.1.1 - Parsing?Was Bedeutet das Success Criterium 4.1.1 - Parsing?Warum ist es so wichtig, das Success Criterium 4.1.1 - Parsing zu beachten?Was hat das Success Criterium 4.1.1 - Parsing mit dem BFSG zu tun?Lösungen für 4.1.1 - Parsing anhand von CodebeispielenWie löse ich Verstöße gegen das Success Criterium 4.1.1 - Parsing?

Was steht in den Guidelines zum Success Criterium 4.1.1 - Parsing?

Start- und End-Tags, denen ein kritisches Zeichen in ihrer Bildung fehlt, wie ein schließendes spitzes Klammerzeichen oder ein nicht übereinstimmendes Anführungszeichen für Attributwerte, sind nicht vollständig.

Was Bedeutet das Success Criterium 4.1.1 - Parsing?

Das WCAG Success Criterion 4.1.1 – Parsing fordert, dass Websites so geschrieben sind, dass sie von Browsern und Hilfstechnologien korrekt interpretiert werden können. Dazu müssen der HTML-Code oder andere Markup-Sprachen fehlerfrei sein, was konkret bedeutet:

  • Es gibt keine offenen oder falsch verschachtelten Tags.
  • Attribute und Werte sind korrekt vergeben und geschrieben.
  • IDs auf einer Seite sind eindeutig vergeben.
  • Es werden nur zugelassene Elemente und Attribute verwendet (laut spezifischem Standard wie HTML5).

Laienhaft gesagt: Die Seitenstruktur sollte keine "kaputten" Stellen haben, weil Screenreader und andere Hilfsmittel sonst nicht korrekt erkennen können, was auf der Seite passiert. Bestehen Parsing-Fehler, riskieren Sie, dass wichtige Informationen oder Navigationswege unsichtbar oder unverständlich werden.

Häufige Fehler:
  • Vergessene schließende Tags (z.B. ein nicht geschlossenes <div>)
  • Verschachtelte Elemente, die nicht richtig geöffnet/sabgeschlossen wurden (z.B. <ul><li><div></ul>...</div>)
  • Mehrere Elemente mit derselben ID auf einer Seite
  • Nicht erlaubte oder falsch geschriebene Attribute

Warum ist es so wichtig, das Success Criterium 4.1.1 - Parsing zu beachten?

Parsing-Fehler gefährden die Basis jedes Webangebots: Die zuverlässige, konsistente Darstellung der Inhalte. Für Sehende kompensieren Browser oft kleine Fehler, aber Screenreader, Tastatursteuerungen oder Sprachassistenten brauchen sauberen, strukturierten Code. Nur so können sie Inhaltsbereiche, Überschriften, Navigation und Beziehungen korrekt erkennen. Parsing-Fehler können dazu führen, dass ganze Bereiche übersprungen oder Inhalte falsch vorgelesen werden – das macht die Seite für viele Nutzer:innen unbenutzbar.

Was hat das Success Criterium 4.1.1 - Parsing mit dem BFSG zu tun?

Für das Barrierefreiheitsstärkungsgesetz (BFSG) in Deutschland ist eine saubere technische Umsetzung Grundvoraussetzung. Bei Parsing-Fehlern sind Inhalte nicht zuverlässig zugänglich, was dem Grundgedanken des BFSG widerspricht. Um rechtskonform zu handeln, muss jede Seite fehlerfrei im HTML-Markup und anderen eingesetzten Sprachen vorliegen. Andernfalls ist die Website nicht als barrierefrei im Sinne des BFSG einzustufen; dies kann zu Beanstandungen, Verbesserungspflichten und in letzter Instanz Bußgeldern führen.

Lösungen für 4.1.1 - Parsing anhand von Codebeispielen

Falscher Code

<label for="name">Name: <input id="name" type="text"> <p>Dies ist ein Absatz <div>Verschachtelte Elemente ohne Abschluss.

Korrekter Code

<label for="name">Name:</label> <input id="name" type="text"> <p>Dies ist ein Absatz</p> <div>Verschachtelte Elemente ohne Abschluss gelöst.</div>

Im schlechten Beispiel fehlen schließende Tags für <label> und <p>. Außerdem ist ein <div> fehlerhaft verschachtelt. Im guten Beispiel sind alle Tags korrekt geschlossen.

Falscher Code

<div id="bereich">Inhalt</div> <div id="bereich">Noch ein Inhalt</div>

Korrekter Code

<div id="bereich1">Inhalt</div> <div id="bereich2">Noch ein Inhalt</div>

Im schlechten Beispiel wurden IDs doppelt vergeben, was zu Problemen bei der Zuordnung und Interpretation durch Hilfstechnologien führt. Im guten Beispiel sind alle IDs eindeutig.

Falscher Code

<input name='data' checked>

Korrekter Code

<input name="data" type="checkbox" checked="checked">

Im schlechten Beispiel fehlt das type-Attribut und checked ist als minimiertes Attribut (im XHTML-Kontext problematisch). Im guten Beispiel ist das Attribut vollständig und laut Standard gesetzt.

Wie löse ich Verstöße gegen das Success Criterium 4.1.1 - Parsing?

Zwei Ansichten eines Accessibility Audits mit Grafiken, die einen zeitlichen Verlauf zeigen und Codebeispielen

Unser Accessibility Audit bietet Ihnen die Möglichkeit, mittels unseres AI-basierten Barrierefreiheits-Assistenten, vollautomatisch konkrete Lösungsvorschläge für Ihre Seite zu erstellen. Dafür scannen wir Ihre Website und ihren Quellcode, finden Problemstellen und zeigen Ihnen anhand Ihres eigenen Websitecode fertige Lösungen zum Kopieren und Einfügen. Starten Sie jetzt den Accessibility Audit kostenlos.

Wir prüfen eine Unterseite Ihrer Website. Geben Sie eine beliebige URL ein.