uHTML.de Nachschlagewerke für die tägliche HTML-Arbeit

HTML validieren

Zuletzt geprüft am von Daniel Weihmann

Browser sind nachsichtig. Ein fehlendes schließendes Tag, ein doppeltes Attribut, eine Liste an der falschen Stelle – gerendert wird trotzdem etwas. Genau das ist das Problem: Der Fehler fällt nicht auf, bis ein Screenreader, ein Druckstylesheet oder der nächste Browser anders damit umgeht.

Wozu überhaupt

Validität ist kein Selbstzweck und auch kein Rankingfaktor. Der Nutzen liegt woanders:

  • Fehler finden, bevor sie jemand meldet. Ein doppeltes id bricht Sprungmarken und Formular-Labels, ohne dass optisch etwas passiert.
  • Barrierefreiheit hängt daran. Screenreader verlassen sich auf die Struktur. Wo der Browser rät, raten sie mit – und oft anders.
  • Es ist die billigste Prüfung überhaupt. Eine URL eingeben, fertig.

Womit geprüft wird

Der Maßstab ist der Nu Html Checker des W3C. Er prüft gegen den aktuellen HTML-Standard, nicht gegen eine Versionsnummer, und er ist dasselbe Werkzeug, das hinter den meisten Editor-Erweiterungen steckt.

Drei Wege, je nachdem, wo die Seite liegt: Address für eine öffentliche URL, File Upload für eine lokale Datei, Text Input zum Einfügen eines Ausschnitts. Bei einer Seite, die erst durch PHP entsteht, prüft man immer das Ergebnis – also die Ausgabe im Browser, nicht die Quelldatei.

Eine Seite ist nicht die Website. Der Validator prüft genau eine Adresse. Wer die Startseite prüft und aufhört, hat das Template geprüft, nicht die Inhalte. Sinnvoll ist eine Stichprobe je Seitentyp.

Meldungen im Klartext

Der Checker meldet auf Englisch und knapp. Die folgenden Formulierungen machen den größten Teil aller Funde aus.

Duplicate ID „x"
Ein id-Wert kommt mehrfach vor. Jede id muss im Dokument einmalig sein. Kaputt gehen dabei Sprungmarken, <label for> und alles, was per getElementById sucht. Häufige Ursache: ein Baustein, der mehrfach eingebunden wird.
The „x" element must not appear as a descendant of the „y" element
Verschachtelung, die der Standard ausschließt. Klassiker: ein <a> in einem <a>, ein <div> in einem <p>, oder ein <button>, der einen Link enthält.
Element „x" not allowed as child of element „y"
Das Kind gehört dort nicht hin. Am häufigsten bei Listen: ein <ul> direkt in einem <ul> statt im <li>, siehe Listen.
An „img" element must have an „alt" attribute
Fehlendes alt. Ein leeres alt="" ist erlaubt und für rein schmückende Bilder auch richtig – das Attribut ganz wegzulassen ist etwas anderes.
Bad value „…" for attribute „href"
Ungültige Adresse. Meist ein Leerzeichen in der URL, ein deutscher Umlaut ohne Kodierung oder ein unmaskiertes &.
End tag „x" seen, but there were open elements
Ein Element wurde geschlossen, während darin noch eines offen war. Der Validator nennt die Zeile des Schließens, der Fehler liegt aber weiter oben.
Stray end tag „x"
Ein schließendes Tag ohne öffnendes. Oft der Rest eines gelöschten Blocks.
Attribute „x" not allowed on element „y" at this point
Entweder ein veraltetes Attribut (align, border, frameborder) oder ein Tippfehler im Namen.
Element „title" must not be empty
Leerer Seitentitel. Zählt als Fehler, nicht als Warnung.

Warnungen

Gelbe Meldungen sind keine Verstöße, sondern Hinweise. Zwei kommen besonders oft:

Section lacks heading
Eine <section> ohne Überschrift. Meist ein Zeichen dafür, dass ein <div> gemeint war – eine section ist ein benannter Abschnitt, siehe semantische Elemente.
Consider using the „h1" element as a top-level heading only
Mehrere <h1> im Dokument. Erlaubt, aber selten gewollt.

Was man ignorieren darf

Nicht jede Meldung ist ein Auftrag. Diese Fälle darf man mit gutem Gewissen stehen lassen:

  • Attribute fremder Frameworks. v-if, x-data, ng-model kennt der Standard nicht. Wer sie loswerden will, schreibt sie als data-* – das ist ausdrücklich vorgesehen.
  • Meldungen zu eingebettetem Fremdinhalt. Was in einem <iframe> steht, gehört einem anderen. Der Checker prüft es nicht mit, wohl aber Werkzeuge, die den gerenderten Baum lesen.
  • „Trailing slash on void elements". <br /> statt <br> ist harmlos und in JSX-Umgebungen unvermeidlich.
  • Hinweise zu role, die das Element schon hat. <nav role="navigation"> ist doppelt gemoppelt, aber ungefährlich. Weglassen ist trotzdem sauberer.

Eine Ausnahme ohne Begründung gibt es nicht. Wer eine Meldung stehen lässt, sollte sagen können, warum. „War schon immer so" zählt nicht – die Hälfte aller Validierungsfehler steht seit Jahren unbemerkt im Template.

Wo der Validator blind ist

Eine valide Seite ist nicht automatisch eine gute Seite. Der Checker prüft Grammatik, nicht Sinn. Er merkt nicht, dass

  • ein alt="Bild" nichts erklärt, obwohl es formal vorhanden ist,
  • die Überschriftenebenen zwar stimmen, die Gliederung aber willkürlich ist,
  • der Kontrast zu schwach ist oder der Fokusrahmen fehlt,
  • die Tabelle eigentlich ein Layout ist,
  • <div>-Verschachtelungen dort stehen, wo <header>, <main> und <footer> hingehören.

Deshalb ist die Validierung der erste Schritt und nicht der letzte. Was danach kommt, steht unter Selbst prüfen.