Wie validiere ich xhtml?

Bei der Validierung von XHTML wird überprüft, ob ein Dokument zwei Regelebenen entspricht: der XML-Syntax und der deklarierten DTD oder dem deklarierten Schema. XHTML 1.0 ist eine Neuformulierung von HTML 4.01 in XML, sodass ein Dokument wohlgeformt, aber ungültig sein kann, wie wenn <a target="_blank"> in XHTML 1.0 Strict erscheint.

Bei der XHTML-Validierung wird überprüft, ob ein Dokument gleichzeitig zwei Regelebenen erfüllt:

1. XML-Syntaxregeln: korrekt verschachtelte Tags, Attribute in Anführungszeichen, obligatorisches Schließen aller Elemente (einschließlich leerer Elemente wie <br />), ein einzelnes Wurzelelement, eine konsistente deklarierte Kodierung usw.
2. DTD-Regeln oder deklariertes Schema: welche Elemente und Attribute existieren, in welchem Kontext sie erscheinen können und welche Werte zulässig sind. Hier sind die klassischen DTDs von XHTML 1.0 (Strict, Transitional, Frameset), XHTML 1.1, XHTML Basic und XHTML Modularization.

Ein Dokument kann wohlgeformtes XML sein und dennoch ungültig sein: Wenn Sie beispielsweise <a target="_blank"> in XHTML 1.0 Strict verwenden, ist die Syntax einwandfrei, aber das Attribut target ist in dieser DTD nicht vorhanden. Diese Unterscheidung zwischen wohlgeformt und gültig ist die häufigste Ursache für Verwirrung, wenn jemand einen Fehler sieht und nicht versteht, warum.

Es ist auch nützlich, sich daran zu erinnern, dass XHTML 1.0 eine vom W3C definierte Neuformulierung von HTML 4.01 in XML ist. Heutzutage hat es einen doppelten praktischen Wert: Es dient für Legacy-Projekte, die immer noch als application/xhtml+xml oder text/html bereitgestellt werden, und es dient als mentale Disziplin, um sauberes Markup zu schreiben. Wenn Sie den vollständigen normativen Kontext zur Validierung von XHTML benötigen, ist die Spezifikation für XHTML 1.0 des W3C die primäre Quelle.

Die Validatoren, die sich lohnen (und wann man welchen einsetzt)

Es gibt keinen einzigen „richtigen“ Validator. Die Wahl hängt davon ab, ob Sie ein Fragment, eine Produktionsseite, eine ganze Website oder ein Dokument validieren, das bereits XHTML5 ist.

Werkzeug	Was es validiert	Ideal für	Hauptbeschränkung
W3C Markup Validation Service (validator.w3.org)	XHTML 1.0/1.1, HTML4, HTML5	Punktuelle Validierung per URL, Datei oder direktem Einfügen	Der moderne „Nu Html Checker“ priorisiert HTML5; alte DTDs erfordern manuelle Auswahl
Nu Html Checker (vnu)	HTML5 und XHTML5	Neue Projekte, lokale Validierung und in CI	Validiert keine klassischen DTDs von XHTML 1.x
Lokale Validatoren (vnu.jar, tidy)	Je nach Konfiguration	Automatisierung, Pre-Commit, Pipelines	Erfordert Installation von Java oder Binärdateien; Anfangskonfiguration
xmllint	XML-Wohlgeformtheit und Validierung gegen DTD/XSD	Prüfung der reinen XML-Ebene	Kennt keine HTML-spezifischen Regeln über das Schema hinaus
Browser- / IDE-Erweiterungen	Live-Markup	Sofortiges Feedback während des Schreibens	Nutzen oft veraltete oder unvollständige Engines

Der W3C Markup Validation Service

Er bleibt der Ausgangspunkt für diejenigen, die sich fragen, wie man XHTML validiert. Er unterstützt drei Modi: Validate by URI, Validate by File Upload und Validate by Direct Input. Bei klassischem XHTML liegt der Trick im Dropdown-Menü Document Type: Wenn Ihr Dokument seine eigene DTD über den DOCTYPE deklariert, respektiert der Validator diese; wenn nicht, müssen Sie sie manuell erzwingen.

Verwandte: accessiBe — Superposición de IA, das die WCAG seit 48 Stunden unterstützt.

Ein Detail, das vielen nicht bewusst ist: Der moderne W3C-Validator setzt auf den Nu Html Checker, der zwar HTML5 und XHTML5 versteht, aber alte DTDs mit geringerer Priorität behandelt. Für XHTML 1.0 Strict funktioniert es immer noch, aber es ist ratsam zu überprüfen, ob das Ergebnis die erwartete DTD widerspiegelt und nicht eine laxere Interpretation.

Nu Html Checker (vnu)

Dies ist der Validator, den das W3C selbst intern verwendet. Er existiert als Webdienst, als ausführbare JAR-Datei und als Docker-Image. Sein großer Vorteil besteht darin, dass Sie ihn lokal und in der kontinuierlichen Integration ausführen können, was essenziell ist, wenn Sie eine große Website verwalten. Für XHTML, das als application/xhtml+xml bereitgestellt wird, erkennt vnu Verschachtelungs- und Attributfehler, die ein toleranter HTML-Validator durchlassen würde.

xmllint

Wenn es Ihnen um die reine XML-Ebene geht – zum Beispiel, weil Sie XHTML aus XSLT-Vorlagen generieren – dann ist xmllint unersetzlich. Mit --noout --valid dokument.xhtml prüft es die Wohlgeformtheit und Gültigkeit anhand der referenzierten DTD. Es ist schnell, skriptfähig und unabhängig vom Netzwerk.

Einen Blick wert: AudioEye — Zugriffsmöglichkeit: Kombinierte Automatisierung mit menschlicher Revision.

Validierung im Editor

Erweiterungen für VS Code, IDE-Plugins und Befehlszeilentools bieten sofortiges Feedback. Sie sind zwar praktisch, hinken aber hinsichtlich der Standards tendenziell hinterher. Nutzen Sie sie als erste Verteidigungslinie, niemals als alleinige Überprüfung.

So validieren Sie XHTML Schritt für Schritt

1. Deklarieren Sie den korrekten DOCTYPE und die Kodierung

Der DOCTYPE bestimmt, anhand welcher Regeln validiert wird. Für XHTML 1.0 Strict:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es" lang="es">
<head>
  <meta http-equiv="Content-Type"
        content="application/xhtml+xml; charset=UTF-8" />
  <title>Ejemplo válido</title>
</head>

Zwei klassische Fehler hier: das Vergessen des xmlns-Attributs (obligatorisch in XHTML) und die Deklaration einer Kodierung in der meta, die nicht mit der tatsächlichen Datei übereinstimmt. Der Validator erkennt beides, aber das zweite Problem zeigt sich manchmal nur durch beschädigte Zeichen.

2. Überprüfen Sie die Wohlgeformtheit vor der Gültigkeit

Stellen Sie vor dem Kampf mit der DTD sicher, dass das XML wohlgeformt ist. xmllint --noout datei.xhtml wird es Ihnen in Sekundenschnelle sagen. Wenn es hier fehlschlägt, hilft Ihnen kein DTD-Validator: Zuerst Tags schließen, Verschachtelung korrigieren und Entitäten (&, <, >) maskieren.

3. Validierung gegen die DTD

Führen Sie das wohlgeformte Dokument durch den W3C-Validator oder vnu. Überprüfen Sie nicht nur, wie viele Fehler es gibt, sondern welcher Art sie sind. Ein einzelner Verschachtelungsfehler kann eine Kaskade sekundärer Fehler erzeugen, die nach der Korrektur des ersten verschwinden.

4. Validieren Sie die gesamte Website, nicht nur die Startseite

Ein häufiger Fehler besteht darin, die Hauptseite zu validieren und davon auszugehen, dass der Rest in Ordnung ist. Vorlagen, Komponenten und dynamisch generierte Seiten führen oft zu ungültigem Markup. Automatisieren Sie dies: Durchlaufen Sie die Haupt-URLs mit einem Skript und führen Sie vnu für jede Antwort aus.

Verwandte: IAAP CPACC / WAS Certification — Die professionelle Zertifizierung erfordert Erfahrung und Zugang.

5. Integrieren Sie die Validierung in Ihren Workflow

Manuelle Validierung skaliert nicht. Fügen Sie Ihrer Pipeline einen Validierungsschritt hinzu (Pre-Commit-Hook, Build-Aufgabe oder CI-Job), der fehlschlägt, wenn ein neuer Fehler auftritt. Auf diese Weise gelangt ungültiges Markup nie in die Produktion.

Fehler interpretieren: Die, die Sie immer wieder sehen werden

• “end tag for X omitted, but OMITTED end tags are not allowed”: typisch für <li>, <p> oder <td> ohne Schließtag. In XHTML muss alles geschlossen werden.
• “there is no attribute X”: das Attribut existiert in Ihrer DTD nicht. Übliche Fälle: target, name in einigen Elementen, data-*-Attribute in XHTML 1.0 (nicht in der klassischen DTD).
• “element X undefined”: es wird ein Element verwendet, das Ihre DTD nicht vorsieht, oft durch das Kopieren von HTML5-Markup in ein XHTML 1.0-Dokument.
• “character data is not allowed here”: Textinhalt, wo die DTD nur Elemente erwartet, oder ein & ohne Maskierung.
• “reference to entity X for which no system identifier could be generated”: benannte HTML-Entitäten, die in XML nicht definiert sind (z. B.   ohne Deklaration). Verwenden Sie in reinem XHTML   oder deklarieren Sie die Entität.

Die goldene Regel für die Validierung von XHTML: von oben nach unten korrigieren. Der erste Fehler ist meist die Ursache; die folgenden sind seine Konsequenz.

XHTML5: Die Nuance, die die Regeln ändert

Wenn Sie XHTML5 bereitstellen – XHTML, das gemäß der HTML5-Syntax serialisiert ist –, ändern sich die Regeln. Es gibt keine DTD mehr: Die Konformität ist in der WHATWG-HTML-Spezifikation und den W3C-Spezifikationen für HTML definiert. Der richtige Validator ist der Nu Html Checker, nicht der klassische DTD-Validator.

Einen Blick wert: UserWay — Widget für den kostenlosen Zugang mit Plan, damit Sie noch heute dort arbeiten können.

Praktische Unterschiede bei der Validierung von XHTML, die man beachten sollte:

• Die data-*-Attribute sind in XHTML5 gültig, nicht in XHTML 1.0.
• Der DOCTYPE wird zu <!DOCTYPE html> vereinfacht.
• Die Validierung erfolgt anhand des Conformance Checkers von HTML5, der an einigen Stellen toleranter und an anderen strenger ist (z. B. bei der Verwendung bestimmter veralteter Elemente).

Die Wahl zwischen XHTML 1.0 und XHTML5 ist nicht nur technischer Natur: Wenn Ihr Projekt neu ist, ist XHTML5 mit vnu-Validierung der sinnvolle Weg. Wenn Sie ein Legacy-System mit DTD verwalten, bleiben Sie bei XHTML 1.0 und validieren Sie gegen dessen DTD.

Validierung und Barrierefreiheit: zwei verschiedene Ebenen

Ein häufiger Fehler ist der Glaube, dass ein gültiges Dokument automatisch barrierefrei ist. Das ist es nicht. Die Validierung prüft die Syntax- und Schemakonformität; die Barrierefreiheit wird anhand der WCAG des W3C bewertet, die Wahrnehmung, Bedienbarkeit und Kompatibilität mit assistiven Technologien abdeckt.

Dennoch gibt es echte Überschneidungen: Ungültiges Markup impliziert normalerweise eine mangelhafte Struktur (schlecht verschachtelte Überschriften, fehlerhafte Listen, Formulare ohne korrekte Labels), und dies beeinträchtigt die Barrierefreiheit. Die sinnvolle Strategie zur Validierung von XHTML und anderen Dokumenten ist, zuerst zu validieren (strukturelles Rauschen zu eliminieren) und danach die Barrierefreiheit zu prüfen mit Tools wie axe, Lighthouse oder manuellen Überprüfungen. Validierung ist eine notwendige, aber keine hinreichende Bedingung.

Häufige Fehler bei der XHTML-Validierung

Vermeiden Sie beim Erlernen der XHTML-Validierung diese häufigen Fehler:

• Nur die Startseite validieren. Das problematische Markup befindet sich meist in internen Vorlagen.
• Kodierung ignorieren. Ein schlecht deklarierter charset erzeugt Geisterfehler.
• Wohlgeformt mit gültig verwechseln. Es sind unterschiedliche Ebenen; lösen Sie diese der Reihe nach.
• Den falschen Validator verwenden. vnu für XHTML5, DTD für XHTML 1.x.
• Kaskadierende Fehler beheben, ohne den ersten zu lesen. Sie verschwenden Zeit und beheben nur Symptome.
• Keine Automatisierung. Manuelle Validierung überlebt den zweiten Sprint nicht.
• Annehmen, dass gültig = barrierefrei ist. Es sind unterschiedliche Standards mit unterschiedlichen Zwecken.

Wichtige Erkenntnisse

• Die Validierung von XHTML umfasst zwei Ebenen: XML-Wohlgeformtheit und Konformität mit der deklarierten DTD oder dem Schema.
• Der W3C Markup Validation Service und der Nu Html Checker (vnu) sind die Referenztools für die Validierung von XHTML; xmllint deckt die reine XML-Ebene ab.
• Verwenden Sie für XHTML 1.0/1.1 die Validierung gegen DTD; für XHTML5 nutzen Sie vnu und vergessen Sie die klassischen DTDs.
• Korrigieren Sie Fehler von oben nach unten: Der erste verursacht normalerweise die folgenden.
• Automatisieren Sie die Validierung in Ihrer Pipeline; manuelle Überprüfung skaliert nicht.
• Gültig ist nicht gleichbedeutend mit barrierefrei: es sind ergänzende Standards, keine Äquivalente.

Quellen & weiterführende Literatur

• XHTML — Wikipedia: Extensible HyperText Markup Language (XHTML) is part of the family of XML markup languages which mirrors or extends versions of the widely used HyperText Markup…
• XHTML Basic — Wikipedia: XHTML Basic is an XML-based markup language designed for simple user agents with limited computing power, such as early mobile phones, PDAs, pagers, and set-top…

Häufig gestellte Fragen

Was ist der Unterschied zwischen wohlgeformtem XHTML und gültigem XHTML?

Ein wohlgeformtes Dokument folgt den syntaktischen Regeln von XML: geschlossene Tags, korrekte Verschachtelung und Attribute in Anführungszeichen. Ein gültiges Dokument respektiert darüber hinaus die DTD oder das Schema, das es deklariert: es verwendet nur Elemente und Attribute, die in seinem Kontext zulässig sind. Man kann ein wohlgeformtes, aber ungültiges Dokument haben, wenn man beispielsweise ein Attribut verwendet, das in XHTML 1.0 Strict nicht existiert.

Ergibt es 2024 noch Sinn, XHTML zu validieren?

Ja, aus zwei Gründen. Erstens stellen viele Legacy-Projekte weiterhin XHTML bereit und müssen gültig bleiben, um im XML-Modus nicht abzustürzen. Zweitens ist die Validierung eine Disziplin, die strukturelle Fehler erkennt, welche die Barrierefreiheit und Wartung beeinträchtigen. Wenn Ihr Projekt neu ist, verwendet es wahrscheinlich HTML5 oder XHTML5, aber die Gewohnheit der Validierung bleibt dennoch wertvoll.

Welchen Validator sollte ich für XHTML5 verwenden?

Nu Html Checker (vnu), verfügbar als Webdienst, ausführbare JAR und Docker-Image. Es ist dieselbe Engine, die der moderne W3C Markup Validation Service verwendet und die HTML5-Syntax sowie deren XHTML-Serialisierung versteht. Verwenden Sie keine klassischen DTD-Validatoren für XHTML5: sie erkennen keine data-*-Attribute oder andere HTML5-Features.

Warum gibt mir der W3C-Validator Fehler aus, die ich nicht verstehe?

Weil viele Fehler die Folge eines vorherigen sind. Eine falsche Verschachtelung kann Dutzende sekundärer Meldungen generieren. Die richtige Strategie ist, den ersten Fehler zu korrigieren, erneut zu validieren und dies zu wiederholen. Zudem wendet der Validator die im DOCTYPE deklarierte DTD an; wenn diese DTD nicht der ist, die Sie erwartet haben, erscheinen die Fehler willkürlich.

Kann ich XHTML über die Befehlszeile validieren?

Ja. Wenn Sie sich fragen, wie Sie XHTML über die CLI validieren können, prüft „xmllint —noout —valid archivo.xhtml“ die Wohlgeformtheit und Gültigkeit anhand der DTD. Für HTML5/XHTML5 macht „vnu.jar archivo.xhtml“ dasselbe. Beide Optionen eignen sich ideal für die Integration in Build-Skripts, Pre-Commit-Hooks oder Continuous-Integration-Jobs, bei denen die manuelle Validierung nicht skaliert werden kann.

Ist eine gültige XHTML-Site automatisch zugänglich?

Nein. Die Validierung überprüft die Syntax- und Schemakonformität. Die Barrierefreiheit wird anhand der WCAG bewertet, die Aspekte wie Kontrast, Tastaturnavigation, Alternativtext oder semantische Struktur abdecken. Ein Dokument kann vollkommen gültig sein und dennoch unzugänglich bleiben. Zuerst validieren und anschließend die Barrierefreiheit prüfen: Es handelt sich um komplementäre Schichten.