WCAG 2.2 Audio-Konformität für WordPress: Leitfaden 2026

WordPress-Audio muss mindestens vier WCAG 2.2-Erfolgskriterien erfüllen: 1.4.2 Audio-Steuerung, 2.1.1 Tastatur, 2.5.8 Zielgröße (neu in 2.2) und 4.1.2 Name, Rolle, Wert. Der Europäische Rechtsakt zur Barrierefreiheit, der seit dem 28. Juni 2025 gilt, macht dies für jede Website mit EU-Kunden zur rechtlichen Pflicht. Der Standard-WordPress-Audioplayer und die meisten Drittanbieter-Plugins scheitern ohne Anpassungen an mehreren dieser Anforderungen.

Dieser Leitfaden ist die praktische Checkliste, die wir bei Mementor für WCAG 2.2-Audits auf WordPress-Websites verwenden. Wir beleuchten beide Seiten des Themas: Audio als Inhalt mit eigenen Barrierefreiheitsregeln und Audio als Zugangshilfe für Textinhalte.

Warum Audio-Konformität 2026 zählt

2025 haben drei Entwicklungen das Thema dringlich gemacht. Der EAA trat am 28. Juni 2025 in Kraft. Der WebAIM Million 2025-Bericht stellte auf 96,3 % der Startseiten messbare WCAG-Verstöße fest. In den USA stiegen ADA-Klagen weiter an, wobei WordPress-Websites in über 4.000 Barrierefreiheitsfällen im Jahr vertreten waren.

Bei unseren Audits sehen wir immer dasselbe Muster. Website-Betreiber gehen davon aus, dass das Theme für Barrierefreiheit sorgt. Das Theme übernimmt, was das Audio-Plugin mitliefert. Das Audio-Plugin liefert Schaltflächen, die zu klein sind, Schieberegler, die Tastaturnutzer blockieren, und Kontrastverhältnisse, die bei der ersten manuellen Prüfung durchfallen.

Die vollständige WCAG 2.2-Audio-Checkliste

Acht Erfolgskriterien betreffen Audio auf einer WordPress-Website direkt. Die folgende Tabelle zeigt, was jedes Kriterium in der Praxis bedeutet, was der Standard-WordPress-Audioplayer richtig oder falsch macht und wie der TTSWP-Player damit umgeht. Mit NEU markierte Kriterien wurden im Oktober 2023 mit WCAG 2.2 eingeführt.

Die W3C-Seite Media Accessibility User Requirements ist die maßgebliche Quelle für diese Kriterien. Wir konzentrieren uns auf die acht genannten, weil sie direkt für Audioplayer gelten. Untertitel (1.2.2) und Audiodeskription (1.2.3) sind ebenfalls relevant, betreffen aber Video, nicht reine Audio-Wiedergabe.

Die Medienalternative für Text

Hier ist die Regel, die 95 Prozent aller Compliance-Artikel übersehen. WCAG definiert eine Medienalternative für Text als Medium, das keine weitergehenden Informationen enthält als der zugehörige Text. Liest eine Text-zu-Sprache-Vertonung einen bestehenden Artikel vor, ist das Audio eine Medienalternative zum Seitentext. Der Seitentext selbst ist das Transkript.

Eine TTS-Audioversion eines Artikels benötigt daher keine separate Transkriptdatei. WebAIM erklärt das klar. Die Bedingung: Das Audio muss eindeutig als Medienalternative gekennzeichnet sein, damit Nutzer wissen, dass sie keine Informationen verpassen, wenn sie es überspringen. Eine Überschrift wie „Artikel anhören” oder ein Player mit der Beschriftung „Audioversion dieses Beitrags” genügt dafür.

Die Ausnahme gilt nicht, wenn das Audio Kommentare, bedeutungstragende Musik oder Abschnitte enthält, die nicht im Text stehen. Reine Vertonungen des Seiteninhalts qualifizieren sich. Wir nutzen diese Regelung regelmäßig, wenn Publisher-Kunden befürchten, dass Audio neue Transkriptpflichten schafft.

Was WCAG 2.2 für Audio neu bringt

Drei neue Level-AA-Kriterien betreffen Audioplayer direkt.

2.5.8 Zielgröße (Minimum)

Jedes interaktive Steuerelement braucht eine Zielfläche von mindestens 24 x 24 CSS-Pixel. Dieses Kriterium lässt die meisten WordPress-Audio-Plugins scheitern. Bei unseren Audits verfehlen die Vor- und Zurückspringen-Schaltflächen von Drittanbieter-Plugins regelmäßig diesen Mindestwert. Visuelle Designer haben vor WCAG 2.2 auf Kompaktheit gesetzt, und viele Plugin-Entwickler haben noch nicht nachgezogen. Theme-eigene Stile verkleinern die Ziele manchmal noch weiter.

Die Lösung liegt meist im Innenabstand, nicht in der Icon-Größe. Ein 16-Pixel-SVG-Icon in einer Schaltfläche mit 4 Pixeln Padding auf jeder Seite erreicht die 24-Pixel-Grenze, ohne das Erscheinungsbild zu verändern.

2.4.11 Fokus nicht verdeckt

Fixierte Audioleisten am Seitenende überdecken das, worauf der Tastaturnutzer gerade fokussiert ist. Liegt ein fokussierter Link hinter der Leiste, schlägt das Kriterium fehl. Die Lösung: Die Leiste schließbar machen, Platz über dem Fokusziel lassen oder scroll-padding-bottom am Dokument setzen, damit fokussierte Elemente sichtbar bleiben.

2.5.7 Ziehbewegungen

Benutzerdefinierte Fortschrittsbalken und Lautstärkeregler, die ausschließlich per Ziehen bedient werden, erfüllen dieses Kriterium nicht. Jede Zieh-Interaktion braucht eine Ein-Zeiger-Alternative. Klick-zur-Position auf einem Fortschrittsbalken erfüllt sie. Ebenso die Pfeiltasten-Steuerung auf einem korrekt implementierten role="slider".

Häufige WordPress-Audio-Fehler aus echten Audits

Die Muster wiederholen sich auf Kundenseiten. Vier Fehler sehen wir am häufigsten.

Der Standard-WordPress-Core-Block <audio> rendert den nativen Browser-Player. Browser-native Audio-Steuerelemente haben eine lange Geschichte inkonsistenten Verhaltens mit Screenreadern, und die Pfeiltasten-Steuerung der Abspielposition variiert zwischen Chrome, Firefox und Safari. Nutzer mit NVDA oder JAWS hören zwar die Zeitangaben, können die Position aber oft nicht zuverlässig per Tastatur ansteuern. Die Lösung: Audio in einem benutzerdefinierten Player kapseln, der role="slider" mit korrekten ARIA-Value-Attributen bereitstellt.

Plugin-Player liefern Schaltflächen unter der 24-Pixel-Grenze. Der visuelle Designer hat auf Kompaktheit gesetzt, bevor WCAG 2.2 die Regel einführte. Themes überschreiben dann die Plugin-Stile, was die Situation manchmal verbessert, manchmal verschlechtert.

Fixierte Audioleisten verdecken fokussierte Inhalte. Wir haben diesen Fehler auf jeder Website gesehen, die einen fixierten Footer-Player ohne Test der Tastaturnavigation einsetzt.

Der Kontrast auf Wellenformdarstellungen liegt regelmäßig unter 4,5:1. Designer mögen das sanfte Grau auf Weiß. Screenreader kümmert das nicht, sehschwache Nutzer schon, und 1.4.3 schlägt fehl.

Barrierefreien Audioplayer bauen: die technische Checkliste

1. Den Player in role="region" mit einem beschreibenden aria-label einbetten.
2. Echte <button>-Elemente für Abspielen, Pause, Springen und Stummschalten verwenden. Niemals <div> mit Click-Handler.
3. aria-pressed am Play-Button setzen, um den Umschaltzustand anzuzeigen.
4. Jedem Steuerelement per Padding eine Mindestzielfläche von 24 x 24 CSS-Pixel geben.
5. Fortschritts- und Lautstärkeregler als role="slider" mit aria-valuemin, aria-valuemax und aria-valuenow implementieren und auf Pfeiltasten reagieren lassen.
6. Klick-zur-Position am Fortschrittsbalken als Alternative zum Ziehen bereitstellen.
7. Kontrast an allen Textelementen und aussagekräftigen Icons mit mindestens 4,5:1 prüfen.
8. Fokusrahmen sichtbar halten und sicherstellen, dass sie nicht durch Overflow-Regeln abgeschnitten werden.
9. Bei fixiertem Player: Platz über dem Player lassen oder ihn schließbar machen.
10. TTS-Vertonungsplayer als „Audioversion dieses Artikels” kennzeichnen, damit die Medienalternative-Ausnahme greift.

Eine minimale barrierefreie Play-Schaltfläche sieht so aus.

<div role="region" aria-label="Article audio player">
  <button type="button"
          aria-pressed="false"
          aria-label="Play article narration"
          style="min-width:24px;min-height:24px;padding:8px">
    <svg aria-hidden="true" width="16" height="16">...</svg>
  </button>
  <input type="range"
         aria-label="Playback position"
         min="0" max="100" value="0">
</div>

Das ist die Grundstruktur. Gestalten Sie die Schaltfläche nach Wunsch, blenden Sie die nativen Range-Elemente aus, wenn Sie eine eigene Spur möchten, aber behalten Sie die zugrunde liegende Semantik bei.

Wie TTS-Vertonung die WCAG-Konformität insgesamt stärkt

Audio ist nicht nur Inhalt, der barrierefrei gestaltet werden muss. Es ist selbst eine Zugangshilfe. Die Weltgesundheitsorganisation schätzt, dass 1,3 Milliarden Menschen, rund 16 % der Weltbevölkerung, mit einer erheblichen Behinderung leben. Viele profitieren von mehreren Zugangswegen zu Textinhalten: Menschen mit Legasthenie, ADHS, Sehschwäche und verschiedenen kognitiven Einschränkungen lesen komfortabler, wenn Audio und Text zusammen angeboten werden.

Text-zu-Sprache-Vertonung hinzuzufügen ist eine der wenigen Barrierefreiheits-Maßnahmen, die Nutzern hilft, bevor sie ein Audit erfüllt. TTS zu WordPress hinzuzufügen dauert mit dem Text-zu-Sprache – TTSWP-Plugin unter 15 Minuten. Der Player kommt mit WCAG 2.1 AA-konformen Standardeinstellungen, Zielflächen von mindestens 24 Pixeln, Tastaturunterstützung und korrekten ARIA-Rollen.

Die minimale Laufzeit-Nutzlast beträgt rund 35 bis 40 KB gzipped (151 KB unkomprimiert) und umfasst die JavaScript-Player-Logik und das gemeinsame CSS. Wir haben GTmetrix auf einem veröffentlichten Artikel mit aktivem Player ausgeführt und Note A erzielt: 93 % Performance, 99 % Structure, Largest Contentful Paint bei 1,3 Sekunden, Total Blocking Time bei 46 Millisekunden und Cumulative Layout Shift bei null. Das Bundle lädt lazy nur auf Seiten, die den Player enthalten, sodass statische Seiten ohne Audio kein zusätzliches Gewicht tragen.

Die Barrierefreiheitsdokumentation finden Sie auf unserer Accessibility-Seite. Die Vertonung nutzt die generative Engine von ElevenLabs, die Prosodie so weit verbessert, dass Zuhörer Artikel tatsächlich zu Ende hören, statt eine roboterhafte Stimme abzubrechen.

Der Europäische Rechtsakt zur Barrierefreiheit in der Praxis

Der EAA ist seit dem 28. Juni 2025 vollziehbar. Neue digitale Dienste, die nach diesem Datum auf dem EU-Markt angeboten werden, müssen jetzt konform sein. Bestehende Dienste haben bis zum 28. Juni 2030 Zeit, alles anzupassen. Die Richtlinie gilt für jedes Unternehmen, das EU-Kunden bedient, unabhängig vom Unternehmenssitz.

Der technische Standard, auf den der EAA verweist, ist EN 301 549. Die aktuelle harmonisierte Fassung (V3.2.1, August 2021) basiert auf WCAG 2.1 Level AA. Entwurf V4.1.0 vom November 2025 aktualisiert die Abschnitte 9, 10 und 11 auf WCAG 2.2, mit erwarteter endgültiger Harmonisierung im Laufe des Jahres 2026. Bis diese Aktualisierung im Amtsblatt der EU veröffentlicht wird, bleibt WCAG 2.1 AA das rechtlich verbindliche Minimum. Wir empfehlen aber, jetzt auf 2.2 zu zielen, da die Umstellung Monate entfernt ist, nicht Jahre.

Die Strafen variieren je nach Mitgliedstaat. Deutschland und Frankreich verfügen über die aktivste Durchsetzungsinfrastruktur, mit nationalen Barrierefreiheitsbehörden, die befugt sind, Beschwerden zu untersuchen und Bußgelder zu verhängen. Wir haben erlebt, dass deutsche Kunden formelle Beschwerden von Endnutzern innerhalb weniger Monate nach dem Inkrafttreten erhalten haben, meistens zu Audio- und Formularkomponenten. Die Beschwerden kommen vor den Bußgeldern, sodass ein Korrekturfenster von 30 Tagen meist erreichbar ist, wenn das Team vorbereitet ist.

Konformität testen

Automatisierte Tools erkennen rund 30 bis 40 Prozent der Probleme. Für den Rest ist manuelle Prüfung erforderlich, insbesondere bei Tastaturinteraktionen und bedeutungsvollem Kontrast in dynamischen Zuständen.

• NVDA unter Windows mit Chrome und Firefox. Kostenlos.
• JAWS unter Windows für Enterprise-Kundenanforderungen.
• VoiceOver auf macOS und iOS. Bereits integriert.
• TalkBack auf Android. Bereits integriert.
• axe DevTools-Browsererweiterung für automatisierte Scans.
• Lighthouse in den Chrome DevTools für schnelle Überprüfungen.
• Tastatur-only-Walkthrough. Maus abstecken und jedes Player-Steuerelement bedienen.

Der Tastatur-only-Walkthrough ist der Test mit dem größten Erkenntnisgewinn. Wenn der Player ohne Maus funktioniert, sind die meisten WCAG 2.2-Anforderungen bereits erfüllt.

Häufige Fragen

Schreibt WCAG 2.2 Untertitel für Audio-Podcasts vor?

Nein. Untertitel (1.2.2) gelten für voraufgezeichnetes Video mit synchronem Audio. Für reine Audio-Inhalte wie Podcasts ist Kriterium 1.2.1 maßgeblich, das eine Textalternative wie ein Transkript oder eine ausführliche Zusammenfassung verlangt. Untertitel und Transkripte dienen unterschiedlichen Zwecken. Ein Podcast braucht das Transkript. Ein Video-Tutorial braucht sowohl Untertitel als auch Audiodeskription für rein visuelle Informationen.

Ist automatisch abspielendes Audio nach dem EAA verboten?

Nicht verboten, aber eingeschränkt. WCAG 1.4.2 Audio-Steuerung, auf die der EAA über EN 301 549 verweist, verlangt, dass jedes Audio, das länger als drei Sekunden automatisch abspielt, eine Pause-, Stopp- oder unabhängige Lautstärkeregelung bieten muss. Auto-Play ohne diese Steuerung verfehlt Level A und wird als Verstoß gewertet. Die meisten Durchsetzungsbehörden behandeln das als klare Verletzung, nicht als Grenzfall.

Brauche ich ein Transkript, wenn ich eine Audioversion meines Artikels habe?

Meist nicht. Wenn das Audio eine direkte Vertonung des Artikeltexts ist und keine neuen Informationen enthält, gilt der Artikeltext selbst als Transkript im Sinne der WCAG-Definition „Medienalternative für Text”. Kennzeichnen Sie den Player klar als Audioversion des Artikels, dann greift die Ausnahme. Wenn das Audio Kommentare, bedeutungstragende Musik oder Abschnitte enthält, die nicht im Text stehen, ist ein separates Transkript notwendig.

Wie groß müssen Schaltflächen in Audioplayern nach WCAG 2.2 mindestens sein?

Interaktive Ziele müssen nach Erfolgskriterium 2.5.8 Zielgröße (Minimum) auf Level AA mindestens 24 x 24 CSS-Pixel groß sein. Die Zielfläche schließt Padding ein, sodass ein 16-Pixel-Icon mit 4 Pixeln Padding auf jeder Seite die Anforderung erfüllt. Ausnahmen gibt es für Inline-Links in Text und vom Browser bestimmte Steuerelemente, aber eigenständige Player-Schaltflächen haben keine Ausnahme und müssen den Mindestwert erreichen.

Gilt WCAG 2.2 auch für WordPress.com-gehostete Websites?

Ja. WCAG gilt für alle Web-Inhalte, unabhängig von der Hosting-Plattform. WordPress.com-Websites tragen dieselbe rechtliche Verantwortung nach EAA, ADA und nationalen Gleichwertigkeitsgesetzen wie selbst gehostetes WordPress. Das Hosting-Modell ändert die Pflicht nicht. Was sich ändert, ist der Einfluss des Website-Betreibers auf den Player-Code. WordPress.com Business- und Commerce-Pläne erlauben eigene Plugins, niedrigere Tarife nicht.

Wo anfangen

Wählen Sie einen Beitrag auf Ihrer Website, führen Sie einen Tastatur-only-Walkthrough des Audioplayers durch und prüfen Sie jede Schaltfläche gegen die 24-Pixel-Regel. Dieses eine Audit zeigt, ob Ihr aktuelles Setup nah an der WCAG 2.2-Konformität ist oder weit davon entfernt. Danach wählen Sie: bestehenden Player korrigieren oder ihn durch einen ersetzen, der von Haus aus konform ausgeliefert wird. Unsere Barrierefreiheitsdokumentation beschreibt die Konfiguration, die wir für Websites unter EAA-Druck empfehlen.