HTML5 ist tot. HTML lebt.

HTML5 als Versionsnummer existiert offiziell nicht mehr. Stattdessen pflegt die WHATWG seit 2019 den HTML Living Standard, zuletzt aktualisiert am 10. Mai 2026. Was diese stille Revolution für Ihre Website, Ihre Agentur und Ihren Browser-Support bedeutet.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

HTML5 hat ein Imageproblem. Die Versionsnummer existiert offiziell nicht mehr, der Begriff geistert trotzdem durch jede Ausschreibung, jedes Briefing, jedes Lehrbuch. Wer heute eine Website beauftragt, sollte verstehen, was hinter dem Buzzword wirklich passiert ist und welche Konsequenzen daraus folgen.

Das Wichtigste in Kürze

• HTML5 ist seit 2019 keine versionierte Spezifikation mehr. Die WHATWG pflegt seither einen HTML Living Standard, der täglich aktualisiert werden kann.
• Der Begriff „HTML5″ überlebt als Marketing-Etikett für moderne Webtechnologien. Im Vertragstext gemeint ist praktisch immer der aktuelle Living Standard.
• Semantische Elemente, native Multimedia und neue Formularfelder gehören 2026 zum Pflichtumfang jedes Mainstream-Browsers. Polyfills sind nur noch für Internet-Explorer-11-Support nötig.
• Mit dem Barrierefreiheitsstärkungsgesetz seit 28. Juni 2025 ist sauberes semantisches HTML keine Stilfrage mehr. Bußgeld bis 100.000 Euro droht bei Verstoß.

Was ist eigentlich aus HTML5 geworden?

Die kurze Antwort: HTML5 wurde abgeschafft. Nicht inhaltlich, sondern als Versionsbezeichnung. Am 28. Mai 2019 unterzeichneten W3C und WHATWG ein Memorandum of Understanding, mit dem die WHATWG seither alleinige Herausgeberin der HTML- und DOM-Standards ist. Versionsnummern wurden gestrichen, Snapshots eingestellt, Forks beendet.

Stattdessen existiert seit 2011 ein Living Standard. Der Begriff ist programmatisch: Die Spezifikation hat kein Versionsende, sondern wächst inkrementell weiter. Die letzte Aktualisierung trägt das Datum 10. Mai 2026, also den heutigen Tag dieses Artikels. Beim Aufruf am nächsten Tag erscheint möglicherweise eine andere Fassung.

Was sagt die WHATWG selbst zur Frage „Is this HTML5?“ Wörtlich heißt die Antwort in der offiziellen FAQ „in short: yes“, in der Langform folgt der entscheidende Hinweis: HTML5 sei ein Buzzword, das auf moderne Webtechnologien verweise, ohne ein bestimmtes Versionsdatum zu meinen. Die Selbstauskunft der Standardisierungsbehörde ist eindeutig.

Stellen Sie sich HTML5 als Schallplatte vor, die niemand mehr presst, aber jeder noch im Regal stehen hat. Die Musik darauf hat sich weiterentwickelt, die Beschriftung blieb. Genau das passiert mit der Bezeichnung im Markt: Sprache verharrt, während die Technologie unter ihrem Namen weiterzieht.

Der Übergang vollzog sich nicht spektakulär. Browserhersteller arbeiten ohnehin gegen den jeweils aktuellen Stand der Spezifikation, nicht gegen einen festgefrorenen Snapshot. Für die Feature-Implementierung gilt der Living Standard als Referenz, nicht eine HTML-5.2- oder HTML-5.3-Mumie. Die Living-Standard-Logik ist insofern ehrlicher als der alte Versionsreigen, der ohnehin nur Marketing-Fiktion war.

Warum spricht trotzdem die halbe Branche von HTML5?

Begriffe sterben langsamer als Standards. HTML5 überlebt aus drei Gründen, die nicht technischer Natur sind, sondern psychologisch und ökonomisch.

Erstens: Tooling. HTML5 Validator, HTML5 Boilerplate, HTML5 Doctor, HTML5 Up. Halbe Werkzeugkästen tragen den Versionsnamen. Niemand benennt Software um, nur weil ein Standardgremium die Versionsnummer streicht. Die Tools existieren weiter, und mit ihnen der Begriff.

Zweitens: Ausschreibungs-Sprache. Im Pflichtenheft signalisiert „HTML5″ einen aktuellen Standard, „Living Standard“ erntet dagegen Rückfragen. Sprachlich gewinnt das Vertraute, auch wenn technisch unschärfer. Branchenbeobachtungen zeigen, dass viele öffentliche IT-Ausschreibungen weiterhin auf den Versionsbegriff zurückgreifen.

Drittens: Lehrmaterial. Schulbücher, Universitätsskripte, VHS-Kurse, Online-Tutorials prägen die Wahrnehmung über Jahre. Eine Bibliothek, die sich nicht über Nacht erneuern lässt. Der Begriff bleibt im Curriculum, weil das Curriculum bleibt.

Welche semantischen Elemente sind heute Pflicht?

Die echte Innovation des Begriffs HTML5 lag nie bei <canvas> oder <video>. Die Innovation lag in der semantischen Strukturierung. Sieben Elemente haben das Web aufgeräumt und das <div id="content">-Zeitalter beendet:

Hinzu kommen <figure> und <figcaption> für Abbildungen mit Beschriftung sowie <time datetime="..."> für maschinenlesbare Datumsangaben. Sieben plus drei Elemente, mehr braucht kein modernes Layout.

Die Pflicht zur Semantik ergibt sich seit Juni 2025 aus dem Barrierefreiheitsstärkungsgesetz. Die Bundesfachstelle Barrierefreiheit verweist explizit auf die Web Content Accessibility Guidelines (WCAG 2.1, mittlerweile 2.2) als Referenzstandard. Screenreader können <nav> von <main> unterscheiden, eine div-Tapete dagegen nicht. Eine Website ohne <nav>, <main> und <article> verletzt nach dem 28. Juni 2025 nicht den Standard, sondern das Gesetz. Bei Online-Shops und kommerziellen Plattformen liegt die Strafandrohung laut BFSG-Verordnung bei bis zu 100.000 Euro. Eine ausführliche Anleitung zur barrierefreien Umsetzung findet sich in unserem Leitfaden zu validem, barrierefreiem Webdesign.

Konkret heißt das: Jede <article>-Box braucht eine Überschrift. Layout-Tabellen sind tabu, Tabellen ausschließlich für tabellarische Daten. Inline-Styles haben in keinem modernen Projekt etwas verloren. Drei Maßgaben decken 80 Prozent der semantischen Pflicht ab.

Was hat HTML5 in Formularen wirklich verändert?

Formulare waren vor 2014 ein Trauerspiel. Jede E-Mail-Validierung musste in JavaScript gegossen werden, jedes Datumsfeld brauchte ein jQuery-UI-Plug-in, jeder Pflichtfeld-Hinweis hing an einer serverseitigen Prüfung. HTML5 hat diese Welt aufgeräumt.

Heute reicht das type-Attribut für die meisten Standardfälle:

Dazu drei Attribute, die früher serverseitige Logik ersetzt haben: required macht Felder zur Pflicht, pattern erlaubt reguläre Ausdrücke direkt im Markup, autocomplete signalisiert Browsern, welche Werte sie vorschlagen sollen. Native Validierung spart Code, beschleunigt das Rendering und reduziert die JavaScript-Abhängigkeit.

Ein viertes Attribut wird unterschätzt: inputmode. Damit lässt sich die mobile Bildschirmtastatur kontextbezogen umschalten, ohne den type zu ändern. Für eine Hausnummer, die als Zeichenkette gespeichert werden muss, ergibt das Sinn. Die Tastatur springt auf numerisch, der Wert bleibt String.

Welche Multimedia-Elemente sind 2026 etabliert?

Vor HTML5 brauchte ein Video im Browser den Adobe Flash Player. Ein Audio-Schnipsel verlangte nach QuickTime oder Windows Media. Plug-in-Inferno, Sicherheitslücken und Inkompatibilitäten waren Alltag. Der Sprung auf native Medienelemente hat das Web aufgeräumt.

Drei Elemente regieren heute die Medienlandschaft:

<video src="film.mp4" controls> reicht für Standard-Videos. Mit dem Attribut poster setzen Sie ein Vorschaubild, mit preload="metadata" reduzieren Sie initiale Ladezeit, mit mehreren <source>-Kindern liefern Sie Codec-Alternativen.

<audio src="podcast.mp3" controls> funktioniert nach demselben Schema. Streaming-Anwendungen ergänzen das durch die Web Audio API, die Sounds programmatisch erzeugen, filtern und mischen kann. Für Standard-Podcast-Player reicht das simple <audio>-Tag.

<picture> plus srcset regelt responsive Bildauslieferung. Verschiedene Auflösungen passen sich an verschiedene Viewport-Größen an, ohne JavaScript. Für moderne Layouts gilt diese Praxis als zwingend, weil mobile Bildauslieferung die Performance maßgeblich bestimmt.

Eine technische Detailfrage entscheidet bei Video oft über die Praxistauglichkeit: das Codec-Problem. Browser unterstützen MP4 (H.264) flächendeckend, WebM (VP9, AV1) wird zunehmend Standard, Apple-Geräte zicken bei manchen WebM-Varianten. Die Faustregel für 2026 lautet: MP4 als Pflicht-Source, WebM als Effizienz-Variante für moderne Browser.

Was ist neu seit dem Living-Standard-Modell?

Seit 2019 wächst der Standard kontinuierlich. Drei Neuerungen verdienen Aufmerksamkeit, weil sie reale Probleme lösen.

Erstens: Das <dialog>-Element ist heute nicht mehr „at-risk“, sondern stabiler Standard. Browser-Support liegt seit 2022 bei nahezu 100 Prozent. Modale Dialoge laufen ohne JavaScript-Bibliotheken, ohne ARIA-Bastelei, ohne Bootstrap-Modal-Plug-in. Die Methoden showModal() und close() öffnen und schließen die Box, das Pseudo-Element ::backdrop stylt den Hintergrund. Eine SweetAlert-Installation 2026 lädt unnötigen Ballast nach.

Zweitens etablieren sich Web Components: Custom Elements und Shadow DOM erlauben echte, browsereigene Komponenten ohne Framework-Overhead. Eine <my-product-card> mit gekapseltem Style und eigener Logik funktioniert in jedem React-, Vue- oder Vanilla-JS-Projekt. Browser-Support liegt im Kern bei 97 Prozent laut caniuse.com (Stand März 2026). Web Components sind die ehrlichste Antwort auf den Framework-Wahnsinn der 2010er-Jahre.

Drittens kommen neue Input-Types und Attribute hinzu: popover als globales Attribut für Tooltips und Menüs ohne JavaScript, <search> als semantischer Container für Suchformulare, inert zur Sperrung ganzer Bereiche gegen Tastatur-Fokus. Kleine Erweiterungen entfalten im Detail große Wirkung.

Wir haben in der Redaktion mehrfach versucht, eine konzentrierte Übersicht aller Living-Standard-Neuerungen seit 2019 zu schreiben. Jeder Versuch endete bei einer Liste mit über 80 Einträgen. Ausrotten lassen sich die Veränderungen nicht, eingrenzen schon. Der pragmatische Mittelweg: Nutzen Sie caniuse.com als laufende Referenz, nicht ein Buch von 2018.

Was bedeutet HTML5 für Entscheider 2026?

Vier Konsequenzen ergeben sich aus dem oben Gesagten für die Geschäftsführung, ohne dass Sie eine Zeile Code lesen müssen.

Erstens, Vertragssprache präzisieren. „HTML5-konform“ ist sprachlich wertlos, weil HTML5 als technischer Versionsbegriff nicht mehr existiert. Besser: „aktueller HTML Living Standard, valide gegen den W3C-Validator, semantisch ausgezeichnet, WCAG-2.2-konform“. Diese drei Maßgaben gehören in jedes Pflichtenheft.

Zweitens, Browser-Support realistisch festlegen. Internet Explorer 11 ist tot, seit Microsoft den Support 2022 eingestellt hat. Eine Zielplattform-Definition mit IE11 verbrennt Budget für Polyfills, die niemand mehr braucht. Die realistische Zielmatrix 2026 umfasst Chrome, Edge, Firefox und Safari in den jeweils aktuellen und vorletzten Versionen. Mobil ergänzen Chrome auf Android und Safari auf iOS die Liste. Weitere Browser brauchen keine Berücksichtigung.

Drittens, BFSG ernst nehmen. Sauberes HTML5, das den semantischen Vorgaben des Living Standards entspricht, ist die technische Voraussetzung für Barrierefreiheit. Eine Website ohne <nav>, <main> und <article> verletzt nicht den Standard, sondern das Gesetz. Bei Online-Shops und kommerziellen Plattformen liegt die Strafandrohung laut BFSG-Verordnung bei bis zu 100.000 Euro. Eine sorgfältige Auswahl der technischen Basis senkt das Risiko früh ab. Welche Rolle dabei das saubere Zusammenspiel von HTML und CSS spielt, hat Dr. Web in einer eigenen Vertiefung beschrieben.

Viertens, Templates und Themes prüfen. Ein WordPress-Theme aus 2018 erfüllt selten heutige semantische Anforderungen. Vor jedem Relaunch lohnt der Validator-Check, der HTML-Audit und der WAVE-Test auf Barrierefreiheit. Auch beim Einsatz fertiger HTML-Templates für Microsites sollten Sie auf semantisches Markup achten. Veraltete Templates bringen technische Schulden mit, die später teuer werden.

Glossar: 14 wichtige Fachbegriffe rund um HTML5

ARIA

Accessible Rich Internet Applications (ARIA) ist ein Set von Attributen, das die Barrierefreiheit dynamischer Inhalte verbessert. Wo semantisches HTML nicht ausreicht, ergänzt ARIA Rollen, Zustände und Eigenschaften. Beispiel: role="alert" für eine Fehlermeldung. In komplexen Webanwendungen ist ARIA Pflicht.

Browser-Support

Browser-Support beschreibt die Verfügbarkeit eines Features in den verschiedenen Webbrowsern. Die Standard-Referenz ist caniuse.com. Bei Webprojekten 2026 sollte vor jedem Feature-Einsatz die aktuelle Support-Lage geprüft werden, insbesondere bei Mobile Safari.

Custom Elements

Custom Elements sind selbst definierte HTML-Elemente, die zum offiziellen Web-Components-Standard gehören. Entwickler registrieren neue Tags wie <my-card> direkt im Browser. Vorteil: kein Framework-Lock-in, gekapselte Logik, browserweit nutzbar.

Datalist

Das datalist-Element liefert Vorschlagswerte für Eingabefelder. Verknüpft mit einem <input> über das list-Attribut, zeigt der Browser eine Auswahlliste während der Eingabe. Native Autovervollständigung ohne JavaScript-Bibliothek.

DOCTYPE

DOCTYPE ist die erste Zeile jedes HTML-Dokuments. Seit HTML5 reicht die Kurzform <!DOCTYPE html>. Die Deklaration teilt dem Browser mit, dass er die Seite im Standards Mode rendern soll, nicht im Quirks Mode mit alten Render-Bugs.

Living Standard

Der HTML Living Standard ist die offizielle, versionslose Spezifikation der WHATWG. Diese Spezifikation ersetzt seit 2019 alle versionierten HTML-Standards. Charakteristisch sind tägliche Updates, kein festes Versionsende und kontinuierliche Weiterentwicklung. Die offizielle Adresse: html.spec.whatwg.org.

Pattern-Attribut

Das pattern-Attribut erlaubt reguläre Ausdrücke direkt im HTML-Markup. Browser prüfen die Eingabe gegen den Ausdruck, bevor das Formular abgeschickt wird. Beispiel: pattern="[0-9]{5}" für eine fünfstellige Postleitzahl.

Picture-Element

Das picture-Element liefert verschiedene Bildvarianten je nach Viewport oder Auflösung aus. Der Browser wählt aus mehreren <source>-Kindern die passendste Variante. Pflicht für responsive Bildauslieferung und Performance-Optimierung.

Polyfill

Ein Polyfill ist JavaScript-Code, der ein modernes Feature in älteren Browsern nachbildet. 2026 sind Polyfills nur noch in Legacy-Projekten relevant. Aktuelle Browser-Generationen kommen ohne Polyfills aus.

Semantisches HTML

Semantisches HTML nutzt Tags entsprechend ihrer Bedeutung. Beispiele: <nav> für Navigation, <article> für eigenständige Inhalte, <header> für Kopfbereiche. Saubere Auszeichnung verbessert Barrierefreiheit, SEO und Wartbarkeit. Seit BFSG ist saubere Auszeichnung für kommerzielle Webseiten Pflicht.

Shadow DOM

Shadow DOM ist Teil der Web Components. Diese Technologie bietet abgekapselte DOM-Bäume innerhalb eines Custom Elements. Styles und Skripte bleiben isoliert, Konflikte mit dem Hauptdokument entstehen nicht. Shadow DOM ist die technische Grundlage für browser-eigene Komponenten.

srcset

Das srcset-Attribut ergänzt <img> und <source>-Tags um Auflösungsvarianten. Der Browser wählt automatisch das passende Bild für Bildschirmdichte und Viewport-Größe. Mobile Datenmengen sinken dadurch drastisch.

Validator

Ein HTML-Validator prüft Markup auf Konformität gegen den Living Standard. Der offizielle Validator findet sich unter validator.w3.org. Bei Code-Reviews und vor jeder Veröffentlichung gehört der Validator zum Standardwerkzeug. Der Validator erkennt fehlerhaftes Markup, das Browser zwar tolerant rendern, das aber Probleme verursachen kann.

WHATWG

Die Web Hypertext Application Technology Working Group (WHATWG) ist seit 2019 alleinige Herausgeberin der HTML- und DOM-Standards. Die Gruppe wurde 2004 von Apple, Mozilla und Opera gegründet, als Reaktion auf die Stagnation der W3C-HTML-Entwicklung.

Quellen

• WHATWG | HTML Living Standard | https://html.spec.whatwg.org/ | besucht am 10.05.2026
• WHATWG | HTML FAQ (whatwg/html GitHub) | https://github.com/whatwg/html/blob/main/FAQ.md | besucht am 10.05.2026
• W3C | Memorandum of Understanding Between W3C and WHATWG | https://www.w3.org/2019/04/WHATWG-W3C-MOU.html | besucht am 10.05.2026
• Bundesministerium für Arbeit und Soziales | Barrierefreiheitsstärkungsgesetz (BFSG) | https://www.bmas.de/DE/Service/Gesetze-und-Gesetzesvorhaben/barrierefreiheitsstaerkungsgesetz.html | besucht am 10.05.2026
• Bundesfachstelle Barrierefreiheit | Das Barrierefreiheitsstärkungsgesetz | https://www.bundesfachstelle-barrierefreiheit.de/DE/Fachwissen/Produkte-und-Dienstleistungen/Barrierefreiheitsstaerkungsgesetz/barrierefreiheitsstaerkungsgesetz_node.html | besucht am 10.05.2026
• Mozilla Developer Network | HTML elements reference | https://developer.mozilla.org/de/docs/Web/HTML/Element | besucht am 10.05.2026
• caniuse.com | Browser-Support für HTML- und CSS-Features | https://caniuse.com/ | besucht am 10.05.2026

Artikelhistorie

Dieser Artikel entstand aus einer vollständigen Überarbeitung des Originalartikels „HTML5 – ein Überblick“, der erstmals im November 2009 erschienen war. Über die Jahre wurden Abschnitte ergänzt, ohne dass eine redaktionelle Gesamtüberarbeitung stattfand. Das Ergebnis war ein Flickenteppich aus Texten verschiedener Jahrgänge: ein Dialog-Element-Abschnitt mit Browsersupport-Daten von 2020, ein Web-Audio-API-Kapitel, das als eigenständiger Artikel besser aufgehoben ist, und Grundlagenpassagen aus der frühen HTML5-Ära.

Im Mai 2026 wurde der Artikel vollständig neu geschrieben. Inhaltlich ersetzt der neue Artikel den Begriff „HTML5″ durch die korrekte Bezeichnung „HTML Living Standard“, ergänzt moderne Features der Jahre 2023–2026 und liefert eine Referenztabelle mit 20 oft übersehenen HTML-Elementen. Der Web-Audio-API-Abschnitt wurde als eigenständiger Artikel ausgelagert.