Barrierefreier Media-Player

Der zugänglichste Media-Player ist fast immer der native: <video controls> liefert tastaturbedienbare, korrekt benannte Bedienelemente, eine Untertitel-Umschaltung und Screenreader-Unterstützung, ohne dass du eine Zeile JavaScript schreibst. Baust du eigene Controls, musst du all das nachbauen – echte <button>-Elemente mit eindeutigen Namen, eine Zeitleiste als vollwertigen Slider mit Pfeiltasten-Steuerung und eine sichtbare Fokusmarkierung.

Ein Media-Player ist kein Element, sondern ein Bündel aus einem halben Dutzend Bedienelementen: Wiedergabe, Pause, Lautstärke, Zeitleiste, Untertitel, Vollbild. Jedes davon kann eine Barriere werden, sobald man es selbst nachbaut – und die meisten selbstgebauten Player scheitern nicht am Aussehen, sondern an genau zwei Stellen: der Zeitleiste, die ein <div> mit Klick-Handler geblieben ist, und den Icon-Buttons ohne zugänglichen Namen. Diese Seite geht beides durch, ordnet die WCAG-Kriterien zu, die ein Player erfüllen muss, und zeigt, wann sich der Eigenbau überhaupt lohnt.

Das Wichtigste in Kürze

• controls zuerst. Die nativen Bedienelemente sind zugänglich, gratis und wartungsfrei.
• Jeder Knopf ist ein echter <button> mit eindeutigem, zugänglichem Namen – Icons allein reichen nicht.
• Play/Pause wechselt den Namen, nicht aria-pressed.
• Die Zeitleiste ist ein Slider: <input type="range"> oder role="slider" mit aria-valuenow, aria-valuemin, aria-valuemax und aria-valuetext.
• Kein Autoplay mit Ton: Läuft Ton länger als drei Sekunden automatisch, verlangt WCAG 1.4.2 eine Stopp-Möglichkeit oder eine eigene Lautstärkeregelung.
• Untertitel-Umschaltung nicht vergessen, wenn du die nativen Controls ersetzt – sie verschwindet sonst ersatzlos.

Welche Kriterien ein Player erfüllen muss

Ein Player ist der Ort, an dem ungewöhnlich viele Erfolgskriterien gleichzeitig zusammenkommen. Diese Liste ist die Prüfliste, mit der ich an fremde Player herangehe:

Die interessante Erkenntnis daraus: Sechs der acht Kriterien erledigen die nativen Controls für dich. Bei einem Eigenbau fängst du bei null an.

Native Controls zuerst

<video controls> und <audio controls> liefern einen vollständig zugänglichen Player – tastaturbedienbar, beschriftet, mit Untertitel-Umschaltung. Kombiniert mit der <track>-Spur ist das Fundament fertig:

<video controls preload="metadata" width="800" height="450" poster="/img/vorschau.webp">
  <source src="/video/einfuehrung.mp4" type="video/mp4" />
  <track kind="captions" src="/video/einfuehrung.de.vtt" srclang="de" label="Deutsch" default />
</video>

Wo die nativen Controls an Grenzen stoßen

Ehrlich bleiben gehört dazu – zwei Einschränkungen sind real:

• Die Tastaturbedienung ist nicht überall gleich. In Firefox lässt sich ein fokussiertes Video direkt mit Leertaste, Pfeiltasten und Lautstärketasten steuern. In Chrome musst du dich erst per Tab in die Bedienleiste bewegen und dort von Knopf zu Knopf wandern. Beides erfüllt 2.1.1, aber es fühlt sich unterschiedlich an – und wer eine Anleitung schreibt, sollte nicht „Leertaste drückt Play“ behaupten.
• Gestalten lässt sich kaum etwas. Die Bedienleiste liegt im Shadow DOM; über proprietäre Pseudoelemente kommt man an Teile heran, aber nicht browserübergreifend zuverlässig. Wenn das Corporate Design den Player einfärben will, ist das der Punkt, an dem die Diskussion beginnt.

Bevor du deshalb controls entfernst, rechne ehrlich: Du tauschst ein paar Pixel Gestaltungsfreiheit gegen sechs Erfolgskriterien, die du fortan selbst verantwortest – und dauerhaft pflegen musst.

Eigene Controls richtig bauen

Wenn das Design eigene Bedienelemente verlangt, ist das machbar. Es braucht nur Disziplin an jeder einzelnen Stelle.

Jeder Knopf ist ein echter Button

Ein <div onclick> ist kein Knopf: nicht fokussierbar, keine Rolle, keine Tastaturauslösung. Nimm <button type="button"> – siehe Buttons vs. Links. Reine Icon-Knöpfe brauchen einen zugänglichen Namen, der Text muss also irgendwo herkommen:

<button type="button" class="player-play">
  <svg aria-hidden="true" focusable="false" width="24" height="24"><!-- Play-Icon --></svg>
  <span class="visually-hidden">Wiedergabe</span>
</button>

Die visually-hidden-Variante ist der aria-label-Variante vorzuziehen: Sie wird von Übersetzungswerkzeugen mit übersetzt und funktioniert auch, wenn ARIA scheitert. Mehr dazu bei Icons & SVGs.

Play/Pause: den Namen wechseln, nicht aria-pressed

Ein häufiger Fehlgriff. aria-pressed beschreibt einen Umschalter, der gedrückt bleibt – etwa „Fett“ in einem Editor. Wiedergabe und Pause sind aber zwei verschiedene Aktionen mit zwei verschiedenen Bedeutungen:

<!-- richtig: der Name beschreibt, was der Klick TUN wird -->
<button type="button" id="playpause">
  <span class="visually-hidden">Wiedergabe</span>
</button>

Beim Start tauschst du Icon und Text gegen „Pause“. So hört ein Screenreader immer die nächste Aktion, nicht einen abstrakten Zustand. Das Gegenstück – ein echter Umschalter – ist die Untertitel-Taste, und dort ist aria-pressed genau richtig. Die Abgrenzung vertieft Toggles & Custom Controls.

Die Zeitleiste ist ein Slider

Das ist die Stelle, an der die meisten Player durchfallen. Ein klickbarer Balken mag mit der Maus funktionieren, ist aber für Tastatur und Screenreader nicht vorhanden.

Der einfachste korrekte Weg ist das native Element:

<label for="seek" class="visually-hidden">Suchlauf</label>
<input type="range" id="seek" min="0" max="252" value="134" step="1" />

<input type="range"> bringt Rolle, Werte, Fokussierbarkeit und die komplette Tastaturbedienung mit. Wenn das Design einen Eigenbau erzwingt, musst du beides nachbauen – Auszeichnung und Tastatur:

<div
  role="slider"
  tabindex="0"
  aria-label="Suchlauf"
  aria-valuemin="0"
  aria-valuemax="252"
  aria-valuenow="134"
  aria-valuetext="2 Minuten 14 von 4 Minuten 12"
>
  <span class="thumb"></span>
</div>

aria-valuetext ist hier der entscheidende Unterschied zwischen brauchbar und unbrauchbar. Ohne das Attribut hört man „134“ – mit ihm „2 Minuten 14 von 4 Minuten 12“. Der gleiche Gedanke gilt für die Lautstärke: „60 Prozent“ statt „0,6“.

Untertitel-Umschaltung

Entfernst du controls, verschwindet auch die eingebaute Untertitel-Auswahl. Sie gehört ersetzt – sonst verstößt der Player gegen 1.2.2, obwohl die <track>-Spur vorhanden ist:

<button type="button" aria-pressed="false" id="cc">
  <span class="visually-hidden">Untertitel</span>
</button>

Bei mehreren Sprachspuren wird daraus ein Menü statt eines Umschalters. Umgeschaltet wird über die mode-Eigenschaft der Textspur (showing bzw. hidden).

Fokus und Kontrast

Zwei Dinge, die beim Eigenbau gern untergehen, weil der Player meist dunkel ist:

• Sichtbare Fokusmarkierung auf dunklem Grund. Der übliche dunkelblaue Standard- Fokusring verschwindet auf einer schwarzen Bedienleiste. Setze eine eigene, helle Outline – genau das macht diese Website auch bei den Kopieren-Knöpfen der Codeblöcke.
• Icons brauchen 3:1 Kontrast zum Hintergrund (1.4.11). Ein grauer Play-Pfeil auf dunkelgrauer Leiste sieht edel aus und fällt durch. Prüfen lässt sich das mit dem Kontrast-Check.

Autoplay, Ton und die Drei-Sekunden-Regel

1.4.2 Audio-Steuerelement ist eines der wenigen Kriterien mit einer harten Zahl: Spielt auf einer Seite Ton länger als drei Sekunden automatisch, muss es entweder eine Möglichkeit geben, ihn anzuhalten oder zu stoppen, oder eine von der Systemlautstärke unabhängige Lautstärkeregelung.

Der Grund dahinter ist ein sehr konkreter: Ein Screenreader gibt seine Sprachausgabe über dieselbe Systemlautstärke aus wie dein Video. Wer den Ton leiser dreht, macht damit auch die eigene Vorlesestimme leiser – und wer das Video stoppen will, muss den Stopp-Knopf erst finden, während ihn die eigene Software überbrüllt. Deshalb reicht „man kann es ja wegdrehen“ ausdrücklich nicht.

Praktisch heißt das:

• Ton nie automatisch starten. Alle aktuellen Browser blockieren das ohnehin, aber verlass dich nicht darauf.
• Stummes Autoplay (autoplay muted playsinline) ist technisch erlaubt – braucht wegen 2.2.2 aber trotzdem einen Pause-Knopf, sobald es länger als fünf Sekunden läuft.
• prefers-reduced-motion respektieren: Wer reduzierte Bewegung eingestellt hat, sollte kein automatisch spielendes Hintergrundvideo vorgesetzt bekommen.

Das Transkript gehört unter den Player

Der wirksamste Zusatz kostet am wenigsten Technik: ein aufklappbares Transkript direkt unter dem Player. Es hilft gehörlosen Nutzern, Menschen, die lieber lesen als schauen, allen ohne Kopfhörer – und macht den Inhalt für Suchmaschinen überhaupt erst lesbar.

Ausgereifte Player gehen noch einen Schritt weiter und bauen ein interaktives Transkript: Der laufende Abschnitt wird hervorgehoben, und ein Klick oder Enter auf einer Stelle springt im Video dorthin. Able Player etwa erzeugt das automatisch aus den vorhandenen WebVTT-Dateien für Untertitel, Kapitel und Beschreibungen. Wer selbst baut, bekommt mit einem simplen <details>-Block schon 80 % des Nutzens.

Fertiger Player oder Eigenbau?

Die ehrliche Abwägung in drei Stufen:

• Native controls – erste Wahl für die allermeisten Fälle. Kostet nichts, funktioniert überall, keine Wartung. Das entspricht auch der ersten Regel von ARIA.
• Etablierte Player-Bibliothek – sinnvoll bei einheitlichem Aussehen über Browser hinweg, mehreren Untertitelspuren, Kapitelnavigation oder Gebärdensprach-Fenster. Able Player ist hier die Referenz, weil Barrierefreiheit dort der Ausgangspunkt war und nicht die Nachrüstung: hochkontrastige Bedienelemente, die auch im Windows-Kontrastmodus sichtbar bleiben, ein deutlicher Fokusindikator und das erwähnte interaktive Transkript.
• Komplett eigener Player – nur mit Budget für Tastaturbedienung, Fokusreihenfolge, Namen, Slider-Semantik und wiederkehrende Tests. Das ist deutlich mehr Arbeit, als es aussieht.

Randnotiz – das schwerste Element gleich mitdenken. Ein Player mit großem Video ist auch ein Performance-Thema: preload="metadata" statt des ganzen Videos, feste Maße gegen Layout-Sprünge und kein automatisches Abspielen schonen LCP und Datenvolumen. Barrierefreiheit und Performance ziehen wieder am selben Strang.

So testest du deinen Player

Vier Durchgänge, die zusammen fast alles finden:

1. Nur Tastatur. Maus weglegen. Erreichst du jeden Knopf per Tab? Siehst du immer, wo du bist? Kannst du mit den Pfeiltasten spulen und die Lautstärke ändern?
2. Screenreader an. Wandere durch die Bedienleiste und höre zu: Sagt jeder Knopf einen verständlichen Namen? Ändert sich der Name beim Umschalten? Sagt der Suchlauf eine Zeit oder eine nackte Zahl? Wie das geht, steht bei Mit NVDA testen.
3. Auf 200 % zoomen. Bleibt die Bedienleiste vollständig und bedienbar?
4. Untertitel prüfen. Lassen sie sich ein- und ausschalten? Bleibt die Einstellung beim nächsten Video erhalten?

Häufige Fehler

• controls entfernt und durch unvollständigen Eigenbau ersetzt.
• Icon-Buttons ohne Namen – der Screenreader sagt nur „Schaltfläche“.
• Zeitleiste als klickbares <div> ohne Rolle, Werte und Tastatur.
• aria-valuetext vergessen – die Ansage bleibt eine bedeutungslose Zahl.
• aria-pressed am Play-Knopf statt eines wechselnden Namens.
• Untertitel-Umschaltung verloren, weil die native Leiste ersetzt wurde.
• Fokusring unsichtbar auf dunkler Bedienleiste.
• Autoplay mit Ton ohne sofortige Stoppmöglichkeit.
• Icons unter 3:1 Kontrast zur Bedienleiste.

Häufige Fragen

Reichen die nativen Controls wirklich?

Für die allermeisten Fälle ja. Sie sind zugänglich, sparen viel Arbeit und altern nicht. Eigene Controls lohnen nur, wenn das Design sie zwingend verlangt oder du Funktionen brauchst, die der Browser nicht bietet – dann aber vollständig.

Warum kein aria-pressed am Play-Knopf?

Weil Wiedergabe und Pause zwei Aktionen sind, kein Ein/Aus-Zustand. Ein wechselnder Name („Wiedergabe“ → „Pause“) sagt dem Nutzer, was als Nächstes passiert. Bei der Untertitel-Taste ist aria-pressed dagegen richtig.

Kann ich die nativen Controls umgestalten?

Nur eingeschränkt. Die Bedienleiste liegt im Shadow DOM; browserspezifische Pseudoelemente erlauben Teil-Anpassungen, aber nichts Verlässliches über alle Browser. Wer wirklich gestalten will, kommt um eigene Controls oder eine Bibliothek nicht herum.

Ist ein eingebettetes YouTube-Video automatisch barrierefrei?

Nein. Der Player selbst ist ordentlich, aber die Inhalte sind deine Verantwortung: korrigierte Untertitel hochladen, kein Autoplay mit Ton, Transkript auf der eigenen Seite bereitstellen. Gib dem <iframe> außerdem ein aussagekräftiges title.

Was ist mit reinen Audio-Playern?

Dieselben Regeln, nur ohne Bild – und mit einer zusätzlichen Pflicht: Für reines Audio verlangt WCAG ein Transkript. Ein Podcast-Player ohne Transkript ist unabhängig von der Bedienung nicht zugänglich.

Fazit

Der zugänglichste Player ist meist der native: <video controls> beziehungsweise <audio controls> plus <track>-Untertitel. Damit sind sechs der acht relevanten Erfolgskriterien schon erfüllt.

Baust du eigene Controls, sind es echte, benannte Buttons, ein Play-Knopf mit wechselndem Namen, eine Zeitleiste als vollwertiger Slider mit aria-valuetext, eine Untertitel-Umschaltung und eine Fokusmarkierung, die auf dunklem Grund sichtbar bleibt. Kein Autoplay mit Ton, prefers-reduced-motion beachten – und ein Transkript direkt unter den Player, weil das der Zusatz mit dem besten Verhältnis von Aufwand zu Nutzen ist.

Quellen

• Understanding SC 1.4.2: Audio Control (W3C – die Drei-Sekunden-Regel und warum sie besonders Screenreader-Nutzer betrifft)
• Slider Pattern (W3C ARIA Authoring Practices – Tastaturbedienung und erforderliche Werte für die Zeitleiste)
• Able Player (barrierefreier HTML5-Media-Player – interaktives Transkript, Gebärdensprach-Fenster, Kontrastmodus)