WCAG 2.2 och ljudtillgänglighet i WordPress: Guide 2026

WordPress-ljud måste uppfylla minst fyra WCAG 2.2-framgångskriterier: 1.4.2 Ljudkontroll, 2.1.1 Tangentbord, 2.5.8 Målstorlek (ny i 2.2) och 4.1.2 Namn, roll, värde. European Accessibility Act, som började gälla den 28 juni 2025, gör detta juridiskt bindande för alla sajter som betjänar EU-kunder. WordPress standardljudspelare och de flesta tredjeparts-ljud-plugins klarar inte flera av dessa krav utan ändringar.

Den här guiden är den praktiska checklistan vi använder på Mementor när vi granskar WordPress-sajter för WCAG 2.2-efterlevnad. Vi täcker båda sidorna av ljudfrågan: ljud som innehåll med egna tillgänglighetsregler, och ljud som en tillgänglighetsfunktion för textinnehåll.

Varför ljudtillgänglighet är viktigt 2026

Tre faktorer sammanföll under 2025 och gjorde detta till ett angeläget ämne. EAA började gälla den 28 juni 2025. WebAIM Million 2025-rapporten visade att 96,3 % av alla startsidor hade detekterbara WCAG-brister. ADA-rättegångarna i USA fortsatte öka, och WordPress-sajter var framträdande i de över 4 000 webbtillgänglighetsmål som väcktes under året.

Mönstret vi ser i våra granskningar är konsekvent. Webbplatsägare utgår ifrån att temat hanterar tillgängligheten. Temat ärver vad ljud-pluginet levererar. Ljud-pluginet levererar knappar som är för små, skjutreglage som fastnar för tangentbordsanvändare och kontrastkvoter som inte håller vid den första manuella kontrollen.

Den fullständiga WCAG 2.2-checklistan för ljud

Åtta framgångskriterier berör ljud på en WordPress-sajt direkt. Tabellen nedan visar vad varje kriterium innebär i praktiken, vad WordPress standardljud klarar eller missar, och hur TTSWP-spelaren hanterar det. Kriterier markerade NY tillkom med WCAG 2.2 i oktober 2023.

W3C:s sida Media Accessibility User Requirements är den officiella källan för dessa kriterier. Vi fokuserar på de åtta ovan eftersom de gäller ljudspelarna direkt. Textning (1.2.2) och syntolkning (1.2.3) är också relevanta men gäller video, inte ren ljudberättelse.

Undantaget för mediaalternativ till text

Här är regeln som 95 procent av alla efterlevnadsartiklar missar. WCAG definierar ett mediaalternativ till text som media som inte presenterar mer information än vad som redan finns i text. När text till tal-berättelse läser upp en befintlig artikel är ljudet ett mediaalternativ för sidtexten. Sidtexten är i sig transkriptionen.

Det innebär att en text till tal-version av en artikel inte behöver en separat transkriptionsfil. WebAIM förklarar detta tydligt. Villkoret är att ljudet måste vara tydligt märkt som ett mediaalternativ så att användarna förstår att de inte missar information om de hoppar över det. En rubrik som "Lyssna på den här artikeln" eller en spelare märkt "Ljudversion av detta inlägg" uppfyller kravet.

Undantaget gäller inte om ljudet innehåller kommentarer, musikunderlägg med innebörd eller avsnitt som inte finns i texten. Ren uppläsning av sidinnehållet kvalificerar sig. Vi lutar oss mot detta regelbundet när vi ger råd till förlagskunderna, som oroar sig för att ljud skapar nya transkriptionskrav.

Vad som är nytt för ljud i WCAG 2.2

Tre nya Level AA-kriterier påverkar ljudspelarna direkt.

2.5.8 Målstorlek (minimum)

Varje interaktiv kontroll behöver en klickyta på minst 24 × 24 CSS-pixlar. Det här är kriteriet som fäller flest WordPress-ljud-plugins. I våra granskningar av WordPress-sajter med tredjeparts-ljud-plugins är det konsekvent hoppa-bakåt- och hoppa-framåt-knapparna som inte når gränsen. Visuella designers optimerade för kompakthet innan WCAG 2.2 införde 24-pixelregeln, och få plugin-utvecklare har hunnit ikapp. Temats standardstilar krymper ibland målytorna ytterligare.

Lösningen är vanligtvis utfyllnad, inte ikonstorlek. En 16-pixels SVG-ikon inuti en knapp med 4 pixlars utfyllnad på varje sida når 24-pixelgränsen utan att ändra det visuella utseendet.

2.4.11 Fokus inte dolt

Fästa ljudrader längst ned på sidan täcker det som tangentbordsanvändaren har fokus på. Om en fokuserad länk hamnar bakom raden misslyckas kriteriet. Lösningen är antingen att göra raden stängbar, lämna utrymme ovanför fokusytan, eller använda scroll-padding-bottom på dokumentet så att fokuserade element förblir synliga.

2.5.7 Draginteraktioner

Anpassade tidslinjereglage och volymreglage som bara fungerar med drag misslyckas med det här kriteriet. Varje draginteraktion kräver ett enkelpekar-alternativ. Klicka till position på en förloppsindikator uppfyller det. Det gör även piltangentskontroll på ett korrekt byggt role="slider".

Vanliga WordPress-ljudfel från verkliga granskningar

Mönstren upprepas på kundernas sajter. Vi ser fyra fel oftast.

WordPress standardblocket <audio> renderar webbläsarens inbyggda spelare. Webbläsarens inbyggda ljudkontroller har en lång historia av inkonsekvent beteende med skärmläsare, och piltangentsstyrning av uppspelningspositionen varierar mellan Chrome, Firefox och Safari. Användare med NVDA eller JAWS hör ofta tidsstämplarna men kan inte på ett tillförlitligt sätt flytta positionen med tangentbordet. Lösningen är att omsluta ljud i en anpassad spelare som exponerar role="slider" med korrekta ARIA-värdesattribut.

Plugin-spelare levererar knappar under 24-pixelgränsen. Den visuella designern optimerade för kompakthet innan WCAG 2.2 införde regeln. Teman åsidosätter sedan plugin-stilarna, vilket ibland gör saker sämre och ibland bättre.

Fästa ljudrader döljer fokuserat innehåll. Vi har sett detta misslyckas på varje sajt som använder en fast footer-spelare utan att testa tangentbordsnavigering.

Kontrasten på vågformer är konsekvent under 4,5:1. Designers älskar den mjuka grå vågen på vitt. Skärmläsare bryr sig inte, men synskadade användare gör det, och 1.4.3 misslyckas.

Att bygga en tillgänglig ljudspelare: den tekniska checklistan

1. Omge spelaren med role="region" och ett beskrivande aria-label.
2. Använd en riktig <button> för uppspelning, paus, hoppa och tysta. Aldrig <div> med en klickhanterare.
3. Sätt aria-pressed på uppspelningsknappen för att exponera växlingstillståndet.
4. Ge varje kontroll en minsta yta på 24 × 24 CSS-pixlar med utfyllnad.
5. Gör skrubber och volym till role="slider" med aria-valuemin, aria-valuemax och aria-valuenow, och svara på piltangenter.
6. Erbjud klicka till position på skrubbern som ett icke-drag-alternativ.
7. Testa kontrasten på alla textelement och meningsfulla ikoner mot minst 4,5:1.
8. Kontrollera att fokusringar är synliga och aldrig klipps av overflow-regler.
9. Om spelaren är fäst, lämna fokusrum ovanför den eller gör den stängbar.
10. Märk text till tal-spelarna som "Ljudversion av den här artikeln" så att undantaget för mediaalternativ gäller tydligt.

En minimal tillgänglig uppspelningsknapp ser ut så här.

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

Det är grunden. Styla knappen, dölj de inbyggda range-visualerna om du vill ha ett anpassat spår, men behåll den underliggande semantiken.

Hur text till tal-berättelse förbättrar den övergripande WCAG-efterlevnaden

Ljud är inte bara innehåll som ska göras tillgängligt. Det är en tillgänglighetsfunktion. Världshälsoorganisationen uppskattar att 1,3 miljarder människor, ungefär 16 % av världsbefolkningen, lever med en betydande funktionsnedsättning. Många av dem drar nytta av multimodal tillgång till textinnehåll: personer med dyslexi, ADHD, nedsatt syn och olika kognitiva funktionsnedsättningar läser mer bekvämt med ljud vid sidan av text.

Att lägga till text till tal-berättelse är en av få tillgänglighetsinvesteringar som hjälper användare innan den uppfyller en granskning. Att lägga till text till tal i WordPress tar under 15 minuter med pluginet Text till tal - TTSWP. Spelaren levereras med WCAG 2.1 AA-konforma standardinställningar, 24-pixlar-plus-mål, tangentbordsstöd och korrekta ARIA-roller.

Den minimala körtidsnyttolasten är ungefär 35 till 40 KB gzippad (151 KB ominifierat), vilket täcker både JavaScript-spelarlogiken och delad CSS. Vi körde GTmetrix på en publicerad artikel med spelaren aktiv och fick betyg A med 93 % prestanda, 99 % struktur, Largest Contentful Paint på 1,3 sekunder, Total Blocking Time på 46 millisekunder och Cumulative Layout Shift på noll. Bunten laddas lazy enbart på sidor som innehåller spelaren, så statiska sidor utan ljud har ingen extra overhead.

Tillgänglighetsdokumentationen finns på vår tillgänglighetssida. Berättelsen använder ElevenLabs generativa motor, som förbättrar prosodi tillräckligt för att lyssnare faktiskt läser klart artiklarna i stället för att ge upp vid robotläsning.

European Accessibility Act i praktiken

EAA blev verkställbar den 28 juni 2025. Nya digitala tjänster som lanseras på EU-marknaden efter det datumet måste följa lagen nu. Befintliga tjänster har fram till den 28 juni 2030 på sig att komma i linje. Direktivet gäller alla företag som betjänar EU-kunder, oavsett var företaget är baserat.

Den tekniska standard som EAA hänvisar till är EN 301 549. Den nuvarande harmoniserade versionen (V3.2.1, augusti 2021) är byggd på WCAG 2.1 Level AA. Utkast V4.1.0 publicerat i november 2025 uppdaterar klausulerna 9, 10 och 11 för att anpassa till WCAG 2.2, med slutlig harmonisering förväntad under 2026. Tills den uppdateringen refereras i EU:s officiella tidning förblir WCAG 2.1 AA det juridiskt bindande minimumet, men vi rekommenderar att sikta på 2.2 nu eftersom övergången är månader bort snarare än år.

Påföljderna varierar mellan medlemsstaterna. Tyskland och Frankrike har den mest aktiva tillsynsinfrastrukturen, med nationella tillgänglighetsmyndigheter som har befogenhet att utreda klagomål och utfärda böter. Vi har sett norska och tyska kunder ta emot formella klagomål från slutanvändare inom månader efter ikraftträdandedatumet, vanligtvis om ljud- och formulärkomponenter. Klagomålen kommer före böterna, så ett trettiodagars åtgärdsfönster är vanligtvis genomförbart om teamet är förberett.

Hur du testar efterlevnad

Automatiserade verktyg fångar ungefär 30 till 40 procent av problemen. Manuell testning krävs för resten, särskilt tangentbordsinteraktion och meningsfull kontrast på dynamiska tillstånd.

• NVDA på Windows med Chrome och Firefox. Gratis.
• JAWS på Windows för företagskunders förväntningar.
• VoiceOver på macOS och iOS. Inbyggt.
• TalkBack på Android. Inbyggt.
• axe DevTools webbläsartillägg för automatiska skanningar.
• Lighthouse i Chrome DevTools för snabba kontroller.
• Genomgång med enbart tangentbord. Koppla bort musen och använd alla spelarkontroller.

Genomgången med enbart tangentbord är det enskilt mest effektiva testet. Om spelaren fungerar utan mus är det mesta av WCAG 2.2 redan uppfyllt.

Vanliga frågor

Kräver WCAG 2.2 textning för ljudpodcaster?

Nej. Textning (1.2.2) gäller förinspelad video med synkroniserat ljud. För ljudbaserat innehåll som podcaster är det relevanta kriteriet 1.2.1, som kräver ett textalternativ som en transkription eller en detaljerad sammanfattning. Textning och transkriptioner tjänar olika syften. En podcast behöver transkriptionen. En videohandledning behöver både textning och syntolkning för visuell information.

Är automatisk uppspelning av ljud olagligt under EAA?

Inte olagligt, men begränsat. WCAG 1.4.2 Ljudkontroll, som EAA refererar till via EN 301 549, kräver att ljud som spelas automatiskt i mer än tre sekunder måste erbjuda paus, stopp eller oberoende volymkontroll. Automatisk uppspelning utan den kontrollen misslyckas på Level A och skapar ett efterlevnadsproblem. De flesta tillsynsorgan behandlar detta som en tydlig överträdelse snarare än ett gränsfall.

Behöver jag en transkription om jag har en ljudversion av min artikel?

Vanligtvis inte. När ljudet är en direkt uppläsning av artikeltexten och inte tillför ny information är artikeltexten i sig transkriptionen enligt WCAG:s definition av "mediaalternativ till text". Märk spelaren tydligt som en ljudversion av artikeln så gäller undantaget. Om ljudet innehåller kommentarer, musik med innebörd eller avsnitt som inte finns i texten behöver du en separat transkription.

Vad är den minsta knappstorleken för ljudspelares i WCAG 2.2?

Klickbara ytor måste vara minst 24 × 24 CSS-pixlar enligt framgångskriterium 2.5.8 Målstorlek (minimum) på Level AA. Målet inkluderar utfyllnad, så en 16-pixlars ikon med 4 pixlars utfyllnad på varje sida uppfyller kravet. Undantag finns för inbyggda länkar i text och kontroller som bestäms av användaragenten, men fristående spelarknappar har inget undantag och måste nå gränsen.

Gäller WCAG 2.2 för WordPress.com-hostade sajter?

Ja. WCAG gäller allt webbinnehåll oavsett hostingplattform. WordPress.com-sajter har samma juridiska exponering under EAA, ADA och motsvarande nationella lagar som självhostade WordPress-sajter. Hostingmodellen ändrar inte skyldigheten. Vad som ändras är hur mycket kontroll sajtägaren har över spelarens markup. WordPress.com Business- och Commerce-planer tillåter anpassade plugins, lägre nivåer gör det inte.

Var du börjar

Välj ett inlägg på din sajt, gör en genomgång med enbart tangentbord av ljudspelaren och kontrollera varje knapp mot 24-pixelregeln. Den enda granskningen visar om din nuvarande setup är nära WCAG 2.2-efterlevnad eller långt ifrån den. Därifrån är valet att åtgärda den befintliga spelaren eller ersätta den med en som levereras kompatibel som standard. Vår tillgänglighetsdokumentation täcker den konfiguration vi rekommenderar för sajter under EAA-press.