WCAG 2.2 Lydtilgjengelighet for WordPress: Guide 2026

11 min lesing 20 min å lytte
WCAG 2.2 Lydtilgjengelighet for WordPress: Guide 2026

WordPress-lyd må oppfylle minst fire WCAG 2.2-suksesskriterier, inkludert 1.4.2 Lydkontroll, 2.1.1 Tastatur, 2.5.8 Målstørrelse (ny i 2.2) og 4.1.2 Navn, rolle, verdi. EUs tilgjengelighetsdirektiv, som trådte i kraft 28. juni 2025, gjør dette lovpålagt for alle nettsteder som betjener EU-kunder. Standard WordPress-lydspiller og de fleste tredjeparts lydplugins oppfyller ikke flere av disse kravene uten endringer.

Denne guiden er den praktiske sjekklisten vi bruker hos Mementor når vi reviderer WordPress-nettsteder for WCAG 2.2-samsvar. Vi dekker begge sider av lydspørsmålet: lyd som innhold med egne tilgjengelighetskrav, og lyd som et tilgjengelighetstiltak for tekstinnhold.

Hvorfor lydtilgjengelighet er viktig i 2026

Tre faktorer møttes i 2025 og gjorde dette til et presserende tema. EUs tilgjengelighetsdirektiv begynte håndhevingen 28. juni 2025. WebAIM Million 2025-rapporten fant at 96,3 prosent av hjemmesider hadde målbare WCAG-feil. ADA-søksmål i USA fortsatte å øke, og WordPress-nettsteder sto sentralt i over 4 000 tilgjengelighetssaker som ble anlagt i løpet av året.

Mønsteret vi ser i revisjonene våre er konsistent. Nettstedseiere regner med at temaet håndterer tilgjengelighet. Temaet arver det lydpluginen leverer. Lydpluginen leverer knapper som er for små, glidebrytere som fanger tastaturbrukere, og kontrastforhold som feiler ved første manuelle sjekk.

Den fullstendige WCAG 2.2-sjekklisten for lyd

Åtte suksesskriterier berører lyd på et WordPress-nettsted direkte. Tabellen nedenfor viser hva hvert kriterium betyr i praksis, hva standard WordPress-lyd gjør riktig eller galt, og hvordan TTSWP-spilleren håndterer det. Kriterier merket NY kom med WCAG 2.2 i oktober 2023.

KriteriumNivåHva det betyrStandard WP-lydTTSWP-spiller
1.2.1 LydalternativALyd-bare innhold trenger tekstalternativ Avhengig av tema Sidetekst fungerer som alternativ
1.4.2 LydkontrollAPause eller stopp for lyd som spilles automatisk i mer enn 3 sekunder Native nettleserkontroller Kun brukerinitiiert avspilling
1.4.3 Kontrast (minimum)AA4,5:1-forhold for spillerens UI-tekst og meningsfulle ikoner Avhengig av tema Alle standardverdier møter 4,5:1
2.1.1 TastaturAAlle kontroller må nås og brukes via tastatur Nettleseravhengig Full tastaturstøtte
2.4.11 Fokus ikke skjult NYAAFaste elementer kan ikke skjule innhold som har fokus Ikke aktuelt Fast linje viker ved fokuskonflikt
2.5.7 Drabevegelser NYAADra-interaksjoner trenger enkeltpeker-alternativ Kun dra på glidebryter Klikk-til-posisjon pluss piltaster
2.5.8 Målstørrelse NYAAInteraktive mål på minst 24 ganger 24 CSS-piksler Avhengig av tema Alle kontroller 24 piksler eller større
4.1.2 Navn, rolle, verdiAHver kontroll eksponerer tilgjengelig navn, rolle og tilstand Delvis Full ARIA-implementering

W3Cs Media Accessibility User Requirements-side er den kanoniske kilden for disse kriteriene. Vi fokuserer på de åtte ovenfor fordi de gjelder for lydspillere spesifikt. Teksting (1.2.2) og lydteksting (1.2.3) er også relevante, men gjelder video, ikke ren lydfortelling.

Diagram som viser de åtte WCAG 2.2-suksesskriteriene som gjelder for lyd
Åtte WCAG 2.2-suksesskriterier berører lyd på et WordPress-nettsted. Tre er nye i 2.2.

Unntaket for mediealternativ til tekst

Her er regelen som nesten alle artikler om samsvar overser. WCAG definerer et mediealternativ til tekst som media som ikke presenterer mer informasjon enn det som allerede finnes i teksten. Når TTS-fortelling leser opp en eksisterende artikkel, er lyden et mediealternativ til sideteksten. Sideteksten selv er transkripsjonen.

Dette betyr at en TTS-lydversjon av en artikkel ikke trenger en separat transkripsjonsfil. WebAIM forklarer dette tydelig. Forbeholdet er at lyden må være tydelig merket som et mediealternativ, slik at brukerne forstår at de ikke går glipp av informasjon ved å hoppe over den. En overskrift som «Lytt til denne artikkelen» eller en spiller merket «Lydversjon av dette innlegget» oppfyller dette.

Unntaket gjelder ikke hvis lyden inneholder kommentarer, musikk med meningsinnhold, eller avsnitt som ikke finnes i teksten. Ren opplesning av sideinnholdet kvalifiserer. Vi bruker dette regelmessig når vi rådgir publisister som bekymrer seg for at å legge til lyd skaper nye transkripsjonskrav.

Hva som er nytt for lyd i WCAG 2.2

Tre nye Level AA-kriterier påvirker lydspillere direkte.

2.5.8 Målstørrelse (minimum)

Alle interaktive kontroller trenger et mål på minst 24 ganger 24 CSS-piksler. Dette er kriteriet som bryter flest WordPress-lydplugins. I revisjonene våre av WordPress-nettsteder med tredjeparts lydplugins er det konsekvent tilbake- og fremoverhopp-knappene som faller under terskelen. Visuelle designere prioriterte kompakthet før WCAG 2.2 innførte 24-piksel-regelen, og få plugin-vedlikeholdere har tatt igjen forsinkelsen. Standard temastiler krymper noen ganger målene ytterligere.

Løsningen er vanligvis å legge til polstring, ikke å endre ikonstørrelsen. Et 16-piksel SVG-ikon inne i en knapp med 4 pikslers polstring på hver side når 24-piksel-terskelen uten å endre det visuelle.

2.4.11 Fokus ikke skjult

Faste lydlinjer nederst på siden dekker det tastaturbrukeren har fokus på. Hvis en lenke med fokus befinner seg bak linjen, feiler kriteriet. Løsningen er enten å gjøre linjen avvisbar, la det være plass over fokusmålet, eller bruke scroll-padding-bottom på dokumentet slik at elementer med fokus forblir synlige.

2.5.7 Drabevegelser

Egendefinerte skrubblinjer og volumglidebrytere som bare fungerer med dra, feiler dette kriteriet. Alle dra-interaksjoner trenger et enkeltpeker-alternativ. Klikk-til-posisjon på en fremdriftslinje oppfyller kravet. Det gjør også piltastkontroll på en riktig bygget role="slider".

Vanlige WordPress-lydfeil fra faktiske revisjoner

Mønstrene gjentar seg på tvers av klientnettsteder. Vi ser fire feil oftest.

Standard WordPress-kjerne <audio>-blokk gjengir den innebygde nettleserspilleren. Innebygde lydkontroller har en lang historikk med inkonsistent oppførsel med skjermlesere, og piltastkontroll av avspillingsposisjonen varierer mellom Chrome, Firefox og Safari. Brukere med NVDA eller JAWS hører ofte tidsstemplene, men kan ikke flytte posisjonen pålitelig med tastaturet. Løsningen er å pakke lyden inn i en egendefinert spiller som eksponerer role="slider" med riktige ARIA-verdiattributter.

Plugin-spillere leverer knapper under 24-piksel-terskelen. Designeren prioriterte kompakthet før WCAG 2.2 innførte regelen. Temaer overstyrer deretter plugin-stilene, noe som noen ganger gjør ting verre og noen ganger bedre.

Faste lydlinjer skjuler innhold med fokus. Vi har sett dette feile på alle nettsteder som bruker en fast bunntekstspiller uten å teste tastaturnavigasjon.

Kontrast på bølgeformer er konsekvent under 4,5:1. Designere elsker den duse grå bølgen på hvit bakgrunn. Skjermlesere bryr seg ikke, men svaksynte gjør det, og 1.4.3 feiler.

Bygge en tilgjengelig lydspiller: den tekniske sjekklisten

  1. Pakk spilleren inn i role="region" med en aria-label som beskriver den.
  2. Bruk en ekte <button> for play, pause, hopp og demp. Aldri <div> med en klikkbehandler.
  3. Sett aria-pressed på play-knappen for å eksponere vekslingstilstanden.
  4. Gi alle kontroller et minimum mål på 24 ganger 24 CSS-piksler ved hjelp av polstring.
  5. Gjør skrubber og volum til role="slider" med aria-valuemin, aria-valuemax og aria-valuenow, og responder på piltaster.
  6. Tilby klikk-til-posisjon på skrubberen som et ikke-dra-alternativ.
  7. Test kontrast på alle tekstelementer og meningsfulle ikoner med minimum 4,5:1.
  8. Sørg for at fokusringer er synlige og aldri klippes av overflow-regler.
  9. Hvis spilleren er fast, la det være fokusrom over den eller gjør den avvisbar.
  10. Merk TTS-fortellerspillere som «Lydversjon av denne artikkelen» slik at unntaket for mediealternativ gjelder tydelig.

En minimal tilgjengelig play-knapp ser slik ut.

<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 er grunnstrukturen. Stil knappen, skjul de native range-visuelle elementene om du vil ha en egendefinert spor, men behold den underliggende semantikken.

Hvordan TTS-fortelling forbedrer den samlede WCAG-samsvar

Lyd er ikke bare innhold som skal gjøres tilgjengelig. Det er et tilgjengelighetstiltak. Verdens helseorganisasjon anslår at 1,3 milliarder mennesker, rundt 16 prosent av verdensbefolkningen, lever med en betydelig funksjonsnedsettelse. Mange av dem har nytte av multimodal tilgang til tekstinnhold: mennesker med dysleksi, ADHD, svaksynthet og ulike kognitive utfordringer leser mer komfortabelt med lyd ved siden av teksten.

Å legge til tekst til tale-fortelling er en av få tilgjengelighetsinvesteringer som hjelper brukere før den oppfyller en revisjon. Å legge til Tekst til Tale - TTSWP i WordPress tar under 15 minutter med Tekst til Tale - TTSWP-pluginen. Spilleren leveres med WCAG 2.1 AA-konforme standardverdier, 24-piksel-pluss-mål, tastaturstøtte og riktige ARIA-roller.

GTmetrix ytelsesrapport for en artikkel med TTSWP aktivert
GTmetrix ytelsesrapport på en publisert artikkel med TTSWP-spilleren aktiv. Karakter A på alle områder, inkludert null Cumulative Layout Shift.

Den minimale kjøretidspakken er omtrent 35 til 40 KB gzippet (151 KB uminifisert), som dekker både JavaScript-spillerlogikken og delt CSS. Vi kjørte GTmetrix på en publisert artikkel med spilleren aktiv og fikk karakter A med 93 prosent ytelse, 99 prosent struktur, Largest Contentful Paint på 1,3 sekunder, Total Blocking Time på 46 millisekunder og Cumulative Layout Shift på null. Pakken lastes inn lat kun på sider som inneholder spilleren, slik at statiske sider uten lyd ikke har noen ekstra belastning.

Tilgjengelighetsdokumentasjonen finnes på vår tilgjengelighets-trustside. Fortelling bruker ElevenLabs-motoren, som forbedrer prosodien nok til at lyttere faktisk fullfører artikler i stedet for å gi opp en robotaktig opplesning.

EUs tilgjengelighetsdirektiv i praksis

EUs tilgjengelighetsdirektiv ble håndhevbart 28. juni 2025. Nye digitale tjenester som tilbys i EU-markedet etter denne datoen må overholde kravene nå. Eksisterende tjenester har til 28. juni 2030 på seg til å få alt på plass. Direktivet gjelder enhver virksomhet som betjener EU-kunder, uavhengig av hvor virksomheten holder til.

Den tekniske standarden EUs tilgjengelighetsdirektiv refererer til, er EN 301 549. Den gjeldende harmoniserte versjonen (V3.2.1, august 2021) er bygget på WCAG 2.1 Level AA. Utkast V4.1.0 publisert i november 2025 oppdaterer klausulene 9, 10 og 11 for å samsvare med WCAG 2.2, med endelig harmonisering forventet i løpet av 2026. Inntil den oppdateringen er referert i EUs offisielle tidende, er WCAG 2.1 AA det juridisk bindende minimumet, men vi anbefaler å sikte på 2.2 nå siden overgangen er måneder unna, ikke år.

Bøter varierer etter medlemsstat. Tyskland og Frankrike har den mest aktive håndhevingsinfrastrukturen, med nasjonale tilgjengelighetsmyndigheter som har fullmakt til å etterforske klager og ilegge bøter. Vi har sett norske og tyske klienter motta formelle klager fra sluttbrukere innen måneder etter håndhevingsdatoen, som regel om lyd- og skjemaelementer. Klagene kommer før bøtene, så et reparasjonsvindu på tretti dager er vanligvis gjennomførbart hvis teamet er forberedt.

Slik tester du samsvar

Automatiserte verktøy fanger opp rundt 30 til 40 prosent av problemene. Manuell testing er nødvendig for resten, særlig tastaturinteraksjon og meningsfull kontrast på dynamiske tilstander.

  • NVDA på Windows med Chrome og Firefox. Gratis.
  • JAWS på Windows for bedriftskunders forventninger.
  • VoiceOver på macOS og iOS. Innebygd.
  • TalkBack på Android. Innebygd.
  • axe DevTools nettleserutvidelse for automatiserte skanninger.
  • Lighthouse i Chrome DevTools for raske kontroller.
  • Kun tastatur-gjennomgang. Koble fra musen og betjen alle spillerkontroller.

Kun tastatur-gjennomgangen er den enkelt mest effektive testen. Fungerer spilleren uten mus, er de fleste kravene i WCAG 2.2 allerede oppfylt.

Ofte stilte spørsmål

Krever WCAG 2.2 teksting for lydpodkaster?

Nei. Teksting (1.2.2) gjelder forhåndsinnspilt video med synkronisert lyd. For lyd-bare innhold som podkaster er det relevante kriteriet 1.2.1, som krever et tekstalternativ som et transskript eller et detaljert sammendrag. Teksting og transskripter tjener ulike formål. En podkast trenger transskriptet. En videoopplæring trenger både teksting og lydteksting for visuell informasjon.

Er autospilling av lyd ulovlig under EUs tilgjengelighetsdirektiv?

Ikke ulovlig, men begrenset. WCAG 1.4.2 Lydkontroll, som EUs tilgjengelighetsdirektiv refererer til gjennom EN 301 549, krever at lyd som spilles automatisk i mer enn tre sekunder, må tilby en pause-, stopp- eller uavhengig volumkontroll. Automatisk avspilling uten denne kontrollen feiler Level A og utgjør et manglende samsvarsfunn. De fleste håndhevingsorganer behandler dette som et klart brudd, ikke som et grensetilfelle.

Trenger jeg et transskript hvis jeg har en lydversjon av artikkelen min?

Vanligvis ikke. Når lyden er en direkte opplesning av artikkelteksten og ikke legger til ny informasjon, er artikkelteksten selv transkripsjonen etter WCAG-definisjonen «mediealternativ til tekst». Merk spilleren tydelig som en lydversjon av artikkelen, og unntaket gjelder. Hvis lyden inneholder kommentarer, musikk med meningsinnhold, eller avsnitt som ikke finnes i teksten, trenger du et separat transskript.

Hva er minimum knappestørrelse for lydspillere i WCAG 2.2?

Interaktive mål må være minst 24 ganger 24 CSS-piksler under suksesskriterium 2.5.8 Målstørrelse (minimum) på Level AA. Målet inkluderer polstring, så et 16-piksel ikon med 4 pikslers polstring på hver side oppfyller kravet. Unntak finnes for innebygde lenker i tekst og kontroller bestemt av nettleseren, men frittstående spillerknapper har ingen unntak og må nå terskelen.

Gjelder WCAG 2.2 for nettsteder hostet på WordPress.com?

Ja. WCAG gjelder for alt nettinnhold uavhengig av hostingplattform. WordPress.com-nettsteder har den samme juridiske eksponeringen under EUs tilgjengelighetsdirektiv, ADA og tilsvarende nasjonale lover som selvhostede WordPress-nettsteder. Hostingmodellen endrer ikke forpliktelsen. Det som endrer seg, er hvor mye kontroll nettstedseieren har over spillerens markup. WordPress.com Business- og Commerce-planer tillater egendefinerte plugins, lavere abonnementer gjør det ikke.

Hvor du bør begynne

Velg ett innlegg på nettstedet ditt, kjør en kun tastatur-gjennomgang av lydspilleren, og sjekk hver knapp mot 24-piksel-regelen. Den enkle revisjonen avslører om det nåværende oppsettet er nær WCAG 2.2-samsvar eller langt fra det. Derfra er valget å reparere den eksisterende spilleren eller erstatte den med en som leveres samsvarsferdig som standard. Vår tilgjengelighetsdokumentasjon dekker konfigurasjonen vi anbefaler for nettsteder under EAA-press.