2025 hat eine Analyse die 200 größten Websites der Welt auf gültiges HTML geprüft. Das Ergebnis: keine einzige. Nicht eine von zweihundert lieferte fehlerfreien, standardkonformen Code aus. Dabei gibt es die semantischen HTML5-Elemente – header, nav, main, article, footer – seit den ersten Entwürfen 2008, und seit 2014 sind sie offizieller Standard. Sauberes, semantisches Markup müsste für Entwickler also längst selbstverständlich sein. Ein Blick in viele Templates zeigt: Es ist es nicht.
Genau hier setzt Guideline 3.6 an. Sie verlangt Code, der den Web-Standards folgt, statt sie zu umgehen.
Die vier Erfolgskriterien von Guideline 3.6 (meine Übersetzung des Originals):
Semantischer Code: Verwende gültiges und standardkonformes Markup.
Optionale Elemente: Entferne optionale HTML-Elemente, Anführungszeichen bei Attributen und Standardattribute, sofern das die Barrierefreiheit, Lesbarkeit, Funktionalität oder Performance nicht beeinträchtigt. Behalte sie, wenn sie die Barrierefreiheit verbessern, die Klarheit ohne Performance-Einbußen erhalten oder eine einheitliche Darstellung im Browser sicherstellen.
Nicht-standardkonformer Code: Vermeide veraltete, proprietäre oder nicht-standardkonforme Technologien, sofern es keinen klaren, begründeten Bedarf gibt, etwa Kompatibilität mit Altsystemen oder Barrierefreiheit. Setze Polyfills nur ein, wenn nötig, und prüfe regelmäßig, ob sie entfernt werden können.
Eigener Code: Verwende Standard-HTML-Elemente, -Attribute, -Funktionen und -APIs überall dort, wo sie die Anforderung erfüllen. Setze eigene Elemente, Web Components oder eigene Funktionen nur ein, wenn eingebaute Fähigkeiten der Web-Plattform den Bedarf nicht decken oder wenn Du wiederverwendbare Komponenten für ein Design-System baust.
Meine Einordnung
Semantisches Markup bedeutet: Der Code sagt, was er meint. Ein nav ist eine Navigation, ein button ist eine Schaltfläche, ein article ist ein in sich geschlossener Beitrag. Für die Nachhaltigkeit zählt das aus drei Gründen. Erstens Barrierefreiheit: Screenreader und Tastaturbedienung funktionieren mit nativen Elementen von allein. Zweitens Maschinenlesbarkeit: Suchmaschinen und zunehmend KI-Systeme verstehen strukturierten Code besser. Und drittens – der Punkt, der mich als CO₂-Doc am meisten interessiert – weniger Code.
Denn jedes native Element, das Du korrekt einsetzt, spart Dir den Ersatz, den Du sonst selbst bauen müsstest. Ein selbst gebautes Dropdown-Menü aus JavaScript wiegt schnell 30 Kilobyte. Das native select-Element kostet null zusätzliche Bytes. Bei einer Million Aufrufen sind das 30 Gigabyte Unterschied, nach der Faustregel rund 12 Kilogramm CO₂ – für ein Bedienelement, das der Browser längst mitbringt.
Das Problem, das ich in der Praxis am häufigsten sehe, ist die “div-Suppe”: verschachtelte Container ohne jede Bedeutung, jeder mit JavaScript und ARIA-Attributen zu etwas gemacht, das ein einziges HTML-Element von Haus aus könnte. Gültiges Markup rendert außerdem zuverlässiger, verursacht weniger Bugs und weniger unnötige Neuberechnungen im Browser.
Wo ich weiter gehe
Guideline 3.6 sagt: Nutze Standard-Elemente, wo sie passen. Ich drehe den Satz um und mache ihn zur Standard-Frage im Entwurf: Gibt es dafür schon ein natives Element? Erst wenn die Antwort ehrlich Nein lautet, greife ich zu einer eigenen Lösung. Die meisten Templates gehen den umgekehrten Weg – sie bauen erst div-Container und flicken die Bedeutung später mit Skripten nach.
Native Elemente sind getestet, barrierefrei und über Jahre stabil. Was ich dem Browser überlasse, muss ich weder selbst schreiben noch pflegen noch später reparieren. Das ist Suffizienz auf Code-Ebene.
Dein erster Schritt heute
Du musst nicht raten, wie sauber Dein HTML ist. Es gibt dafür seit über zwanzig Jahren ein kostenloses Werkzeug.
Diese eine Prüfung ist der ehrlichste Gesundheitscheck für Deinen Code. Sie zeigt Dir nicht nur Fehler, sondern auch, wo Du Ballast mit Bordmitteln ersetzen kannst.
Der sparsamste Code ist der, den der Browser schon kennt. Semantisches HTML schreibt ihn nicht neu, es ruft ihn nur ab.
Quellen: W3C-Fassung von Guideline 3.6 · Interpretation bei Sustainable Web Design