html-einfach.de

Semantisches HTML · Fehler vermeiden

HTML validieren & häufige Fehler

Von Zuletzt geändert am

Browser sind nachsichtig: Sie zeigen auch fehlerhaftes HTML irgendwie an. Genau das ist die Falle – aus „sieht ok aus“ wird schnell „ist schon richtig“. Validierung macht die Fehler sichtbar, die der Browser stillschweigend überspielt, und stärkt das „R“ der vier Prinzipien: robust.

Der W3C-Validator

Das offizielle Werkzeug ist der Markup Validation Service des W3C (validator.w3.org). Drei Wege führen zum Ergebnis:

  • Adresse prüfen: eine öffentliche URL eingeben.
  • Datei hochladen: eine lokale HTML-Datei.
  • Code einfügen: Markup direkt hineinkopieren.

Der Validator listet Fehler und Warnungen mit Zeilennummer – ideal, um sie der Reihe nach abzuarbeiten. Für den Alltag lässt sich das auch automatisieren (z. B. im Build), damit nichts durchrutscht.

Die häufigsten Fehler

Ein paar Klassiker tauchen immer wieder auf:

  • Nicht geschlossene oder falsch verschachtelte Tags (<p> um ein <div>, überlappende Elemente).
  • Doppelte id auf einer Seite – id muss eindeutig sein, sonst brechen Sprungziele und ARIA-Verknüpfungen.
  • Verschachtelte interaktive Elemente – ein <a> im <a> oder Button im Button (siehe klickbare Cards).
  • Fehlendes alt an Bildern.
  • Blockelemente in Inline-Elementen (z. B. ein <div> in einem <span>).
  • Doppelte oder ungültige Attribute.

Randnotiz – valide ist nicht gleich barrierefrei. Der Validator prüft die Syntax, nicht den Sinn. Ein Bild mit leerem alt="" ist valide – aber falsch, wenn das Bild Information trägt. Eine Seite ganz aus <div> kann fehlerfrei validieren und trotzdem „div-Suppe“ sein. Validierung ist die Pflicht, echtes Testen die Kür.

Warum sich das lohnt

Doppelte IDs hebeln aria-describedby und Sprungmarken aus, falsch verschachtelte Elemente verwirren Screenreader und führen zu schwer findbaren Layout-Bugs. Valides Markup ist die verlässliche Grundlage, auf der Hilfsmittel und Browser übereinstimmend arbeiten. Übrigens: Das frühere WCAG-Kriterium 4.1.1 („Parsing“) wurde in 2.2 entfernt, weil moderne Browser robust parsen – die praktischen Vorteile sauberen Markups bleiben aber.

Häufige Fehler

  • Nie validieren und sich auf die Browseransicht verlassen.
  • Doppelte IDs für mehrfach genutzte Komponenten.
  • Validator-Warnungen ignorieren, statt sie zu verstehen.
  • Valide mit barrierefrei verwechseln – zwei verschiedene Prüfungen.
  • Generierten Code nie gegenprüfen (Templates können fehlerhaft ausgeben).

Häufige Fragen

Muss meine Seite zu 100 % fehlerfrei validieren?

Anstrebenswert ja. Manche Warnungen sind harmlos, echte Fehler (doppelte IDs, kaputte Verschachtelung) solltest du aber beheben – sie haben reale Folgen.

Macht valides HTML meine Seite barrierefrei?

Nein, aber es ist die Grundlage. Barrierefreiheit prüfst du zusätzlich – etwa mit den Methoden aus Barrierefreiheit selbst testen.

Hilft Validierung dem SEO?

Indirekt. Suchmaschinen kommen mit kleinen Fehlern klar, aber sauberes Markup beugt Parsing- und Rendering-Problemen vor – und die können sehr wohl schaden.

Fazit

Der W3C-Validator macht sichtbar, was Browser verschlucken: nicht geschlossene Tags, doppelte IDs, kaputte Verschachtelung. Valides HTML ist robust und die Basis für Hilfsmittel – aber kein Ersatz für echtes Testen. Validieren ist die Pflicht, div-Suppe vermeiden und Barrierefreiheit prüfen die Kür.