Semantische Medien: audio, video & track

HTML bringt für Ton und Bewegtbild eigene Elemente mit: <video> und <audio> binden das Medium ein, <source> bietet dasselbe Medium in mehreren Formaten an, und <track> liefert die Textspuren für Untertitel, Beschreibungen und Kapitel. Zusammen mit dem controls-Attribut ergibt das einen vollständigen, tastaturbedienbaren Player ohne eine einzige Zeile JavaScript.

Bevor es diese Elemente gab, brauchte man Plugins und schwere Fremd-Player für jedes Video. Was davon übrig geblieben ist, ist die Gewohnheit: Auch heute noch wird regelmäßig ein 300-KB-JavaScript-Player geladen, um das zu tun, was der Browser von sich aus kann – und dabei geht die Semantik verloren, die Screenreader, Web-Crawler und Tastaturnutzer brauchen. Auf dieser Seite geht es um das native Medien-Set: welches Element wofür zuständig ist, welche Attribute wirklich zählen und wie du Medien einbindest, ohne dir die Ladezeit zu ruinieren.

Das Wichtigste in Kürze

• controls ist Pflicht, solange du keinen vollwertigen eigenen Player baust – es liefert tastaturbedienbare, beschriftete Bedienelemente gratis.
• <source> statt src, sobald du mehr als ein Format anbietest; der Browser nimmt das erste, das er versteht.
• <track kind="captions"> ist der Schlüssel zur Barrierefreiheit – eine abschaltbare WebVTT-Spur statt eingebrannter Pixel.
• preload="metadata" statt Vollausbau: So lädt nur die Kopfinformation, nicht der ganze Clip.
• width und height immer angeben – ohne sie springt das Layout, besonders bei loading="lazy".
• Autoplay mit Ton wird von allen aktuellen Browsern blockiert. Nur muted funktioniert – und ist trotzdem meistens die falsche Entscheidung.

video & audio: die Basis

Das controls-Attribut liefert die nativen Bedienelemente. Sie sind tastaturbedienbar, haben in jedem Browser korrekte Beschriftungen und werden von Screenreadern verstanden – ein Vorsprung, den ein Eigenbau erst mühsam aufholen muss:

<video controls width="800" height="450" poster="/img/vorschau.webp" preload="metadata">
  <source src="/video/clip.webm" type="video/webm" />
  <source src="/video/clip.mp4" type="video/mp4" />
  <track kind="captions" src="/video/clip.de.vtt" srclang="de" label="Deutsch" default />
  <p>
    Dein Browser kann dieses Video nicht abspielen.
    <a href="/video/clip.mp4" download>Video herunterladen (MP4, 12 MB)</a>
  </p>
</video>

<audio controls preload="metadata">
  <source src="/audio/folge.mp3" type="audio/mpeg" />
  <p><a href="/audio/folge.mp3" download>Folge als MP3 herunterladen</a></p>
</audio>

Die Attribute, die wirklich zählen

Ein Stolperstein bei booleschen Attributen: muted="false" schaltet den Ton nicht an. Boolesche Attribute wirken allein durch ihre Anwesenheit – wer sie loswerden will, muss sie entfernen, nicht auf false setzen. Dasselbe gilt für autoplay, loop und controls.

Der Fallback-Inhalt

Der Inhalt zwischen den Tags erscheint ausschließlich in Browsern, die das Element gar nicht kennen. Das ist heute praktisch keiner mehr – trotzdem lohnt er sich, weil er die einzige Stelle ist, an der du einen Download-Link unterbringen kannst, ohne das Layout zu belasten. Wichtig: Er greift nicht, wenn nur der Codec fehlt. Ein Browser, der <video> versteht, aber keines deiner Formate abspielen kann, zeigt einen leeren Player. Dagegen hilft nur ein breit unterstütztes Fallback-Format.

source: mehrere Formate anbieten

Mit mehreren <source>-Elementen bietest du dasselbe Medium in verschiedenen Formaten an. Der Browser geht die Liste von oben nach unten durch und nimmt das erste, das er versteht – also modernes und effizientes Format zuerst, breit unterstütztes zuletzt:

<video controls width="800" height="450">
  <source src="/video/clip.webm" type="video/webm; codecs=&quot;vp9, opus&quot;" />
  <source src="/video/clip.mp4" type="video/mp4; codecs=&quot;avc1.42E01E, mp4a.40.2&quot;" />
</video>

Der type-Wert ist mehr als Dokumentation: Ohne ihn muss der Browser jede Datei anfragen, um herauszufinden, ob er sie abspielen kann. Mit MIME-Typ und Codec-Angabe entscheidet er allein anhand des Markups – das spart bei mehreren Quellen echte Anfragen.

Für die Formatwahl reicht in der Praxis ein einfaches Bild:

Wer nur ein Format ausliefern will, nimmt MP4 mit H.264 – das läuft ausnahmslos überall. Wer Bandbreite sparen will, stellt WebM davor.

track: Untertitel, Kapitel und mehr

Das <track>-Element fügt Textspuren hinzu. Es kennt fünf Arten, und die Wahl ist nicht kosmetisch:

Für Barrierefreiheit brauchst du captions, nicht subtitles – der Unterschied liegt genau in den Geräuschen und Sprecherangaben, die gehörlosen Nutzern sonst fehlen.

<video controls width="800" height="450">
  <source src="/video/clip.mp4" type="video/mp4" />
  <track kind="captions" src="/video/clip.de.vtt" srclang="de" label="Deutsch" default />
  <track kind="chapters" src="/video/clip.kapitel.vtt" srclang="de" label="Kapitel" />
</video>

Die Spuren liegen als WebVTT-Datei (.vtt) vor – ein einfaches Textformat aus Zeitstempel und Text, das abschaltbar, skalierbar und durchsuchbar ist. Welche Alternativen die WCAG im Einzelnen verlangt und wie eine gute WebVTT-Datei aufgebaut ist, vertieft Untertitel & Transkripte.

Zwei Details, die regelmäßig Zeit kosten: src ist Pflicht – ein <track> ohne Quelle ist ungültig. Und liegt die .vtt-Datei auf einer anderen Domain, greift die Same-Origin-Policy: Dann brauchst du passende CORS-Header auf dem Server und crossorigin="anonymous" am <video>, sonst bleibt die Spur unsichtbar.

poster, preload und Performance

Video ist fast immer das größte Element einer Seite. Drei Attribute entscheiden darüber, ob es die Ladezeit ruiniert oder nicht.

• preload="metadata" ist der richtige Standardwert. Der Browser holt nur Laufzeit und Abmessungen; die Videodaten kommen erst beim Klick auf Abspielen. preload="auto" lädt dagegen den kompletten Clip – für Besucher, die ihn womöglich nie starten. Achtung: autoplay setzt preload außer Kraft, weil zum automatischen Start geladen werden muss.
• poster zeigt ein Vorschaubild, statt einen schwarzen Kasten. Es ist damit ein ganz normales Bild – und wenn das Video oben auf der Seite liegt, ist das Poster häufig das Element, an dem der LCP gemessen wird. Behandle es wie ein Hero-Bild: komprimiert, im richtigen Format, in der richtigen Größe.
• width und height reservieren den Platz, bevor das Medium geladen ist. Ohne sie springt der Inhalt beim Laden nach unten – ein direkter Beitrag zum CLS-Wert. Bei loading="lazy" ist es keine Empfehlung, sondern Pflicht: Ein noch nicht geladenes Video hat die Größe 0 × 0.

Randnotiz – Medien sind Schwergewichte. Ein einziges unkomprimiertes Hintergrund- video kann mehr Daten verbrauchen als der gesamte restliche Seiteninhalt zusammen. Bevor du an preload feilst, lohnt die grundsätzlichere Frage: Muss es überhaupt ein Video sein? Für kurze Abläufe reicht oft eine Bildstrecke, ein animiertes SVG oder einfach eine gute Erklärung in Text. Semantik und Performance gehen auch hier Hand in Hand – und Text ist das einzige Format, das jeder lesen, durchsuchen und übersetzen kann.

Autoplay: die Regeln der Browser

Automatisch startende Videos mit Ton werden von allen aktuellen Browsern blockiert. Erlaubt ist nur die stumme Variante:

<!-- funktioniert -->
<video autoplay muted playsinline loop preload="metadata" width="800" height="450">
  <source src="/video/hintergrund.mp4" type="video/mp4" />
</video>

playsinline ist dabei kein Beiwerk: Ohne dieses Attribut wechseln mobile Browser bei manchen Konstellationen in den Vollbildmodus, statt das Video im Layout zu belassen.

Unabhängig davon, was technisch erlaubt ist, gilt die inhaltliche Regel: 2.2.2 „Pausieren, beenden, ausblenden“ verlangt für alles, was länger als fünf Sekunden automatisch läuft, eine Möglichkeit zum Anhalten. Ein autoplayendes Hintergrundvideo ohne Pause-Knopf ist also ein WCAG-Verstoß – auch wenn es stumm ist. Wer prefers-reduced-motion respektiert und das Video bei entsprechender Systemeinstellung gar nicht erst startet, erspart sich und seinen Besuchern viel.

Medien in figure einbetten

Ein Video mit erklärender Bildunterschrift ist genau der Fall, für den es <figure> gibt:

<figure>
  <video controls width="800" height="450" preload="metadata">
    <source src="/video/aufbau.mp4" type="video/mp4" />
    <track kind="captions" src="/video/aufbau.de.vtt" srclang="de" label="Deutsch" default />
  </video>
  <figcaption>Der Aufbau eines HTML-Dokuments, Schritt für Schritt (4:12 Min.).</figcaption>
</figure>

Die Bildunterschrift ist dabei programmatisch mit dem Medium verknüpft – Details dazu bei figure & figcaption. Praktisch nebenbei: Die Laufzeit in der figcaption zu nennen, ist eine der wirksamsten kleinen Freundlichkeiten, die man Besuchern erweisen kann.

Native controls oder eigener Player?

Die nativen Bedienelemente haben zwei unschlagbare Vorteile: Sie sind in jedem Browser korrekt beschriftet, und sie funktionieren auch dann, wenn dein JavaScript nicht lädt. Ihr Nachteil: Sie sehen in jedem Browser anders aus und lassen sich kaum gestalten.

Die Abwägung sieht so aus:

• Native controls – erste Wahl für die allermeisten Fälle. Kostet nichts, funktioniert überall, keine Wartung.
• Etablierte Player-Bibliothek – sinnvoll, wenn du einheitliches Aussehen über Browser hinweg brauchst oder Funktionen wie Kapitelnavigation und mehrere Untertitelspuren komfortabel anbieten willst.
• Komplett eigener Player – nur mit Budget für Tastaturbedienung, Fokusreihenfolge, Beschriftungen und Tests. Das ist deutlich mehr Arbeit, als es aussieht: Alles, was der Browser gratis mitbringt, musst du dann nachbauen und dauerhaft pflegen.

Was ein selbstgebauter Player mindestens leisten muss, steht bei Barrierefreier Media-Player.

Häufige Fehler

• controls weggelassen ohne vollwertigen eigenen Player-Ersatz.
• Keine <track>-Untertitel – Video ohne Textspur ist nicht zugänglich.
• kind="subtitles" statt kind="captions" – ohne Geräusche und Sprecherangaben.
• Untertitel ins Bild gebrannt statt als abschaltbare Spur.
• width/height vergessen – Layout-Sprünge, besonders mit loading="lazy".
• preload="auto" auf einer Seite mit mehreren Videos – Megabytes für nichts.
• Autoplay mit Ton – wird blockiert und ist aufdringlich.
• Nur ein Exotenformat ohne breit unterstütztes Fallback.
• muted="false" in der Annahme, damit den Ton anzuschalten.
• <track> von fremder Domain ohne CORS und crossorigin.

Häufige Fragen

Brauche ich <source> oder reicht src am <video>?

Für ein einzelnes Format genügt src – das ist sogar etwas schlanker. Mehrere <source> lohnen sich, sobald du verschiedene Formate für Kompatibilität und Kompression anbietest.

Was ist WebVTT?

Ein einfaches Textformat für Untertitel und Kapitel: Zeitstempel plus Text, eingebunden über <track>. Die Datei beginnt zwingend mit der Zeile WEBVTT, und die Millisekunden werden mit einem Punkt abgetrennt – umbenannte SRT-Dateien funktionieren deshalb nicht.

Wie mache ich den Player zugänglich?

Am einfachsten mit den nativen controls. Sie sind tastaturbedienbar und beschriftet. Eigene Bedienelemente sind möglich, aber aufwendig – das entspricht auch der ersten Regel von ARIA: Nimm das native Element, solange es geht.

Wie binde ich YouTube-Videos ein?

Über einen <iframe> – dann gelten aber die Regeln der Plattform, und die Ladezeit leidet spürbar. Gib dem <iframe> in jedem Fall ein aussagekräftiges title-Attribut, damit er in der Elementliste eines Screenreaders erkennbar ist. Wer die Kontrolle über Datenschutz und Performance behalten will, hostet selbst und nutzt <video>.

Kann ich mitten im Video starten?

Ja, über Media-Fragmente am Ende der URL:

<video controls src="/video/clip.mp4#t=90"></video>

Das startet bei Sekunde 90; #t=90,120 begrenzt zusätzlich das Ende. Praktisch für Verweise auf eine bestimmte Stelle – setzt allerdings voraus, dass der Server Range-Requests unterstützt, was bei normalem Apache-Hosting der Fall ist.

Fazit

<video> und <audio> mit controls, <source> für mehrere Formate und <track> für Untertitel und Kapitel bilden ein vollständiges, semantisches Medien-Set – ganz ohne fremde Player. Ergänzt um poster, preload="metadata" sowie feste width und height bleibt es dabei auch noch schnell.

Der rote Faden ist derselbe wie im Rest des semantischen HTML: Das native Element bringt Bedeutung, Bedienbarkeit und Robustheit gratis mit. Mit echten Textspuren statt eingebrannter Untertitel und ohne Autoplay mit Ton hast du die Basis für zugängliche Medien gelegt – der Rest ist Sorgfalt beim Inhalt der Spuren.

Quellen

• <video>: Das Video-Einbettungs-Element (MDN Web Docs – vollständige Attributliste, preload-Werte, Autoplay-Richtlinien und Layout-Shift-Hinweise)
• Multimedia/Audio und Video (SELFHTML-Wiki – Formatunterstützung, source-Reihenfolge und track-Arten auf Deutsch)