W3C-Webstandards verstehen: Gremien, Spezifikationen, Prüfwerkzeuge

W3C-Webstandards verstehen: Gremien, Spezifikationen, Prüfwerkzeuge

Tech

Wer eine Frage zu HTML, CSS oder Barrierefreiheit wirklich klären will, landet früher oder später in einer Spezifikation. Dort steht nicht nur, was erlaubt ist, sondern auch, wie verbindlich eine Regel ist und ob das Dokument überhaupt noch gilt. Genau daran scheitern viele: Sie zitieren veraltete Fassungen, verwechseln Entwürfe mit Standards oder halten eine Übersetzung für den Originaltext. Dieser Überblick ordnet die Gremien, Dokumentstufen und Werkzeuge so, dass man die richtige Quelle findet und sie korrekt liest.

Wer hinter dem W3C steht

Das World Wide Web Consortium wurde im Oktober 1994 von Tim Berners-Lee am Laboratory for Computer Science des MIT gegründet, unterstützt von CERN, DARPA und der Europäischen Kommission. Später kamen weitere Gastinstitutionen hinzu: Inria 1995 als europäischer Host, die Keio University 1996 in Japan, ERCIM übernahm 2003 die europäische Rolle, die Beihang University wurde 2013 angekündigt. Anfang 2023 hat sich das W3C als eigenständige gemeinnützige Organisation neu aufgestellt. An der Arbeit beteiligen sich Mitgliedsorganisationen, eingeladene Fachleute und öffentliche Kommentare.

Wichtig für die Einordnung: Das W3C ist kein Gesetzgeber. Seine Standards gelten, weil Browserhersteller sie umsetzen und weil Gesetze oder Normen auf sie verweisen. Bei HTML hat sich das Machtverhältnis deshalb verschoben, dazu gleich mehr.

Vom Arbeitsentwurf zur Recommendation

Jedes Dokument unter w3.org/TR/ trägt oben einen Status. Diese Zeile sollte man vor allem anderen lesen, denn sie entscheidet, wie belastbar der Inhalt ist. Seit dem Process Document vom 18. August 2025 gibt es die frühere Stufe Proposed Recommendation nicht mehr; die Prüfung durch das Advisory Committee findet nun bereits bei der Candidate Recommendation statt.

StufeBedeutungPraxis-Einschätzung
Editor's Draftinterner Arbeitsstand, kein veröffentlichtes W3C-Dokumentnur zum Mitlesen, nie als Standard zitieren
(First Public) Working Draftveröffentlichter Entwurf einer Arbeitsgruppe, ohne vollen KonsensFunktionen können sich noch grundlegend ändern
Candidate Recommendation Snapshottechnisch vollständig, öffentlich geprüft, sammelt Rückmeldungen von Implementierernmeist schon in Browsern, Details können sich noch verschieben
Candidate Recommendation DraftZwischenstand mit Änderungen seit dem letzten SnapshotÄnderungen sind noch nicht formell geprüft
Recommendationvom W3C verabschiedeter Standarddarf als W3C-Standard zitiert werden
Superseded / Obsolete / Rescindedersetzt, nicht mehr empfohlen oder zurückgezogennur noch historisch relevant
Group Note / Statementkein Standard, z. B. Leitfäden oder Anwendungsfällenützlich, aber nicht normativ

Ein Beispiel für die letzte Kategorie liefert HTML 4.01: Die Recommendation vom 24. Dezember 1999 steht seit dem 27. März 2018 als Superseded Recommendation im Archiv. Wer sie heute noch als Referenz nutzt, arbeitet gegen veraltete Regeln. Was sich seitdem geändert hat, zeigt der Beitrag zu HTML 4.01 und dem Weg zum heutigen HTML.

HTML und DOM entstehen bei der WHATWG

Die Web Hypertext Application Technology Working Group (WHATWG) ist ein Zusammenschluss der Browserhersteller. Lange gab es parallel eine W3C-Fassung von HTML und eine WHATWG-Fassung, die sich in Details widersprachen. Am 28. Mai 2019 trat eine Vereinbarung (Memorandum of Understanding) in Kraft: HTML und DOM werden seitdem hauptsächlich bei der WHATWG als Living Standard entwickelt. Das W3C stoppte die geplanten Fassungen HTML 5.3 und DOM 4.1 und kann stattdessen etwa halbjährliche Review Drafts der WHATWG als Recommendation bestätigen.

Für die Praxis heißt das: Maßgeblich ist html.spec.whatwg.org. Ältere W3C-Fassungen wie HTML5 oder HTML 5.2 sind historisch. Der Living Standard hat keine Versionsnummer; er wird laufend geändert, und Änderungen lassen sich im GitHub-Repository nachvollziehen.

CSS kennt keine Versionen mehr, nur Module

Bei CSS lohnt ein genauer Blick, weil der Begriff »CSS3« bis heute durch Tutorials geistert. Nach CSS Level 2 hat die CSS Working Group die Sprache in Module aufgeteilt, die unabhängig voneinander Level zählen. Die Selektoren stehen etwa in Selectors Level 4. Ein CSS4 gibt es ausdrücklich nicht. Welche Module als stabil gelten, fasst die CSS Working Group regelmäßig in einem Snapshot zusammen, etwa im CSS Snapshot 2025. CSS 2.1 bleibt dabei die Grundlage, auf der die Module aufsetzen. Wie zwei dieser Module im Alltag funktionieren, zeigen die Beiträge zu CSS-Selektoren und zu position und z-index.

WCAG: der Standard mit rechtlichen Folgen

Die Web Content Accessibility Guidelines stammen aus der Web Accessibility Initiative des W3C. WCAG 2.0 erschien am 11. Dezember 2008, WCAG 2.1 am 5. Juni 2018, WCAG 2.2 am 5. Oktober 2023 mit einer aktualisierten Fassung vom 12. Dezember 2024. Die Erfolgskriterien sind in die Stufen A, AA und AAA eingeteilt; Inhalte, die WCAG 2.2 erfüllen, erfüllen auch 2.1 und 2.0. WCAG 2.2 ist zudem als ISO/IEC 40500:2025 genormt. WCAG 3 ist dagegen ein früher Entwurf und für Projekte heute noch kein Maßstab.

In Deutschland gilt seit dem 28. Juni 2025 das Barrierefreiheitsstärkungsgesetz (BFSG). Es betrifft unter anderem Websites und Apps, über die Unternehmen Produkte oder Dienstleistungen an Verbraucher verkaufen, also typischerweise Onlineshops. Kleinstunternehmen, die Dienstleistungen erbringen (weniger als zehn Beschäftigte und höchstens zwei Millionen Euro Jahresumsatz oder Bilanzsumme), sind ausgenommen. Als technischer Maßstab dient die harmonisierte Norm EN 301 549, die für Webinhalte auf die WCAG verweist. Laut IHK Köln drohen Bußgelder bis 100.000 Euro, dazu Abmahnungen durch Wettbewerber. Ob ein konkretes Angebot unter das Gesetz fällt, klärt im Zweifel eine Rechtsberatung.

Spezifikationen lesen, ohne sich zu verlaufen

Normativ und informativ trennen

Spezifikationen unterscheiden zwischen normativen Teilen, die Anforderungen festlegen, und informativen Teilen wie Beispielen, Hinweisen und Einführungen. Abschnitte mit dem Vermerk »This section is non-normative« erklären, verpflichten aber zu nichts. Bei Streitfragen zählt allein der normative Text. Hilfreich ist außerdem die Unterscheidung zwischen Anforderungen an Dokumente (was Autoren schreiben dürfen) und an Browser (wie sie auch fehlerhaften Code verarbeiten müssen). Der HTML Standard betont, dass zwischen beiden kein Zusammenhang besteht: Dass ein Browser etwas toleriert, macht es nicht konform.

MUST, SHOULD und MAY nach RFC 2119

Die Schlüsselwörter stammen aus RFC 2119. MUST bezeichnet eine Pflicht, SHOULD eine Empfehlung, von der man nur mit gutem Grund abweicht, MAY eine echte Option. RFC 8174 hat 2017 klargestellt, dass diese Bedeutung nur bei Großschreibung gilt, sofern ein Dokument das so erklärt. Ältere Texte handhaben das anders: HTML 4.01 verweist auf RFC 2119, schreibt die Wörter aber klein. Auch der heutige HTML Standard formuliert seine Anforderungen mit kleingeschriebenem »must«.

Was Übersetzungen leisten können

Viele Spezifikationen wurden ehrenamtlich übersetzt, auch ins Deutsche. Solche Übersetzungen erleichtern den Einstieg, haben aber keinen offiziellen Status. Selbst bei einer Authorized W3C Translation, die ein formales Prüfverfahren mit mindestens 30 Tagen öffentlicher Kommentarphase durchläuft, bleibt laut W3C-Richtlinie im Streitfall die englische Fassung maßgeblich. Hinzu kommt: Eine Übersetzung friert den Stand ihres Originals ein. Wer heute eine deutsche Fassung von HTML 4.01 liest, liest einen Text von 1999.

Validatoren: was sie prüfen und was nicht

Das W3C betreibt mehrere kostenlose Prüfwerkzeuge. Der klassische Markup Validation Service unter validator.w3.org prüft gegen DTDs und eignet sich für alte Doctypes wie HTML 4.01 oder XHTML 1.0. Für aktuelles HTML ist der Nu Html Checker unter validator.w3.org/nu/ das passende Werkzeug; er lässt sich auch lokal betreiben und in Build-Prozesse einbinden. CSS prüft der CSS Validation Service, defekte Links findet der Link Checker.

Ein sauberes Ergebnis beweist allerdings weniger, als viele annehmen. Der Nu Html Checker versteht sich selbst ausdrücklich nicht als Zertifizierung, und er kann nicht beurteilen, ob ein Alternativtext sinnvoll, eine Überschrift passend oder ein Formular bedienbar ist. Für Barrierefreiheit braucht es zusätzlich manuelle Tests mit Tastatur und Screenreader. Umgekehrt gilt: Nicht jede Warnung ist ein Problem. Fehler, die die Struktur zerstören, also nicht geschlossene Elemente, doppelte IDs oder falsch verschachtelte Listen, sollte man beheben; Hinweise auf veraltete, aber erlaubte Attribute können warten.

Warum Standardtreue auch für Suchmaschinen zählt

Google verlangt kein fehlerfreies HTML und interpretiert auch kaputtes Markup so gut es geht. An einer Stelle wirkt sich ungültiger Code aber direkt aus: Steht im head ein dort unzulässiges Element wie img oder iframe, nimmt Google das Ende des Kopfbereichs an und ignoriert alle folgenden Metadaten. Ein Tracking-Pixel an der falschen Stelle kann so Canonical-Angabe, hreflang oder Robots-Meta unwirksam machen. Erlaubt sind im head nur title, meta, link, script, style, base, noscript und template.

<head>
  <meta charset='utf-8'>
  <title>Produktseite</title>
  <link rel='canonical' href='https://example.com/produkt'>
  <!-- Pixel nicht hier, sondern im body einbauen -->
</head>

Darüber hinaus helfen semantisch korrekte Überschriften, Listen und Tabellen sowohl Screenreadern als auch Crawlern, den Aufbau einer Seite zu erfassen. Die Empfehlung für den Alltag: neue Projekte gegen den HTML Living Standard und den Nu Html Checker prüfen, Barrierefreiheit an WCAG 2.2 Stufe AA ausrichten und bei Unsicherheit die Originalspezifikation statt eines Tutorials befragen.

Quellen

Verwandte Beiträge