EAA & WCAG 2.1: Guide til universell utforming 2026

#Hva er European Accessibility Act (EAA) og WCAG 2.1

Fra 28. juni 2025 gjelder de nasjonale lovene som gjennomfører European Accessibility Act (EAA) i EU-landene. De omfatter ikke alle nettsteder, men forbrukertjenestene som direktivet lister opp, blant annet netthandel, bank, elektronisk kommunikasjon og deler av persontransport. Mikrovirksomheter som yter tjenester er unntatt. I Norge gjelder EAA ennå ikke: ifølge Uutilsynet er gjennomføringen i Norge, Island og Liechtenstein forsinket. Selger du til forbrukere i EU, gjelder loven i landet du selger til. Hele listen, unntakene og de nasjonale reglene står i guiden om tilgjengelighet i WordPress og WCAG 2.2. Denne artikkelen handler om noe annet: hvordan selve gjennomføringen foregår på et WordPress-nettsted.

Direktivet nevner ikke WCAG ved navn, men kravene bygger på de samme fire prinsippene, og derfor måles revisjoner mot WCAG 2.1 eller 2.2 nivå AA. Det er et sett med retningslinjer som sikrer at digitalt innhold er tilgjengelig for personer med nedsatt funksjonsevne, eldre og brukere som møter midlertidige begrensninger.

WCAG 2.1 (Web Content Accessibility Guidelines) er en internasjonal standard som definerer hvordan man skal designe og kode nettsteder for å være mulig å oppfatte, mulig å betjene, forståelig og robust. Brudd på de nasjonale lovene som gjennomfører EAA kan få økonomiske og juridiske konsekvenser.

#Hvorfor er digital tilgjengelighet viktig for nettsteder

• Ifølge EU-kommisjonen lever 90 millioner mennesker i EU med en funksjonsnedsettelse, en stor gruppe potensielle kunder for nettstedet ditt.
• Mer enn bare funksjonshemming: Tilgjengelighet (universell utforming) hjelper eldre, personer med midlertidige skader (f.eks. en brukket arm), de med konsentrasjonsvansker, eller bare brukere på mobil i sterkt sollys.
• Bedre brukeropplevelse (UX): Tilgjengelighet betyr enklere navigasjon, tydeligere innhold og et intuitivt grensesnitt for alle.
• SEO: Mange WCAG-krav overlapper med god praksis for SEO (responsivitet, logisk struktur, ALT-attributter).
• Konvertering: Enklere kjøpsprosess, tydelige skjemaer og bedre kundeservice.
• Risikoreduksjon: Bøter for manglende overholdelse kan være betydelige.
• Merkevarebygging: Det bygger et rykte som et samfunnsansvarlig og moderne selskap.

#Hva betyr WCAG 2.1 AA-samsvar i praksis

Her er nøkkelkrav du må implementere:

1. Tastaturnavigasjon: Hele nettstedet må kunne betjenes uten mus.
2. Skjermleser-kompatibilitet: Riktig HTML-semantikk, overskrifter, bildebeskrivelser (ALT) og skjemaetiketter.
3. Fargekontrast: Tekst må være lesbar for personer med nedsatt syn (minimumsforhold på 4.5:1).
4. Multimedia: Teksting og transkripsjoner for video- og lydinnhold.
5. Klar struktur: Korrekt bruk av H1-H6 overskrifter og logisk layout.
6. Feilhåndtering: Klare meldinger i skjemaer som forklarer hvordan feil kan rettes.
7. Tilgjengelige PDF-er og dokumenter: Riktig formatert og lesbare for skjermlesere.
8. Responsivitet: Nettstedet må fungere flytende på mobil, nettbrett og skrivebord.

#Hvordan implementerer vi WCAG 2.1 med wppoland.com

1. Tilgjengelighetsrevisjon: Vi gjennomfører en detaljert revisjon av ditt WordPress-nettsted, som kombinerer automatiske verktøy med manuell verifisering av eksperter.
2. Optimalisering av tema og plugins: Vi modifiserer dine eksisterende komponenter eller anbefaler tilgjengelige alternativer.
3. Utbedring: Vi implementerer kodeendringer, fikser overskriftsstrukturer, forbedrer skjemaetiketter og optimaliserer mediefiler.
4. Opplæring og support: Vi lærer teamet ditt hvordan man lager tilgjengelig innhold (f.eks. hvordan skrive gode ALT-tekster).
5. Tilgjengelighetserklæring: Vi hjelper deg med å utarbeide erklæringen og en kanal for tilbakemeldinger om tilgjengelighetsproblemer.

Seksjonene nedenfor bryter disse trinnene ned i konkrete beslutninger. Referansen er WCAG-EM 2.0, metoden for å evaluere samsvar med WCAG som W3C publiserte som Group Note 23. juli 2026. Den deler evalueringen i fem trinn: definere omfanget, utforske nettstedet, velge et representativt utvalg, evaluere utvalget og rapportere funnene.

#Hvordan definere omfanget av en tilgjengelighetsrevisjon i WordPress

Første trinn i WCAG-EM har fire deler: nettstedets omfang, mål for samsvarsnivå, et grunnlag for tilgjengelighetsstøtte og eventuelle tilleggskrav. På et WordPress-nettsted blir hver del en konkret beslutning.

Nettstedets omfang. Det må stå hva som vurderes: bare hoveddomenet, eller også et underdomene med nettbutikk, kundeportal, språkversjoner og kampanjesider. I en multisite-installasjon kan hvert nettsted i nettverket ha eget tema og egne plugins, så et nettsted som holdes utenfor, må skrives ned eksplisitt.

Mål for samsvarsnivå. For tjenester som omfattes av EAA er nivå AA det praktiske målet. Valget mellom WCAG 2.1 og 2.2 bør stå i omfanget, fordi det avgjør hvilke suksesskriterier revisoren sjekker. WordPress har selv valgt WCAG 2.2 AA for sin egen kode, som guiden om WCAG 2.2 beskriver.

Grunnlag for tilgjengelighetsstøtte. WCAG-EM krever at man fastsetter hvilke kombinasjoner av nettlesere og hjelpemidler evalueringen bygger på. For eksempel: NVDA med Firefox eller Chrome på Windows, VoiceOver med Safari på macOS og iOS, TalkBack med Chrome på Android. Uten en slik liste kan to revisjoner av samme nettsted gi ulike resultater, og ingen av dem kan gjentas.

Tilleggskrav. Her havner det som går utover selve samsvaret, for eksempel vurdering av utvalgte AAA-kriterier eller en brukertest med personer med funksjonsnedsettelser.

#Hvordan velge sider til utvalget i en WCAG-revisjon

Andre trinn i WCAG-EM er å utforske nettstedet: felles visninger, viktig funksjonalitet, sidetyper og teknologiene innholdet er avhengig av. Metoden definerer felles visninger som de som gjelder hele nettstedet, vanligvis lenket direkte fra inngangssiden: forsiden, hjelp, juridisk informasjon og kontakt.

I WordPress lønner det seg å utforske etter malhierarkiet, fordi én mal gjengir hundrevis av adresser. En typisk liste over sidetyper:

Tredje trinn er å velge utvalget. WCAG-EM kombinerer tre deler. Det strukturerte utvalget dekker felles visninger, viktig funksjonalitet og et eksempel på hver sidetype. Det tilfeldige utvalget utgjør ifølge metoden 10 % av antall sider i det strukturerte utvalget og legges til i tillegg: med 30 sider i den strukturerte delen kommer 3 tilfeldige i tillegg. Komplette prosesser betyr at hvis en side hører til en prosess, må hvert trinn i prosessen være med, inkludert startpunktet, standardsekvensen og viktige forgreninger.

For en WooCommerce-butikk er den komplette kjøpsprosessen handlekurv, kundeopplysninger, valg av frakt og betaling, ordrebekreftelse og veien med en valideringsfeil. For et kontaktskjema er det tomt skjema, skjema med feil og meldingen etter innsending. En revisjon som hopper over feiltilstanden, hopper over stedet der en skjermleserbruker oftest blir sittende fast.

#Hva resultatene fra det tilfeldige utvalget forteller

Fjerde trinn i WCAG-EM er å evaluere de valgte sidene og prosessene, og deretter sammenligne resultatene fra den strukturerte og den tilfeldige delen. Hvis de tilfeldige sidene viser problemer som ikke fantes i den strukturerte delen, var utvalget ikke representativt og må utvides. I WordPress skjer dette som regel når utforskningen har oversett en innholdstype: et gammelt innlegg fra den klassiske editoren, en side bygget med en annen sidebygger, eller en plugin som setter inn sin egen widget bare på noen av sidene.

Metoden forutsetter også at den som evaluerer har god forståelse av WCAG 2, hjelpemidler og hvordan personer med funksjonsnedsettelser bruker nettsteder. Å kjøre et automatisk verktøy oppfyller ikke den forutsetningen, fordi verktøyet ikke kan vurdere om en alternativ tekst beskriver bildet, eller om fokusrekkefølgen gir mening.

#Hvordan prioritere utbedringer etter en tilgjengelighetsrevisjon

En revisjonsrapport inneholder som regel dusinvis av feil. I WordPress bestemmes rekkefølgen best ut fra hvor feilen oppstår, ikke ut fra rekkefølgen i listen.

1. Komplette prosesser som blokkerer målet. En feil som gjør det umulig å fullføre en bestilling eller sende et skjema, stenger tjenesten for en hel brukergruppe, så den kommer først.
2. Felles maldeler. Topptekst, meny, bunntekst, samtykkebanner og søk vises på hver side. Én rettelse i en maldel eller i temafilen fjerner feilen fra hele nettstedet.
3. Gjenbrukte komponenter. Egne blokker, mønstre, kortkoder og widgeter fra plugins. Her er spørsmålet: rette, erstatte med et tilgjengelig alternativ eller fjerne.
4. Redaksjonelt innhold. Alternative tekster, overskrifter i innlegg, lenketekster og PDF-filer. Denne delen rettes av redaksjonen, så retningslinjer og eksempler må følge med rettelsene.

Inndelingen har også en budsjettside: rettelsene i punkt 2 og 3 gjøres én gang og virker på tusenvis av adresser, mens punkt 4 vokser med mengden innhold.

#Hvordan teste nettstedet med brukere av hjelpemidler

En revisjon etter WCAG viser om nettstedet oppfyller kriteriene. Den viser ikke om det er behagelig å bruke. W3C WAI anbefaler i «Involving Users in Evaluating Web Accessibility» å involvere personer med funksjonsnedsettelser gjennom hele arbeidet, ikke bare til slutt, og påpeker at korte, uformelle kontroller underveis gir mer enn én formell test.

Fra dette materialet følger konkrete regler for hvordan testen organiseres:

• Ekspertgjennomgang først. Åpenbare barrierer fjernes før brukerne inviteres, slik at tiden deres ikke går med til problemer revisjonen allerede har funnet.
• Noen få personer, ulike behov. WAI anbefaler å ta med noen få personer med funksjonsnedsettelser, og eldre brukere hvis de er en del av målgruppen. Erfaringsnivået bør passe målgruppen: i en offentlig tjeneste teller også nybegynnere med skjermleser.
• Tenke høyt. Deltakeren sier hva hun eller han gjør og forventer, og testlederen noterer hvor en barriere fører til feil.
• Forsiktige konklusjoner. WAI advarer: «Unngå å anta at innspill fra én person med funksjonsnedsettelse gjelder for alle personer med funksjonsnedsettelser» (W3C WAI, egen oversettelse). Problemet kan ligge i innholdet, i nettleseren, i hjelpemiddelet eller i hvor godt deltakeren kjenner det.

En brukertest erstatter ikke revisjonen. WAI skriver at den alene ikke kan avgjøre om et nettsted er tilgjengelig, så den kombineres med evaluering etter WCAG. I et WordPress-prosjekt er et godt tidspunkt for testen når malrettelsene er på plass i staging og innholdet er ekte, ikke testinnhold.

#Hva en tilgjengelighetserklæring for et WordPress-nettsted bør inneholde

W3C WAI angir i veiledningen om tilgjengelighetserklæringer et minimum: en forpliktelse til tilgjengelighet, standarden som er brukt (f.eks. WCAG 2.2) og kontaktinformasjon hvis brukere møter problemer. Veiledningen anbefaler også kjente begrensninger, tiltak organisasjonen har gjort, tekniske forutsetninger, miljøene innholdet er testet i, og henvisninger til gjeldende lover.

Den gratis erklæringsgeneratoren fra W3C leder gjennom disse feltene. Mest arbeid krever delen om begrensninger, fordi generatoren for hvert kjente problem spør om fem ting: hvilken del av innholdet det gjelder, hva problemet er, hvorfor det oppstår, hva organisasjonen gjør med det og hva brukeren kan gjøre i mellomtiden. For å fylle den ut ærlig trengs revisjonsresultatene, så erklæringen skrives etter evalueringen, ikke før. Generatoren har også felt for samsvarsstatus (fullt, delvis, ikke i samsvar, ikke vurdert) og for vurderingsmetode: egenvurdering eller ekstern vurdering.

For tjenester som omfattes av EAA kommer en plikt fra selve direktivet. Artikkel 13 nr. 2 i direktiv 2019/882 krever at tjenesteyteren utarbeider informasjon i samsvar med vedlegg V og forklarer hvordan tjenesten oppfyller tilgjengelighetskravene. Informasjonen skal være offentlig tilgjengelig skriftlig og muntlig, også på en måte som er tilgjengelig for personer med funksjonsnedsettelser, og den skal oppbevares så lenge tjenesten er i drift. Vedlegg V sier at informasjonen tas inn i de alminnelige vilkårene for tjenesten eller et tilsvarende dokument, og at den der det er relevant omfatter:

• en generell beskrivelse av tjenesten i tilgjengelige formater,
• beskrivelser og forklaringer som trengs for å forstå hvordan tjenesten fungerer,
• en beskrivelse av hvordan tjenesten oppfyller de relevante tilgjengelighetskravene i vedlegg I.

For en nettbutikk på WordPress betyr det vanligvis to dokumenter: en side med tilgjengelighetserklæringen for brukerne og et avsnitt i kjøpsvilkårene med informasjonen vedlegg V krever. Begge bør lenkes fra bunnteksten, slik at de kan nås fra hver side.

#Hvordan holde nettstedet tilgjengelig etter utbedringene

Tilgjengeligheten til et WordPress-nettsted endres ved hver oppdatering av tema og plugins og ved hvert nytt innlegg. Direktivet tar høyde for dette i artikkel 13 nr. 3: tjenesteyteren må ha prosedyrer som sikrer at tjenesten fortsatt er i samsvar med kravene, og må ta hensyn til endringer i tjenesten, i kravene og i standardene den viser til. Artikkel 13 nr. 4 legger til at tjenesteyteren ved manglende samsvar skal sette inn korrigerende tiltak og straks informere de nasjonale myndighetene.

I praksis består en slik prosedyre på et WordPress-nettsted av noen faste elementer:

• Ny vurdering av utvalget etter endringer. Utvalget fra revisjonen (felles visninger, sidetyper, komplette prosesser) blir en sjekkliste etter oppdatering av tema, skjema- eller butikkplugins og etter endringer i en maldel.
• Dokumentasjon av resultater. WCAG-EM anbefaler i femte trinn å dokumentere resultatene fra hvert trinn, og eventuelt også en maskinlesbar rapport. Det gratis WCAG-EM Report Tool leder gjennom trinnene i metoden og lager en rapport som kan sammenlignes med neste revisjon.
• Retningslinjer for redaksjonen. De fleste nye feil etter gjennomføringen kommer fra innholdet: manglende alternativ tekst, et hoppet overskriftsnivå, en PDF skannet som bilde.
• Håndtering av henvendelser. Kontaktkanalen i erklæringen trenger en eier og en svartid, fordi W3C-generatoren spør nettopp om typisk svartid.

Hvis en virksomhet viser til uforholdsmessig byrde etter artikkel 14, må vurderingen dokumenteres og oppbevares i fem år. Det er enda en grunn til å samle revisjonsresultater og beslutninger om rettelser på ett sted.

#Hvem kan implementere EAA og WCAG 2.1 i WordPress

• WordPress-spesialister: Vi kjenner økosystemet ut og inn, inkludert WooCommerce.
• Helhetlig tilnærming: Vi krysser ikke bare av på lister; vi sikter mot reell brukervennlighet.
• Juridisk trygghet: Vi hjelper deg å navigere i kompleksiteten i EAA for å unngå bøter.

Ta kontakt via skjemaet for en revisjon.

Universell utforming blir sjelden riktig av en avkrysningsliste alene, den blir riktig når tastaturnavigasjon og kontraster testes på ekte innhold. Skal EAA-kravene inn i en side som allerede er i drift, tar vi det som en del av tilgjengelig WordPress-utvikling.