Videoformate in WordPress: MOV, MP4 oder WebM (Adobe Effects & Web)

Ein typisches Problem von Motion Designern und Videoeditoren, die mit Websites anfangen: “Ich habe in Adobe After Effects eine schöne Animation gebaut, als .mov gerendert (in bester Qualität!), in WordPress hochgeladen, und nichts. Schwarzer Bildschirm, Fehlermeldung, oder die Datei wiegt 500 MB und lädt eine Ewigkeit.”

Die Datei ist nicht kaputt. Sie wurde für einen Schnittplatz gemacht, und ein Browser ist kein Schnittplatz.

#Warum MOV-Dateien in WordPress nicht abspielen

Das Format .mov (der QuickTime-Container) ist in der Kreativbranche Standard, vor allem auf dem Mac. .mov ist ein Container, kein Codec. Unbrauchbar für das Web macht ihn meist das, was darin steckt: ProRes oder unkomprimierte Frames.

Die Dateigrößen sind keine Ansichtssache. Apple veröffentlicht sie. Bei 1920x1080 und 29,97 fps nennt das ProRes-Whitepaper Zieldatenraten von 45 Mbit/s für 422 Proxy, 102 Mbit/s für 422 LT, 147 Mbit/s für 422, 220 Mbit/s für 422 HQ, 330 Mbit/s für 4444 und 495 Mbit/s für 4444 XQ. Der Anhang desselben Dokuments rechnet das in Gigabyte pro Stunde um: 422 HQ sind 99 GB pro Stunde, also etwa 1,65 GB für eine einzige Minute Material. Ein zwanzigsekündiger Hero-Loop direkt aus After Effects kann deshalb größer sein als der gesamte Rest der Website.

In WordPress geht dann zweierlei schief, in dieser Reihenfolge.

Der Upload kommt womöglich gar nicht durch. wp_max_upload_size() liest upload_max_filesize und post_max_size aus PHP und gibt den kleineren der beiden Werte zurück. Auf Shared Hosting stehen diese oft noch auf bescheidenen Standardwerten, und ein POST mit mehreren hundert Megabyte stirbt, bevor die Mediathek ihn überhaupt sieht.

Kommt er durch, spielt die Datei trotzdem nicht ab. WordPress akzeptiert die Datei, weil wp_get_mime_types() den Eintrag 'mov|qt' => 'video/quicktime' enthält. Aber wp_get_video_extensions(), die Funktion, die festlegt, was der Core als abspielbare Videoquelle betrachtet, gibt nur mp4, m4v, webm, ogv und flv zurück. MOV steht nicht auf dieser Liste. Der Anhang liegt also in der Mediathek, sieht aus wie ein Video und verhält sich wie ein Download.

Das Markup von Hand zu erzwingen, rettet dich auch nicht. Laut MDN-Leitfaden zu Containern unterstützen QuickTime nur ältere Safari-Versionen sowie andere Browser, die früher Apples QuickTime-Plugin unterstützt haben. MDN markiert jeden Codec in seiner QuickTime-Tabelle als in Firefox nicht unterstützt und weist darauf hin, dass das QuickTime-Framework ab macOS 10.15 Catalina überhaupt nicht mehr verfügbar ist. ProRes taucht unter den Codecs, die MDNs Leitfaden zu Videocodecs für Browser dokumentiert, nicht auf.

#Warum ProRes nicht fürs Web gedacht ist

ProRes wurde für den professionellen Schnitt entwickelt, wo es darum geht, über mehrere Runden Color Grading und Compositing die maximale Qualität zu halten. Jeder Frame wird mit leichter Intra-Frame-Kompression gespeichert. Das macht die Dateien riesig, aber in der Postproduktion leicht zu scrubben und zu schneiden.

Das Web hat andere Prioritäten. Besucher erwarten, dass ein Video in Sekunden startet. Mobile Verbindungen haben begrenzte Bandbreite. Browser brauchen Codecs, die auf effizientes Decodieren ausgelegt sind, und MDN sagt das in seinem Codec-Leitfaden auch so: Kein verlustfreier oder nahezu verlustfreier Codec ist in Browsern allgemein verfügbar, weil unkomprimiertes 1080p mit 4:2:0-Subsampling schon mindestens 1,5 Gbit/s braucht.

#Verbessert ein Export in maximaler Qualität das Webvideo

Viele Designer gehen davon aus, dass bessere Qualität ein besseres Erlebnis bedeutet. Eine Master-Datei, die Minuten bis zur Ankunft braucht, liefert ein schlechteres Erlebnis als eine komprimierte Kopie, die sofort losläuft und die ein normaler Zuschauer auf einem Laptop-Bildschirm nicht vom Master unterscheiden kann.

#Welche Videoformate WordPress unterstützt

Zwei Formate decken das ganze Web ab, und die Wahl zwischen ihnen ist weniger dramatisch als zu der Zeit, als dieser Artikel zum ersten Mal erschien.

#1. MP4 mit H.264 (AVC)

Der sichere Standard. caniuse beziffert die weltweite Unterstützung von H.264 in MP4 auf 97,26 Prozent (Daten geprüft am 12. Oktober 2026), zurück bis Chrome 4 und Safari 3.2. Wenn du nur eine Datei auslieferst, dann diese.

Zwei Einstellungen entscheiden, ob dein Export tatsächlich funktioniert, und beide siehst du in einem Vorschau-Player nicht.

Chroma-Subsampling. ProRes 422 ist, wie der Name sagt, 4:2:2, und die 422-Familie arbeitet mit 10 Bit. Gibst du das ohne weitere Anweisung an libx264, codiert es einen Stream im Profil High 4:2:2, den Browser nicht decodieren. Wir haben das mit einer ProRes-422-HQ-Testdatei geprüft: Ohne Flag für das Pixelformat meldete ffprobe die Ausgabe als High 4:2:2 mit yuv422p10le. Erzwinge 8 Bit 4:2:0 mit -pix_fmt yuv420p.

Wo der Index liegt. Die Muxer-Dokumentation von FFmpeg beschreibt -movflags +faststart als Option, die in einem zweiten Durchlauf den Index (das moov-Atom) an den Anfang der Datei verschiebt, und weist darauf hin, dass sie standardmäßig nicht aktiv ist. Ohne sie kann der Browser die Wiedergabe erst beginnen, wenn die ganze Datei angekommen ist, und genau das ist das Symptom “lädt eine Ewigkeit”.

Wenn du aus dem Adobe Media Encoder exportierst statt über die Kommandozeile, wähle als Format H.264, nicht QuickTime, und prüfe danach beide Einstellungen am Ergebnis. Entscheidend ist allein die Formatliste, die Namen der Presets wechseln zwischen den Versionen.

#Empfohlene Exporteinstellungen für H.264

Für verlässliche Ergebnisse beim Export für WordPress:

• Auflösung: 1920x1080 für inhaltliche Videos, 1280x720 für Nebenclips.
• Qualität: CRF zwischen 23 und 28 in libx264, statt einer festen Bitrate hinterherzulaufen.
• Bildrate: die Bildrate der Quelle beibehalten (meist 24, 25 oder 30 fps).
• Audio: AAC mit 128 bis 192 kbit/s Stereo, oder gar keine Tonspur, wenn der Clip dekorativ ist.
• Pixelformat: yuv420p, geprüft mit ffprobe an der exportierten Datei.
• Profil und Level: mit -profile:v high -level:v 4.0 für 1080p festlegen, damit die Datei zum codecs-String passt, den du im Markup deklarierst (mehr dazu weiter unten).

#2. WebM mit VP9

Ein offenes Format, entwickelt von Google. Auf Googles VP9-Seite heißt es, der Codec könne die Video-Bitrate im Vergleich zu anderen bekannten Codecs um bis zu 50 % senken. Sieh das als Obergrenze, die bei schwierigem Material erreicht wird, nicht als Wert, den du bei jedem Clip triffst. Bei einer flächigen Motion-Grafik ist die Ersparnis aber real.

Der veraltete Rat zu diesem Thema lautet, WebM sei ein Format für Chrome und Firefox. Das ist es seit Jahren nicht mehr. caniuse verzeichnet volle WebM-Unterstützung in Safari auf macOS ab Version 16 und in Safari auf iOS ab 17.4, wobei Safari 14.1 bis 15.6 es auf macOS 11.3 Big Sur oder neuer bereits abspielt. Damit liegt die volle Unterstützung weltweit bei 96,05 Prozent, gut einen Punkt hinter H.264 in MP4.

#Browserunterstützung für den AV1-Codec

AV1 ist eine Generation weiter und komprimiert besser als VP9, aber die Verbreitung hinkt hinterher. caniuse gibt 80,39 Prozent volle Unterstützung an, die erst auf 95,02 Prozent steigt, wenn man teilweise Unterstützung mitzählt. Safari ist der Teilfall: Auf macOS und iOS decodiert es AV1 nur auf Geräten mit Hardware-Decoder, etwa dem iPhone 15 Pro oder einem MacBook Pro mit M3.

Der Leitfaden zu Videocodecs von MDN empfiehlt inzwischen WebM mit AV1 und Opus als erste Wahl für eine typische Website und MP4 mit AVC und AAC als breit kompatible zweite. Damit ist AV1 ein erstes <source>, nie das einzige. Das Encoding von AV1 ist außerdem deutlich langsamer als bei H.264 oder VP9, es lohnt sich also bei Inhalten, die einmal codiert und oft abgespielt werden.

#HTML5-Video-Tag mit WebM- und MP4-Quellen

Wenn du selbst hosten musst, etwa für einen Hero-Hintergrund, liste die Quellen von der besten an. Der Browser nimmt die erste, die er decodieren kann, und schaut sich den Rest nie an.

<video autoplay loop muted playsinline preload="none"
       poster="/media/hero-poster.avif"
       width="1920" height="1080">
  <source src="/media/hero.webm" type='video/webm; codecs="vp9, opus"'>
  <source src="/media/hero.mp4" type='video/mp4; codecs="avc1.640028, mp4a.40.2"'>
  Dein Browser unterstützt keine Videos.
</video>

Die Attribute haben jeweils eine bestimmte Aufgabe:

• muted plus playsinline: Mobile Browser verweigern Autoplay ohne beide. Ohne playsinline schaltet iOS das Video in den Vollbildmodus, sobald es startet, und das zerstört einen Hintergrund-Loop.
• preload="none": Es wird nichts geladen, bevor die Wiedergabe angefordert wird, also trägt das Poster den ersten Paint. Nimm metadata, wenn du die Dauer vorab brauchst, und auto so gut wie nie.
• poster: Ein Standbild in AVIF oder WebP ist ein Bruchteil des Videos und das, was der Besucher in den ersten Sekunden tatsächlich sieht.
• der codecs=-Teil des type-Strings: Damit kann der Browser eine Quelle ablehnen, ohne ein einziges Byte davon herunterzuladen.
• width und height: Setze sie immer, damit der Platz reserviert ist, bevor das Video lädt. Das verhindert Cumulative Layout Shift, eine der Core Web Vitals.

#So schreibst du den codecs-String für MP4 und WebM

Frühere Versionen dieses Artikels deklarierten avc1.42E01E für die MP4-Quelle. Dieser String deklariert das Baseline-Profil (42) auf Level 3.0, während der FFmpeg-Befehl weiter unten eine Datei im High-Profil erzeugt. Ein codecs-String, der einen anderen Stream beschreibt als den, den du auslieferst, ist eine falsche Angabe gegenüber dem Browser.

Der MDN-Leitfaden zum codecs-Parameter definiert die AVC-Form als avc1.PPCCLL: zwei Hex-Ziffern für das Profil, zwei für die Constraint-Flags, zwei für das Level. Das High-Profil ist 64 mit den Constraints 00, und Level 4.0 ist dezimal 40, hexadezimal 28. High auf Level 4.0 ist also avc1.640028. AAC-LC-Audio in MP4 ist mp4a.40.2. Für WebM nennt MDN die Kurzformen vp9, vp8, opus und vorbis.

Lies die echten Werte aus der exportierten Datei, statt sie zu raten:

ffprobe -v error -select_streams v:0 \
  -show_entries stream=profile,level,pix_fmt -of csv=p=0 web.mp4

In unserem Test kam ein 1080p-Encode mit -preset slow und ohne Level-Flag als High,50 zurück, also Level 5.0, weil das Preset slow mehr Referenzframes verwendet, als Level 4.0 bei dieser Auflösung zulässt. Mit -profile:v high -level:v 4.0 kam High,40 zurück, und genau das deklariert avc1.640028.

#Attribute des Video-Blocks im Block-Editor

Im Block-Editor musst du das Tag nicht von Hand schreiben. Die block.json des Core-Blocks Video führt autoplay, controls, loop, muted, playsInline, poster, preload, src und tracks als Attribute, wobei preload standardmäßig auf metadata steht, und playsInline hat einen eigenen Schalter in der Seitenleiste. Der Cover-Block hat kein solches Attribut: Seine block.json deklariert keinen Schlüssel playsInline, und seine Save-Ausgabe setzt autoPlay, muted, loop und playsInline am Hintergrundvideo fest im Code. Ein Video-Loop im Cover-Block läuft also immer inline, und es gibt keinen Schalter, den du prüfen müsstest. Keiner der beiden Blöcke schreibt einen codecs-Parameter ins Markup.

#Wie der Video-Shortcode die Quellen auswählt

Klassische Inhalte und viele Page Builder laufen weiterhin über den Shortcode [video], den der Core mit wp_video_shortcode() rendert. Der Quellcode in wp-includes/media.php erklärt mehrere Dinge, die als Bugs gemeldet werden.

• Aus einer MOV wird ein Link. Zeigt src auf eine Datei, deren Endung nicht in wp_get_video_extensions() steht, gibt die Funktion statt eines Players einen einfachen Link <a class="wp-embedded-video"> auf die Datei zurück.
• Die Reihenfolge der Quellen ist fest. Du kannst pro Endung ein Attribut übergeben (mp4, m4v, webm, ogv, flv), und die Funktion gibt die <source>-Elemente in genau dieser Reihenfolge aus. [video webm="a.webm" mp4="a.mp4"] setzt die MP4 deshalb an die erste Stelle, und jeder Browser, der H.264 decodiert, nimmt sie.
• Der type enthält keine codecs. Jedes <source> bekommt einen nackten MIME-Typ aus wp_check_filetype(), etwa video/mp4.
• Standardwerte. preload ist metadata, muted ist false, und der Player misst 640x360, sofern du nicht width und height übergibst. Eine größere Breite wird auf die $content_width des Themes herunterskaliert.
• Player-Bibliothek. Die Ausgabe wird standardmäßig für MediaElement.js verpackt, der Filter wp_video_shortcode_library ändert das.

Fügst du mov über den Filter wp_video_extensions hinzu, rendert der Shortcode dafür einen Player, aber Chrome oder Firefox bekommen dadurch keinen Decoder. Die Lösung bleibt also das Neucodieren.

#MIME-Typen auf dem Server für MP4 und WebM

Eine Datei kann perfekt codiert sein und trotzdem mit dem falschen Content-Type ausgeliefert werden. Prüfe den Response-Header im Netzwerk-Tab des Browsers. Die Standarddatei mime.types von nginx ordnet mp4 bereits video/mp4 zu, webm video/webm und mov video/quicktime. Kommt der Header auf Apache als text/plain oder application/octet-stream zurück, ergänze die Zuordnung in der .htaccess:

AddType video/mp4 .mp4
AddType video/webm .webm

#Dateigröße von Videos optimieren

Die Dateigröße zählt für das Nutzererlebnis und für SEO. Ein Video, das zu lange lädt, erhöht die Absprungrate und zieht die Core Web Vitals nach unten.

Eine allgemeingültige Tabelle mit Zielgrößen gibt es nicht: Dieselbe Sekunde Material wiegt in einer statischen Einstellung ganz anders als in einem körnigen Schwenk. Lege die Qualität mit CRF fest, miss die entstandene Datei und entscheide anhand dieser Zahl.

#Kostenlose Tools zur Komprimierung

1. HandBrake: kostenlos und Open Source. Die Funktionsliste nennt AV1, H.265, H.264, MPEG-4, MPEG-2, VP8 und VP9 als Video-Encoder sowie MP4, MKV und WebM als Container.
2. FFmpeg: das Kommandozeilenwerkzeug hinter den meisten anderen und das, das in allen Beispielen hier verwendet wird.
3. Shutter Encoder: eine grafische Oberfläche für FFmpeg, leichter für den Einstieg.

#Video mit FFmpeg komprimieren

# MOV zu Web-MP4 (H.264, High-Profil, Level 4.0)
ffmpeg -i input.mov -c:v libx264 -preset slow -crf 23 \
  -profile:v high -level:v 4.0 -pix_fmt yuv420p \
  -c:a aac -b:a 128k -movflags +faststart output.mp4

# MOV zu WebM mit VP9 und Opus
ffmpeg -i input.mov -c:v libvpx-vp9 -crf 33 -b:v 0 -row-mt 1 \
  -pix_fmt yuv420p -c:a libopus -b:a 96k output.webm

# 720p-Version für Mobilgeräte
ffmpeg -i input.mov -vf scale=1280:720 -c:v libx264 -preset slow -crf 23 \
  -pix_fmt yuv420p -movflags +faststart output-mobile.mp4

Der Wert -crf steuert die Qualität: Niedrigere Werte bedeuten höhere Qualität und eine größere Datei. Fürs Web ist ein CRF von 23 bis 28 bei H.264 oder 30 bis 35 bei VP9 ein sinnvoller Bereich, um mit dem Messen anzufangen.

Prüfe den Export, statt dich darauf zu verlassen, denn ein fehlendes +faststart fällt nicht auf:

grep -abo -m2 -e moov -e mdat output.mp4

Das gibt den Byte-Offset des ersten moov und des ersten mdat aus. Der Offset von moov sollte der kleinere sein. Bei unserer Testdatei ohne das Flag kam mdat zuerst, bei Byte 44, und moov stand am Ende der Datei. Mit dem Flag lag moov bei Byte 36.

#Video mit Transparenz (Alphakanal) veröffentlichen

VP9 in WebM transportiert einen Alphakanal, wenn du nach yuva420p codierst. MDNs Codec-Leitfaden führt VP9 in allen aktuellen Versionen von Chrome, Edge, Firefox, Opera und Safari, mit dem Hinweis, dass Safari darin keine Alpha-Transparenz unterstützt. caniuse hat denselben Hinweis zu WebM in Safari. Apples Weg ist HEVC mit Alpha, dokumentiert im HEVC Video with Alpha Interoperability Profile. Braucht eine After-Effects-Komposition im Web einen echten Alphakanal, lieferst du zwei Dateien und einen Fallback in Volltonfarbe aus.

#Selbst gehostetes Video oder YouTube und Vimeo

Beim Selbsthosten lieferst du eine Datei in einer Bitrate per progressivem HTTP-Download aus. Es gibt keine adaptive Leiter. WordPress erzeugt beim Upload verkleinerte Varianten von Bildern, für Videos aber nichts Vergleichbares, weil der Core keinen Transcoder mitbringt. Ein Besucher mit schwacher mobiler Verbindung bekommt deine 1080p-Datei oder gar nichts, und das Video stockt, während es puffert.

Die Regel hängt also davon ab, was das Video ist, nicht davon, wie groß es ist.

#Wann du Videos auf dem eigenen Server hosten solltest

• Hintergrundvideo: kurze, stumme Animationen hinter einer Hero-Überschrift.
• Private Videos: Inhalte, die nicht auf einer öffentlichen Plattform liegen dürfen.
• Markenvorgaben: wenn der Player komplett dein eigener sein muss, ohne Logos von Drittanbietern.
• Ladegewicht: Bei sehr kurzen Clips zieht ein YouTube-Embed einen fremden Player samt Cookies nach sich, für etwas, das eher ein bewegtes Hintergrundbild ist.

#Wann du YouTube oder Vimeo nutzen solltest

• Jedes Video mit Ton, das länger als etwa 30 Sekunden ist und das sich ein Besucher ansehen will: ein Interview, ein Tutorial, die Vorstellung einer Fallstudie.
• Lern- oder Marketinginhalte, die von der YouTube-Suche profitieren.
• Videos, die geteilt werden sollen, in sozialen Netzwerken.
• Websites mit begrenzter Bandbreite, bei denen adaptives Streaming zählt.

Bandbreite ist die andere Hälfte dieser Entscheidung. Ein Loop mit 10 MB auf einer Seite mit fünfzigtausend Aufrufen im Monat sind ein halbes Terabyte ausgehender Traffic, und bei Einsteiger-Hosting heißt das: ein Gespräch mit deinem Anbieter.

#Wie Google selbst gehostete Videos indexiert

Googles Best Practices für Video-SEO bringen einen dritten Blickwinkel in die Formatfrage, und der deckt sich nicht mit dem der Browser.

Google kann MOV verarbeiten, Browser können es nicht abspielen. Googles Liste unterstützter Videodateitypen enthält MOV, MP4, M4V, WebM, OGV und weitere. Eine MOV ist damit im Prinzip indexierbar und für den Besucher trotzdem nutzlos. Ein Argument, eine auszuliefern, ist das also nicht.

Nur eine Wiedergabeseite bekommt alle Videofunktionen. Google definiert eine Wiedergabeseite als Seite, deren Hauptzweck es ist, ein einzelnes Video zu zeigen. Ein Blogbeitrag, der ein eingebettetes Video bespricht, oder eine Produktseite mit einem 360-Grad-Video ist ausdrücklich keine Wiedergabeseite. Solche Seiten können trotzdem als Textergebnisse und in Google Bilder mit einem Video-Badge erscheinen. Ein dekorativer Hero-Loop wird nie ein Videoergebnis sein, und das muss er auch nicht.

Das Poster dient zugleich als Thumbnail. Wenn du das Element <video> verwendest, liest Google das Attribut poster als bevorzugtes Thumbnail. Unterstützte Thumbnail-Formate sind BMP, GIF, JPEG, PNG, WebP, SVG und AVIF, mindestens 60x30 Pixel, unter einer stabilen URL, die der Googlebot abrufen darf.

Versteck das Video nicht hinter einer Interaktion. Google bittet darum, dass Videos zum Laden nicht von Wischen, Klicken oder Tippen abhängen und dass ein per JavaScript eingefügtes Video im gerenderten HTML erscheint, das das URL-Prüftool anzeigt. Das ist für das Lazy-Loading-Muster weiter unten wichtig: in Ordnung für einen dekorativen Loop, riskant für ein Video, das indexiert werden soll.

Strukturierte Daten. Die VideoObject-Dokumentation nennt drei Pflichtattribute: name, thumbnailUrl und uploadDate (ISO 8601, mit Zeitzone). contentUrl sollte auf die Videodatei selbst zeigen und wird bevorzugt. embedUrl zeigt auf einen Player und ist die Alternative, wenn die URL der Datei nicht verfügbar ist. Bei einer selbst gehosteten MP4 ist contentUrl einfach die URL der Datei in wp-content/uploads.

#Videos in WordPress responsiv machen

WordPress passt selbst gehostete Videos nicht von sich aus an Bildschirmgrößen an, diesen Teil schreibst du also selbst.

#CSS für responsive Videos

/* Responsiver Container für Videos */
.video-container {
    position: relative;
    width: 100%;
    padding-bottom: 56.25%; /* Seitenverhältnis 16:9 */
    height: 0;
    overflow: hidden;
}

.video-container video,
.video-container iframe {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
    object-fit: cover;
}

#Verschiedene Auflösungen je nach Gerät ausliefern

<video autoplay loop muted playsinline>
  <!-- Mobil: 720p -->
  <source
    src="video-720p.webm"
    type="video/webm"
    media="(max-width: 768px)"
  >
  <!-- Desktop: 1080p -->
  <source src="video-1080p.webm" type="video/webm">
  <source src="video-1080p.mp4" type="video/mp4">
</video>

Das Attribut media an einem Video-<source> ist eine alte Funktion mit einer Lücke in der Mitte: Laut den Kompatibilitätsdaten von MDN haben Firefox 53 bis 119 es nur innerhalb von <picture> beachtet, und die Unterstützung für <audio> und <video> kam mit Firefox 120 zurück.

#Videos in WordPress barrierefrei machen

Barrierefreie Videos sind für den europäischen öffentlichen Sektor nach der Richtlinie über den barrierefreien Zugang zu Websites Pflicht, und außerhalb davon machen sie Inhalte einfach für mehr Menschen verständlich. Die einschlägigen Erfolgskriterien der WCAG 2.2 sind kurz und konkret:

• 1.2.2 Untertitel (aufgezeichnet), Stufe A: Untertitel für alle aufgezeichneten Audioinhalte in synchronisierten Medien.
• 1.2.5 Audiodeskription (aufgezeichnet), Stufe AA: eine Audiodeskription für aufgezeichnete Videoinhalte.
• 1.4.2 Audio-Steuerelement, Stufe A: Jeder Ton, der automatisch länger als 3 Sekunden abgespielt wird, braucht eine Möglichkeit zum Pausieren oder Stoppen oder eine Lautstärkeregelung unabhängig von der Systemlautstärke.
• 2.2.2 Pausieren, Stoppen, Ausblenden, Stufe A: Bewegte Inhalte, die automatisch starten, länger als fünf Sekunden dauern und neben anderen Inhalten gezeigt werden, brauchen eine Möglichkeit, sie zu pausieren, zu stoppen oder auszublenden.

Das letzte Kriterium ist das, an dem Hero-Loops scheitern. Ein stummes Hintergrundvideo mit loop und ohne Steuerelemente läuft endlos, also braucht es einen sichtbaren Pause-Button oder muss nach ein paar Sekunden anhalten.

#Untertitel mit dem track-Element hinzufügen

Untertitel für ein selbst gehostetes Video sind eine WebVTT-Datei, auf die ein <track>-Element verweist. caniuse beziffert die Unterstützung von WebVTT auf 97,26 Prozent, genauso viel wie beim Element <video> selbst.

<video controls>
  <source src="video.mp4" type="video/mp4">
  <track kind="captions" src="captions.vtt" srclang="de" label="Deutsch" default>
  <track kind="descriptions" src="descriptions.vtt" srclang="de" label="Audiodeskription">
</video>

Eine minimale WebVTT-Datei sieht so aus:

WEBVTT

00:00:00.000 --> 00:00:04.000
Willkommen zu diesem Video.

00:00:04.000 --> 00:00:08.000
[Leise Musik im Hintergrund]

Der Core-Block Video speichert dasselbe in seinem Attribut tracks, sodass im Editor hinzugefügte Untertitel im gespeicherten Markup als <track>-Elemente landen.

#Minimale Checkliste für barrierefreie Videos

1. Untertitel: für gehörlose und schwerhörige Nutzer, als WebVTT-Datei in einem <track>-Element.
2. Audiodeskription: für blinde Nutzer, beschreibt, was nur zu sehen ist.
3. Tastatursteuerung: Der Player muss ohne Maus bedienbar sein.
4. Textalternative: Das Poster oder Thumbnail braucht eine aussagekräftige Beschreibung, wenn es Informationen trägt.
5. Kein Autoplay mit Ton: Ein Video mit Ton sollte nie von selbst starten.

#Das Laden eines selbst gehosteten Videos verzögern

Die Behandlung von loading="lazy" im WordPress-Core gilt für Bilder und iframes, nicht für das Element <video>, das dieses Attribut nicht unterstützt. Bei einem selbst gehosteten Video verzögert preload="none" zusammen mit einem poster den Download. Brauchst du mehr, lade die Quelle per JavaScript mit einem IntersectionObserver, sobald das Element in den Viewport kommt, und denk dabei an Googles Hinweis oben für jedes Video, das indexiert werden soll.

#MOV in MP4 für WordPress umwandeln

1. Schneide und mastere in After Effects oder Premiere mit .mov und ProRes. Dieser Teil war nie falsch.
2. Exportiere fürs Web als H.264 in MP4 und erzwinge dabei -pix_fmt yuv420p, -movflags +faststart sowie ein Profil und Level, die du dann in codecs deklarierst.
3. Prüfe den Export: moov auf einem niedrigeren Byte-Offset als mdat, und ffprobe meldet yuv420p und High,40, nicht yuv422p10le.
4. Füge eine WebM-Kopie mit VP9 hinzu und liste sie im Element <video> vor der MP4. Setze AV1 über beide, wenn du um die letzten paar hundert Kilobyte kämpfst.
5. Gib dem Element ein Posterbild und preload="none", behalte muted und playsinline bei jedem automatisch startenden Loop bei und ergänze eine Pause-Steuerung, wenn er länger als fünf Sekunden läuft.
6. Setze immer width und height, um Layout-Verschiebungen zu vermeiden.
7. Hat der Clip Ton und soll ihn sich jemand in Ruhe ansehen, lade ihn stattdessen auf YouTube oder Vimeo hoch und bette ihn ein.

Wenn das Teil eines Projekts ist, das wir betreuen, richten wir den Encoding-Schritt einmal in der Deploy-Pipeline ein, damit sich niemand die Flags merken muss. Das gehört zu unserer WordPress-Entwicklung.