HTML5-Tags: Referenz mit Beispielen

HTML-Tags sind keine Liste zum Auswendiglernen, sondern ein Werkzeug, um Bedeutung auszuzeichnen. Browser, Suchmaschinen-Crawler und Screenreader lesen dieselbe Seite auf unterschiedliche Weise, und das Einzige, worauf sie sich alle stützen, sind die gewählten Tags. Im Folgenden stehen alle aktuellen HTML5-Tags: was jedes bedeutet, wann es passt, welches Tag ein veraltetes abgelöst hat und welche Fehler im Markup am häufigsten vorkommen.

Wie ein HTML-Dokument aufgebaut ist

Jede Seite ist ein Baum. Der Baum hat eine Wurzel, <html>, und zwei Äste: <head> mit technischen Angaben und <body> mit dem, was der Besucher sieht. Alles Weitere verschachtelt sich in diese beiden Äste, und genau die Verschachtelung bestimmt, wie der Browser das DOM aufbaut und worauf CSS seine Stile anwendet.

Ein minimales gültiges HTML5-Dokument sieht so aus:

<!DOCTYPE html>
<html lang="de">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Seitentitel</title>
</head>
<body>
    <h1>Hallo</h1>
</body>
</html>

Vier Zeilen daraus sollte man verstehen. <!DOCTYPE html> schaltet den Browser in den Standardmodus — ohne ihn greift der Kompatibilitätsmodus für zwanzig Jahre alte Dokumente, und die Berechnung der Boxgrößen ändert sich. Das Attribut lang nennt Suchmaschine und Sprachausgabe die Sprache des Textes. <meta charset="UTF-8"> muss innerhalb der ersten 1024 Bytes stehen, sonst werden Sonderzeichen zu Fragezeichen. <meta name="viewport"> sorgt dafür, dass die Seite auf dem Handy nicht als „gesamte Desktop-Breite in Winzschrift“ erscheint.

Block- und Inline-Elemente

Historisch wurden Tags in Block- (div, p, section) und Inline-Elemente (span, a, strong) geteilt. Die HTML5-Spezifikation ersetzte das durch Inhaltskategorien, in der Praxis bleibt der Unterschied aber bestehen: ein Blockelement nimmt die volle verfügbare Breite und beginnt in einer neuen Zeile, ein Inline-Element fließt im Text mit. Eine Verschachtelungsregel ist wichtig: ein Inline-Element darf kein Blockelement enthalten. Die einzige Ausnahme ist <a>, das in HTML5 ganze Blöcke umschließen darf — praktisch, wenn eine komplette Produktkarte ein Link sein soll.

Semantische Seitenstruktur

Vor HTML5 bestand eine typische Seite aus ineinander verschachtelten <div>-Elementen mit Klassen wie header, menu, content, sidebar. Eine Maschine wusste nicht, was diese Klassen bedeuten — für sie waren es gleiche, namenlose Kisten. Semantische Tags gaben jedem Seitenteil einen eigenen Namen.

Der Unterschied zwischen <article> und <section> verwirrt am meisten. Die Prüfung ist einfach: Lässt sich ein Fragment aus der Seite schneiden, separat veröffentlichen und behält es seinen Sinn, dann ist es ein <article>. Ist es nur ein inhaltlicher Teil von etwas Größerem, dann ein <section>. Ein Blogbeitrag ist ein article. Der Abschnitt „Technische Daten“ in einer Produktbeschreibung ist eine section.

Eine typische Blogseite wird so ausgezeichnet:

<body>
  <header>
    <a href="/">Logo</a>
    <nav><a href="/blog/">Blog</a> <a href="/contacts/">Kontakt</a></nav>
  </header>

  <main>
    <article>
      <h1>Artikelüberschrift</h1>
      <p>Artikeltext…</p>
      <section>
        <h2>Abschnitt des Artikels</h2>
        <p>…</p>
      </section>
      <footer>Autor, Veröffentlichungsdatum</footer>
    </article>
  </main>

  <aside>Ähnliche Beiträge</aside>

  <footer>© 2026</footer>
</body>

Der Gewinn ist nicht abstrakt. Ein Screenreader lässt blinde Besucher direkt zu main springen und das Menü überspringen. Der Lesemodus des Browsers erkennt article und zeigt nur den Text. Der Crawler erkennt genauer, wo der eigentliche Inhalt steht und wo das auf allen Seiten wiederholte Beiwerk beginnt.

Text: Überschriften, Absätze und Hervorhebungen

Diese Tags nutzt man täglich — und gerade bei ihnen wird Aussehen am häufigsten mit Bedeutung verwechselt.

Der Unterschied zwischen <strong> und <b> liegt in der Bedeutung, nicht im Schnitt. „Achtung: der Server startet neu“ ist strong, weil der Satz wichtig ist. Ein Produktname, aus typografischer Gewohnheit fett gesetzt, ist b. Ebenso bei <em> und <i>: das erste ändert den Sinn des Satzes, das zweite neigt nur die Schrift.

Für Überschriften gilt eine Regel, die ständig gebrochen wird: die Ebenen bilden die Gliederung des Dokuments, nicht eine Auswahl von Schriftgrößen. Folgt auf h2 ein h4, entsteht ein Loch in der Struktur. Kleinere Schrift ist Aufgabe von CSS und kein Grund, eine Ebene tiefer zu greifen.

Listen

HTML kennt drei Listen, jede für ihren Zweck.

<ul>                        <!-- ungeordnet, Reihenfolge egal -->
  <li>Erster Punkt</li>
  <li>Zweiter Punkt</li>
</ul>

<ol start="3" reversed>      <!-- geordnet, Reihenfolge zählt -->
  <li>Der dritte</li>
</ol>

<dl>                         <!-- Beschreibungsliste -->
  <dt>HTML</dt>
  <dd>Auszeichnungssprache für Dokumente</dd>
  <dt>CSS</dt>
  <dd>Sprache zur Beschreibung der Darstellung</dd>
</dl>

<ol> hat nützliche Attribute, die oft vergessen werden: start setzt den Anfang der Nummerierung, reversed dreht sie um, type wechselt zu Buchstaben oder römischen Zahlen. Die Beschreibungsliste <dl> passt hervorragend zu Glossaren, Produktdaten und FAQ-Blöcken: Paare aus Begriff und Beschreibung liest die Maschine als zusammengehörig, anders als zwei benachbarte Absätze.

Ein Seitenmenü ist ebenfalls eine Liste. Nur durch Leerzeichen getrennte Links liest ein Screenreader als fortlaufenden Text; eine Liste kündigt er als „Navigation, 5 Einträge“ an.

Links und Navigation

<a> ist das zentrale Tag des Hypertexts, und einige Attribute sollte man auswendig kennen.

<a href="/blog/">Interner Link</a>
<a href="https://example.com" target="_blank" rel="noopener noreferrer">Extern</a>
<a href="#section-2">Anker auf derselben Seite</a>
<a href="mailto:[email protected]">E-Mail</a>
<a href="tel:+380675024584">Anrufen</a>
<a href="/price.pdf" download>Preisliste laden</a>

target="_blank" ohne rel="noopener" ist eine alte Sicherheitslücke: die geöffnete Seite erhält Zugriff auf window.opener und kann den ursprünglichen Tab austauschen. Moderne Browser ergänzen noopener selbst, sich in fremder Umgebung darauf zu verlassen ist dennoch unklug.

rel trägt auch SEO-Bedeutung: rel="nofollow" sagt der Suchmaschine, kein Gewicht weiterzugeben, rel="sponsored" kennzeichnet bezahlte Links, rel="ugc" solche aus Nutzerinhalten. Der Linktext selbst muss aussagekräftig sein: „mehr“ und „hier“ sind für Suchmaschine wie für jemanden, der die Seite per Screenreader hört und eine Linkliste ohne umgebenden Text bekommt, gleichermaßen nutzlos.

Bilder, Video und Audio

Ein Bild in HTML ist mehr als <img>. Um es herum steht eine ganze Tag-Familie, die zwei Aufgaben löst: das Bild zu beschriften und dem Browser eine passend schwere Datei zu liefern.

<figure>
  <img src="/img/scheme.webp"
       alt="Schema der Struktur eines HTML-Dokuments"
       width="1200" height="630"
       loading="lazy" decoding="async">
  <figcaption>Der Dokumentbaum: eine Wurzel und zwei Äste</figcaption>
</figure>

Das Attribut alt ist immer Pflicht. Es beschreibt den Inhalt für alle, die das Bild nicht sehen, und erscheint, wenn die Datei nicht lädt. Für rein dekorative Bilder schreibt man ein leeres alt="" — dann überspringt der Screenreader es, während ein fehlendes Attribut ihn den Dateinamen vorlesen lässt. width und height dienen nicht der Größe, sondern der Platzreservierung: ohne sie springt die Seite beim Laden, was den Cumulative Layout Shift in den Core Web Vitals direkt verschlechtert. loading="lazy" verschiebt Bilder außerhalb des Sichtbereichs.

Wenn verschiedene Bildschirme verschiedene Dateien brauchen, kommt <picture> ins Spiel:

<picture>
  <source srcset="/img/hero.avif" type="image/avif">
  <source srcset="/img/hero.webp" type="image/webp">
  <img src="/img/hero.jpg" alt="Beschreibung">
</picture>

Der Browser nimmt das erste Format, das er versteht, und hört dort auf. Ein alter Browser landet bei <img> und bekommt das JPEG. Derselbe Kniff mit dem Attribut media zeigt am Handy ein Hochformat und am Desktop ein Querformat.

Autoplay funktioniert nur als autoplay muted playsinline — ohne muted blockiert der mobile Browser es. Einem <iframe> sollte stets ein title mitgegeben werden: der Screenreader kündigt den Rahmen damit an, sonst hört der Besucher einen namenlosen „eingebetteten Bereich“.

Tabellen

Tabellen sind zurück im Einsatz, seit man sie nicht mehr für Layout verwendet. Für echte tabellarische Daten gibt es keine Alternative — ausgezeichnet werden müssen sie aber vollständig.

<table>
  <caption>Hosting-Tarife</caption>
  <thead>
    <tr><th scope="col">Tarif</th><th scope="col">Speicher</th><th scope="col">Preis</th></tr>
  </thead>
  <tbody>
    <tr><th scope="row">Start</th><td>10 GB</td><td>3 $</td></tr>
    <tr><th scope="row">Business</th><td>50 GB</td><td>9 $</td></tr>
  </tbody>
  <tfoot>
    <tr><td colspan="3">Preise ohne MwSt.</td></tr>
  </tfoot>
</table>

Drei Dinge unterscheiden eine ausgezeichnete Tabelle von einem Raster aus Zellen. <caption> gibt ihr einen Namen, der zuerst vorgelesen wird. <th> mit scope erklärt die Zelle zur Spalten- oder Zeilenüberschrift, sodass der Screenreader beim Wandern durch die Zellen sagt: „Business, Preis, 9 Dollar“. Die Trennung in <thead>, <tbody> und <tfoot> erlaubt dem Browser, den Kopf beim Druck langer Tabellen zu wiederholen und den Körper getrennt zu scrollen.

Auf schmalem Bildschirm ist eine breite Tabelle stets ein Problem. Zwei Lösungen funktionieren: in einen Container mit overflow-x: auto packen und scrollen lassen, oder die Zeilen per CSS zu Karten umbauen und die Spaltenüberschriften aus data-label holen. Beides hält das Markup korrekt — kaputt macht die Tabelle erst der Versuch, sie durch kleinere Schrift in die Bildschirmbreite zu quetschen.

Formulare und Eingabefelder

Formulare sind die größte Tag-Gruppe und der einzige Ort, an dem HTML nicht nur zeigt, sondern Daten sammelt.

<form action="/send/" method="post">
  <fieldset>
    <legend>Anfrage</legend>

    <label for="name">Name</label>
    <input type="text" id="name" name="name" required autocomplete="name">

    <label for="mail">E-Mail</label>
    <input type="email" id="mail" name="email" required
           placeholder="[email protected]" autocomplete="email">

    <label for="plan">Tarif</label>
    <select id="plan" name="plan">
      <optgroup label="Hosting">
        <option value="start">Start</option>
        <option value="pro" selected>Business</option>
      </optgroup>
    </select>

    <label for="msg">Nachricht</label>
    <textarea id="msg" name="message" rows="5"></textarea>

    <button type="submit">Senden</button>
  </fieldset>
</form>

Die Verbindung von <label for> mit der id des Feldes ist keine Formalie. Sie vergrößert die Klickfläche — ein Klick auf die Beschriftung setzt den Cursor ins Feld — und sagt dem Screenreader, wonach gefragt wird. Ein Feld ohne Beschriftung, bei dem der placeholder diese Rolle übernimmt, ist ein verbreiteter Fehler: der Hinweis verschwindet beim ersten Zeichen, und der Besucher weiß nicht mehr, was er ausfüllt.

Der Feldtyp bestimmt sowohl die Tastatur am Handy als auch die eingebaute Prüfung:

Die HTML-eigene Validierung läuft ohne eine Zeile JavaScript: required verbietet das Absenden eines leeren Feldes, minlength und maxlength begrenzen die Länge, pattern setzt einen regulären Ausdruck, min und max die Grenzen von Zahl und Datum. Das ist eine erste Linie, kein Schutz: die serverseitige Prüfung ersetzt sie nicht, denn jede Anfrage lässt sich am Formular vorbei senden.

Zwei weitere Tags dieser Gruppe verdienen Beachtung. <datalist> gibt dem Feld Vorschläge und lässt dennoch eigene Werte zu. <output> zeigt ein Rechenergebnis — etwa die Bestellsumme, neu berechnet bei geänderter Menge.

Interaktive Elemente ohne JavaScript

Ein Teil des Verhaltens, für das früher Skripte nötig waren, steckt in HTML5 bereits drin.

<details>
  <summary>Was gehört zur Website-Betreuung?</summary>
  <p>Updates, Sicherungen, Verfügbarkeitsüberwachung.</p>
</details>

<dialog id="modal">
  <p>Anfrage gesendet</p>
  <button onclick="modal.close()">Schließen</button>
</dialog>

<progress value="70" max="100">70%</progress>
<meter value="0.8" low="0.3" high="0.9">80%</meter>

<details> mit <summary> ist ein fertiges Akkordeon: klappt per Klick auf, funktioniert mit der Tastatur, wird von Suchmaschinen indexiert. Ein FAQ-Block auf dieser Basis braucht keine Zeile JavaScript. <dialog> ist ein Modalfenster mit korrektem Fokusverhalten: showModal() hält den Fokus im Fenster und schließt per Escape. <progress> zeigt den Fortschritt, <meter> einen Wert in bekanntem Bereich, etwa die Speicherbelegung.

Technische Tags im <head>

Diese Tags sieht der Besucher nie, doch sie entscheiden, wie die Seite in den Suchergebnissen und in sozialen Netzen aussieht.

<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>HTML5-Tags: Referenz</title>
  <meta name="description" content="Alle aktuellen HTML5-Tags mit Beispielen">
  <link rel="canonical" href="https://example.com/html5/">
  <link rel="alternate" hreflang="uk" href="https://example.com/uk/html5/">
  <link rel="icon" href="/favicon.svg" type="image/svg+xml">
  <link rel="stylesheet" href="/style.css">
  <meta property="og:title" content="HTML5-Tags: Referenz">
  <meta property="og:image" content="https://example.com/img/cover.webp">
  <script src="/app.js" defer></script>
</head>

<title> ist das gewichtigste Textsignal für Suchmaschinen und das, was der Besucher im Tab sieht. <link rel="canonical"> nennt die Hauptadresse einer Seite, wenn mehrere URLs mit Parametern zu ihr führen. hreflang verknüpft die Sprachversionen — für eine mehrsprachige Website Pflicht, sonst zeigt die Suchmaschine die falsche Fassung. Die og:-Angaben bestimmen, wie der Link im Messenger und im sozialen Netz erscheint.

Zum Einbinden von Skripten eines: ein <script> ohne Attribute hält das Parsen des Dokuments an, bis die Datei geladen und ausgeführt ist. defer verschiebt die Ausführung ans Ende des Parsens und bewahrt die Reihenfolge, async führt sofort nach dem Laden aus und garantiert keine Reihenfolge. Für Zähler passt async, für Anwendungscode defer.

Veraltete Tags und ihr Ersatz

Browser stellen diese noch dar, die Spezifikation hat sie jedoch gestrichen: ein Teil regelte Gestaltung, die längst in CSS gehört, ein Teil schadete schlicht.

Eine eigene Geschichte ist <hgroup>. Es wurde aus der Spezifikation entfernt, später mit anderer Bedeutung zurückgeholt; heute genügt für Titel und Untertitel ein gewöhnliches <p> neben der Überschrift.

Häufige Fehler im Markup

• Mehrere <h1> auf einer Seite. Die Überschrift erster Ebene beschreibt die ganze Seite, und sie ist einzig. Alles andere liegt eine Ebene tiefer.
• Ein Block im Absatz. Ein <div> in <p> korrigiert der Browser stillschweigend, indem er den Absatz früher schließt — und das Layout verrutscht ohne sichtbaren Grund.
• <br> statt Abständen. Drei Umbrüche hintereinander versuchen im Markup, was margin sauber erledigt.
• Bild ohne alt. Barrierefreiheit und Bildersuche-Traffic gehen beide verloren.
• Ein Button aus <div>. So ein „Button“ braucht Tastaturbehandlung, role und tabindex, während <button> das von Haus aus kann.
• Ein Link ohne href. Das Element fällt aus der Tastaturnavigation. Keine Adresse — dann <button>.
• Tabelle als Layout. Auf dem Handy bricht solches Markup nicht um, und der Screenreader liest es als Datentabelle vor.
• <div> statt Semantik. Eine Seite aus lauter div funktioniert, verliert aber alles, was Markup mit Bedeutung bringt: schnelle Navigation, Lesemodus, klare Struktur für Suchmaschinen.

Wie man das Markup prüft

Drei Werkzeuge decken fast alle Fehler ab. Der W3C-Validator findet nicht geschlossene Tags, falsche Verschachtelung und nicht existierende Attribute. Der Reiter Accessibility in den Entwicklerwerkzeugen zeigt den Accessibility-Baum — das, was ein Screenreader „sieht“. Lighthouse in Chrome prüft Semantik zusammen mit Geschwindigkeit und liefert eine Liste konkreter Hinweise.

Eine Selbstprüfung ist mehr wert als alle drei: öffnen Sie die Seite mit abgeschaltetem CSS. Liest sich das Dokument ohne Stile weiterhin von oben nach unten als sinnvoller Text mit Überschriften, Listen und Bildunterschriften, ist das Markup richtig. Wird es zum Brei, liegt es nicht an den Stilen, sondern an den Tags.

Das Wichtigste in Kürze

Behält man eine Handvoll Regeln im Kopf, ergibt sich der Rest von selbst:

• Das Tag wird nach Bedeutung gewählt, nicht nach Aussehen. Das Aussehen jedes Elements ändert eine Zeile CSS, die im Tag steckende Bedeutung lesen dagegen Maschinen — und kein Stylesheet ändert sie.
• Die Seitenstruktur ist header, nav, main, article, section, aside, footer. <div> bleibt für Fälle, in denen keines davon passt — nicht umgekehrt.
• Überschriften bilden die Gliederung des Dokuments. Ein h1, danach der Reihe nach, ohne Ebenen zu überspringen.
• Drei Attribute, die am häufigsten vergessen werden: alt am Bild, for an der Feldbeschriftung und title am Rahmen. Jedes kostet zwei Minuten und bringt spürbar mehr Barrierefreiheit.
• Ein Formular kann sich selbst prüfen. Der richtige type plus required und pattern decken den Großteil der Validierung ohne JavaScript ab — die Prüfung auf dem Server ersetzen sie nicht.
• Alles zur Gestaltung gehört in CSS. Genau deshalb haben font, center und ihre Nachbarn die Spezifikation verlassen.

Gutes Markup fällt kaum auf: die Website funktioniert einfach — sie lädt schnell, liest sich am Handy gut, sieht in den Suchergebnissen und im Messenger richtig aus und ist mit einem Screenreader bedienbar. Schlechtes Markup bemerkt man sofort, behandelt es aber meist an der falschen Stelle: Stile werden geflickt, Skripte eingebunden, Plugins installiert — während die Ursache in zwei, drei falsch gewählten Tags liegt.

Prüfen Sie Ihre Seite gleich jetzt: öffnen Sie den Quelltext und zählen Sie, wie viele <div> darin stehen und wie viele Tags mit Bedeutung. Überwiegen die ersten im Verhältnis drei zu eins, arbeiten Sie diesen Artikel von oben nach unten durch. Die ganze Website muss dafür nicht neu geschrieben werden: meist genügt es, einige Container umzubenennen und die fehlenden Attribute zu ergänzen.