WCAG 2.2 dla audio w WordPress: przewodnik na 2026 rok

Audio w WordPress musi spełniać co najmniej cztery kryteria sukcesu WCAG 2.2, w tym 1.4.2 Kontrola dźwięku, 2.1.1 Klawiatura, 2.5.8 Rozmiar obszaru docelowego (nowość w wersji 2.2) oraz 4.1.2 Nazwa, rola, wartość. Europejski Akt o Dostępności, obowiązujący od 28 czerwca 2025 r., czyni to wymogiem prawnym dla każdej witryny obsługującej klientów z UE. Domyślny odtwarzacz audio WordPress oraz większość wtyczek audio od podmiotów zewnętrznych nie spełnia tych wymagań bez modyfikacji.

Ten przewodnik to praktyczna lista kontrolna, której używamy w Mementor podczas audytów witryn WordPress pod kątem zgodności z WCAG 2.2. Omawiamy oba aspekty dostępności audio: audio jako treść rządząca się własnymi zasadami dostępności oraz audio jako funkcję ułatwień dostępu dla treści tekstowych.

Dlaczego zgodność audio jest ważna w 2026 roku

W 2025 roku zbiegły się trzy czynniki, które uczyniły z tego tematu pilną kwestię. EAA zaczął być egzekwowany 28 czerwca 2025 r. Raport WebAIM Million 2025 wykazał, że 96,3% stron głównych miało wykrywalne błędy WCAG. Liczba spraw sądowych na podstawie ADA w Stanach Zjednoczonych stale rosła, a witryny WordPress figurowały wśród ponad 4000 przypadków naruszenia dostępności cyfrowej zgłoszonych w ciągu roku.

Schemat powtarzający się w naszych audytach jest niezmienny. Właściciele witryn zakładają, że motyw obsługuje dostępność. Motyw przejmuje ustawienia wtyczki audio. Wtyczka audio dostarcza przyciski zbyt małe, suwaki blokujące użytkowników klawiatury i współczynniki kontrastu, które nie przechodzą pierwszego ręcznego sprawdzenia.

Kompletna lista kontrolna WCAG 2.2 dla audio

Osiem kryteriów sukcesu dotyczy bezpośrednio audio w witrynie WordPress. Poniższa tabela pokazuje, co każde z nich oznacza w praktyce, co domyślny odtwarzacz audio WordPress robi dobrze lub źle oraz jak radzi sobie z nimi odtwarzacz TTSWP. Kryteria oznaczone jako NOWOŚĆ pojawiły się wraz z WCAG 2.2 w październiku 2023 r.

Strona W3C Media Accessibility User Requirements to kanoniczne źródło tych kryteriów. Skupiamy się na powyższych ośmiu, bo dotyczą bezpośrednio odtwarzaczy audio. Napisy (1.2.2) i audiodeskrypcja (1.2.3) są też istotne, ale odnoszą się do wideo, nie do samego lektora audio.

Wyjątek dla mediów będących alternatywą tekstu

Tu jest zasada, którą pomija dziewięćdziesiąt pięć procent artykułów o zgodności. WCAG definiuje medium będące alternatywą tekstu jako medium, które nie zawiera więcej informacji niż tekst, do którego się odnosi. Gdy lektor TTS czyta istniejący artykuł, nagranie audio jest alternatywą medialną dla tekstu strony. Sam tekst strony jest transkrypcją.

Oznacza to, że wersja audio artykułu w postaci TTS nie wymaga osobnego pliku transkrypcji. WebAIM wyjaśnia to jasno. Warunek jest jeden: audio musi być wyraźnie oznaczone jako alternatywa medialna, żeby użytkownicy rozumieli, że pomijając je, nie tracą żadnych informacji. Nagłówek „Posłuchaj tego artykułu" lub odtwarzacz opisany jako „Wersja audio tego wpisu" spełniają ten wymóg.

Wyjątek nie ma zastosowania, gdy audio zawiera komentarz, muzyczne tło niosące znaczenie lub fragmenty nieobecne w tekście. Czyste lektorowanie treści strony kwalifikuje się do wyjątku. Korzystamy z tego regularnie, doradzając klientom wydawniczym, którzy obawiają się, że dodanie audio tworzy nowe obowiązki dotyczące transkrypcji.

Co nowego dla audio w WCAG 2.2

Trzy nowe kryteria na poziomie AA bezpośrednio dotyczą odtwarzaczy audio.

2.5.8 Rozmiar obszaru docelowego (minimum)

Każdy interaktywny element sterujący musi mieć obszar docelowy co najmniej 24 na 24 piksele CSS. To kryterium sprawia największe problemy wtyczkom audio dla WordPress. W naszych audytach witryn WordPress z wtyczkami audio podmiotów trzecich przyciski przewijania do przodu i do tyłu regularnie nie osiągają tej wartości. Projektanci wizualni optymalizowali pod kątem zwartości, zanim WCAG 2.2 wprowadził regułę 24 pikseli, a niewielu twórców wtyczek nadążyło z aktualizacją. Domyślne style motywu czasem dodatkowo zmniejszają te obszary.

Rozwiązanie to zazwyczaj padding, nie rozmiar ikony. Ikona SVG o rozmiarze 16 pikseli wewnątrz przycisku z paddingiem 4 pikseli z każdej strony spełnia próg 24 pikseli bez żadnych zmian wizualnych.

2.4.11 Fokus nie jest zasłonięty

Przyklejone paski audio na dole strony zasłaniają element, na którym skupiony jest użytkownik klawiatury. Jeśli aktywny link schowany jest za takim paskiem, kryterium nie jest spełnione. Rozwiązaniem jest umożliwienie zamknięcia paska, zostawienie miejsca powyżej aktywnego elementu lub użycie scroll-padding-bottom na dokumencie, żeby aktywne elementy pozostawały widoczne.

2.5.7 Gesty przeciągania

Własne paski postępu i suwaki głośności działające wyłącznie przez przeciąganie nie spełniają tego kryterium. Każda interakcja z przeciąganiem wymaga alternatywy z jednym wskaźnikiem. Kliknięcie w pasek postępu wystarczy. Spełnia to warunek, podobnie jak obsługa klawiszy strzałek na prawidłowo zbudowanym role="slider".

Najczęstsze błędy audio w WordPress na podstawie rzeczywistych audytów

Te same wzorce powtarzają się na stronach klientów. Najczęściej widzimy cztery rodzaje błędów.

Domyślny blok <audio> w rdzeniu WordPress renderuje natywny odtwarzacz przeglądarki. Natywne kontrolki audio przeglądarek mają długą historię niespójnego działania z czytnikami ekranu, a obsługa klawiaturowa pozycji głowicy różni się między Chrome, Firefox i Safari. Użytkownicy NVDA lub JAWS często słyszą znaczniki czasu, ale nie mogą niezawodnie zmienić pozycji klawiaturą. Rozwiązaniem jest owinięcie audio w niestandardowy odtwarzacz udostępniający role="slider" z odpowiednimi atrybutami wartości ARIA.

Wtyczki z odtwarzaczami dostarczają przyciski poniżej progu 24 pikseli. Projektant wizualny optymalizował pod kątem zwartości, zanim WCAG 2.2 wprowadził tę regułę. Motywy następnie nadpisują style wtyczki, co czasem pogarsza, a czasem poprawia sytuację.

Przyklejone paski audio zasłaniają aktywną treść. Ten błąd widzieliśmy na każdej stronie używającej przyklejonego odtwarzacza w stopce bez testowania nawigacji klawiaturowej.

Kontrast fal dźwiękowych jest regularnie poniżej 4,5:1. Projektantom podoba się jasno szara fala na białym tle. Czytniki ekranu tego nie zauważają, ale użytkownicy słabowidzący tak, i kryterium 1.4.3 nie jest spełnione.

Jak zbudować dostępny odtwarzacz audio: lista techniczna

1. Opakuj odtwarzacz w role="region" z aria-label opisującym go.
2. Użyj prawdziwego elementu <button> dla odtwarzania, pauzy, pomijania i wyciszenia. Nigdy <div> z obsługą kliknięcia.
3. Ustaw aria-pressed na przycisku odtwarzania, aby ujawnić stan przełącznika.
4. Nadaj każdemu elementowi sterującemu minimalny obszar 24 na 24 piksele CSS za pomocą paddingu.
5. Nadaj suwakom postępu i głośności role="slider" z atrybutami aria-valuemin, aria-valuemax i aria-valuenow, i reaguj na klawisze strzałek.
6. Dodaj kliknięcie pozycji na suwaku jako alternatywę dla przeciągania.
7. Sprawdź kontrast każdego elementu tekstowego i znaczącej ikony przy minimalnym współczynniku 4,5:1.
8. Upewnij się, że pierścienie fokusu są widoczne i nigdy nie są przycinane przez reguły overflow.
9. Jeśli odtwarzacz jest przyklejony, zostaw miejsce na fokus powyżej lub umożliw zamknięcie odtwarzacza.
10. Oznacz odtwarzacze lektora TTS jako „Wersja audio tego artykułu", żeby wyjątek dla alternatywy medialnej miał zastosowanie.

Minimalny dostępny przycisk odtwarzania wygląda tak.

<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>

To jest szkielet. Ostyluj przycisk, ukryj natywny wygląd zakresu jeśli chcesz własnego toru, ale zachowaj podstawową semantykę.

Jak lektor TTS poprawia ogólną zgodność z WCAG

Audio to nie tylko treść, która wymaga dostępności. Audio jest funkcją dostępności. Światowa Organizacja Zdrowia szacuje, że 1,3 miliarda ludzi, czyli około 16% światowej populacji, żyje z poważną niepełnosprawnością. Wiele z tych osób korzysta z wielomodalnego dostępu do treści tekstowych: osoby z dysleksją, ADHD, słabym wzrokiem i różnymi niepełnosprawnościami poznawczymi czytają wygodniej, gdy obok tekstu jest audio.

Dodanie lektora zamiany tekstu na mowę to jedna z nielicznych inwestycji w dostępność, która pomaga użytkownikom zanim spełni wymogi audytu. Dodanie TTS do WordPress zajmuje mniej niż 15 minut z wtyczką Text to Speech – TTSWP. Odtwarzacz jest dostarczany z domyślnymi ustawieniami zgodnymi z WCAG 2.1 AA, obszarami docelowymi 24 piksele i więcej, obsługą klawiatury oraz prawidłowymi rolami ARIA.

Minimalne obciążenie środowiska wykonawczego to około 35–40 KB po kompresji gzip (151 KB bez minifikacji), obejmujące zarówno logikę odtwarzacza JavaScript, jak i współdzielony CSS. Uruchomiliśmy GTmetrix na opublikowanym artykule z aktywnym odtwarzaczem i uzyskaliśmy ocenę A z wydajnością 93%, strukturą 99%, Largest Contentful Paint na poziomie 1,3 sekundy, Total Blocking Time na poziomie 46 milisekund i Cumulative Layout Shift równym zero. Paczka ładuje się leniwie tylko na stronach zawierających odtwarzacz, więc statyczne strony bez audio nie ponoszą żadnych kosztów.

Dokumentacja dostępności znajduje się na naszej stronie zaufania i dostępności. Lektor korzysta z silnika generatywnego ElevenLabs, który na tyle poprawia prozodię, że słuchacze faktycznie kończą artykuły zamiast porzucać robotyczne czytanie w połowie.

Europejski Akt o Dostępności w praktyce

EAA zaczął być egzekwowany 28 czerwca 2025 r. Nowe usługi cyfrowe wprowadzone na rynek UE po tej dacie muszą być zgodne od razu. Istniejące usługi mają czas do 28 czerwca 2030 r. na pełne dostosowanie. Dyrektywa dotyczy każdej firmy obsługującej klientów z UE, niezależnie od miejsca siedziby.

Normą techniczną, do której odnosi się EAA, jest EN 301 549. Aktualna wersja zharmonizowana (V3.2.1, sierpień 2021) opiera się na WCAG 2.1 Level AA. Projekt V4.1.0 opublikowany w listopadzie 2025 r. aktualizuje klauzule 9, 10 i 11, żeby były zgodne z WCAG 2.2, a ostateczna harmonizacja spodziewana jest w 2026 roku. Do czasu odniesienia do tej aktualizacji w Dzienniku Urzędowym UE, WCAG 2.1 AA pozostaje prawnie wiążącym minimum, ale zalecamy dążenie do zgodności z wersją 2.2 już teraz, bo przejście to kwestia miesięcy, nie lat.

Kary różnią się w zależności od kraju członkowskiego. Niemcy i Francja mają najaktywniejszą infrastrukturę egzekwowania, z krajowymi organami ds. dostępności uprawnionymi do badania skarg i nakładania grzywien. Widzieliśmy, że norwescy i niemieccy klienci otrzymywali formalne skargi od użytkowników końcowych w ciągu kilku miesięcy od daty egzekwowania, zazwyczaj dotyczące audio i elementów formularzy. Skargi pojawiają się przed grzywnami, więc trzydziestodniowe okno na naprawę jest zazwyczaj do osiągnięcia, jeśli zespół jest przygotowany.

Jak sprawdzić zgodność

Narzędzia automatyczne wyłapują około 30–40 procent problemów. Ręczne testowanie jest wymagane w pozostałych przypadkach, szczególnie w zakresie interakcji klawiaturowych i znaczącego kontrastu w stanach dynamicznych.

• NVDA w Windows z Chrome i Firefox. Bezpłatny.
• JAWS w Windows dla wymagań klientów korporacyjnych.
• VoiceOver w macOS i iOS. Wbudowany.
• TalkBack w Android. Wbudowany.
• axe DevTools – rozszerzenie przeglądarki do automatycznych skanów.
• Lighthouse w Chrome DevTools do szybkich sprawdzeń.
• Przejście wyłącznie klawiaturą. Odłącz mysz i obsłuż każdą kontrolkę odtwarzacza.

Przejście wyłącznie klawiaturą to pojedynczy test dający największy zwrot. Jeśli odtwarzacz działa bez myszy, większość WCAG 2.2 jest już spełniona.

Najczęściej zadawane pytania

Czy WCAG 2.2 wymaga napisów dla podcastów audio?

Nie. Napisy (1.2.2) dotyczą nagranych filmów z zsynchronizowanym dźwiękiem. W przypadku treści wyłącznie audio, takich jak podcasty, odpowiednim kryterium jest 1.2.1, które wymaga alternatywy tekstowej w postaci transkrypcji lub szczegółowego streszczenia. Napisy i transkrypcje służą różnym celom. Podcast potrzebuje transkrypcji. Film instruktażowy potrzebuje zarówno napisów, jak i audiodeskrypcji dla informacji wyłącznie wizualnych.

Czy automatyczne odtwarzanie audio jest niezgodne z prawem na podstawie EAA?

Nie jest nielegalne, ale jest ograniczone. WCAG 1.4.2 Kontrola dźwięku, do którego EAA odwołuje się przez EN 301 549, wymaga, aby dźwięk odtwarzany automatycznie przez ponad trzy sekundy oferował pauzę, zatrzymanie lub niezależną kontrolę głośności. Automatyczne odtwarzanie bez tej kontroli nie spełnia poziomu A i skutkuje stwierdzeniem niezgodności. Większość organów egzekwujących traktuje to jako wyraźne naruszenie, a nie przypadek graniczny.

Czy potrzebuję transkrypcji, jeśli mam wersję audio artykułu?

Zazwyczaj nie. Gdy audio jest bezpośrednim lektorem tekstu artykułu i nie dodaje nowych informacji, tekst artykułu sam w sobie jest transkrypcją zgodnie z definicją WCAG „medium będące alternatywą tekstu". Oznacz odtwarzacz wyraźnie jako wersję audio artykułu, a wyjątek ma zastosowanie. Jeśli audio zawiera komentarz, muzykę niosącą znaczenie lub fragmenty nieobecne w tekście, osobna transkrypcja jest wymagana.

Jaki jest minimalny rozmiar przycisku dla odtwarzaczy audio w WCAG 2.2?

Elementy interaktywne muszą mieć co najmniej 24 na 24 piksele CSS zgodnie z kryterium sukcesu 2.5.8 Rozmiar obszaru docelowego (minimum) na poziomie AA. Obszar docelowy obejmuje padding, więc ikona 16-pikselowa z paddingiem 4 pikseli z każdej strony spełnia wymaganie. Wyjątki istnieją dla linków umieszczonych w tekście i elementów sterowanych przez agenta użytkownika, ale samodzielne przyciski odtwarzacza nie mają wyjątku i muszą spełniać próg.

Czy WCAG 2.2 dotyczy witryn hostowanych na WordPress.com?

Tak. WCAG dotyczy każdej treści internetowej bez względu na platformę hostingową. Witryny WordPress.com mają taką samą ekspozycję prawną na podstawie EAA, ADA i równoważnych przepisów krajowych jak WordPress hostowany samodzielnie. Model hostingu nie zmienia obowiązku. Zmienia się zakres kontroli właściciela witryny nad kodem odtwarzacza. Plany WordPress.com Business i Commerce umożliwiają instalację własnych wtyczek, niższe plany nie.

Od czego zacząć

Wybierz jeden wpis na swojej stronie, przejdź przez odtwarzacz audio wyłącznie klawiaturą i sprawdź każdy przycisk pod kątem reguły 24 pikseli. Ten jeden audyt pokaże, czy Twoje obecne rozwiązanie jest bliskie zgodności z WCAG 2.2, czy daleko od niej. Od tego momentu wybór to naprawa istniejącego odtwarzacza lub zastąpienie go takim, który jest dostępny domyślnie. Nasza dokumentacja dostępności zawiera konfigurację, którą rekomendujemy dla witryn pod presją EAA.