Tilgjengelighet (WCAG 2.2) i 2026: Er WordPress-siden din lovlig?

I EU gjelder European Accessibility Act (EAA), direktiv (EU) 2019/882, fra 28. juni 2025. Norge er ikke der ennå. Tilsynet for universell utforming av IKT (Uutilsynet) skriver at Norge er i prosess med å innlemme direktivet, og at gjennomføringen i EØS-landene Norge, Island og Liechtenstein er forsinket. Samtidig har Norge allerede egne krav til digital tilgjengelighet som gjelder både private og offentlige nettsteder.

For WordPress-utviklere og nettstedeiere er WCAG 2.2 nivå AA et praktisk teknisk mål, selv om det norske regelverket i dag bygger på et utvalg av WCAG 2.1-kravene. Denne guiden viser hvilke WCAG 2.2-kriterier som oftest knekker WordPress-temaer, hva norske regler og EU-direktivet faktisk krever, og hvordan du tester før hver lansering. Den erstatter ikke juridisk rådgivning.

Offisielle kilder: WCAG 2.2-anbefalingen, teksten i direktiv 2019/882, Uutilsynets regelverkssider og WordPress sin tilgjengelighetshåndbok.

#Hvilke tilgjengelighetskrav gjelder for norske nettsteder

Uutilsynet sier det kort: IKT-løsninger i Norge skal være universelt utformet. Det gjelder nettsider, apper og automater, og både private og offentlige virksomheter, lag og organisasjoner må følge regelverket.

Kravene er hentet fra WCAG 2.1, men ikke alle. Ifølge Uutilsynets oversikt over WCAG-kravene skal offentlig sektor følge 48 krav og privat sektor 35 krav. Dette er minimumskrav. For offentlig sektor kom flere krav fra EUs webdirektiv (WAD), med endringer som gjelder fra 1. februar 2023. Se også vår guide til WordPress i offentlig sektor.

#Er WCAG 2.2 en del av det norske regelverket

Nei. Uutilsynet skriver at WCAG 2.2 ikke er en del av regelverket nå, og at dette ikke endrer seg på kort sikt. Om nye krav tas inn, avhenger av om EU tar WCAG 2.2 inn i revisjonen av EN 301 549, den harmoniserte standarden til webdirektivet, og en eventuell oppdatering skjer i en nasjonal regelverksprosess som gjerne tar et par år. Uutilsynet ber også virksomhetene fortsette å følge 4.1.1 Parsing inntil videre, fordi kriteriet inngår i minstekravene, selv om det er fjernet fra WCAG 2.2.

Det betyr ikke at WCAG 2.2 er uinteressant i Norge. De nye kriteriene beskriver feil som også rammer norske brukere, og et nettsted som selger til EU-land, må forholde seg til lovene der.

#Hvem omfattes av EUs tilgjengelighetsdirektiv

EAA utvider kravene til privat sektor, men bare for bestemte kategorier. Artikkel 2 nr. 2 i direktivet lister tjenestene som ytes til forbrukere etter 28. juni 2025:

• elektroniske kommunikasjonstjenester;
• tjenester som gir tilgang til audiovisuelle medietjenester;
• elementer av persontransport med fly, buss, tog og båt (nettsteder, apper, elektroniske billetter, reiseinformasjon);
• banktjenester for forbrukere;
• e-bøker og programvare for dem;
• netthandelstjenester.

Direktivet definerer netthandel som tjenester som ytes på avstand via nettsteder og mobilapper, på individuell forespørsel fra en forbruker, med sikte på å inngå en forbrukeravtale. En WooCommerce-butikk som selger til forbrukere i EU, faller inn under definisjonen. Et nettsted for et konsulentselskap som bare selger til bedrifter, står ikke på listen.

#Hvilke unntak direktivet har

• Svært små foretak som yter tjenester (artikkel 4 nr. 5) er unntatt fra tilgjengelighetskravene til tjenester. Direktivet definerer et svært lite foretak som et foretak med færre enn 10 ansatte og en årlig omsetning eller balansesum på høyst 2 millioner euro. Unntaket gjelder ikke produkter.
• Grunnleggende endring og uforholdsmessig byrde (artikkel 14): kravene gjelder bare så langt de ikke endrer tjenestens grunnleggende art eller gir en uforholdsmessig byrde. Vurderingen skal dokumenteres og oppbevares i fem år.
• Unntatt innhold (artikkel 2 nr. 4): blant annet forhåndsinnspilte medier og kontordokumenter publisert før 28. juni 2025, og innhold fra tredjeparter som virksomheten verken finansierer, utvikler eller kontrollerer.

#Frister i direktivet

Direktivet fastsetter ingen bøtebeløp. Artikkel 30 krever at hvert land har sanksjoner som er effektive, forholdsmessige og avskrekkende, og som tar hensyn til hvor alvorlig bruddet er, antall produkter eller tjenester og antall berørte personer.

#Hvordan EU-land har gjennomført EAA og hvilke bøter som gjelder

Selger du til forbrukere i EU, gjelder loven i landet du selger til. Se vår sammenligning av bøter og plikter per land. Kortversjonen:

#Hvilken teknisk standard EAA bygger på

EAA nevner ikke WCAG. Vedlegg I krever at nettsteder og mobilapper gjøres tilgjengelige på en konsekvent og egnet måte, ved at de er mulige å oppfatte, betjene, forstå og robuste: de samme fire prinsippene som WCAG bygger på. Artikkel 15 gir en presumpsjon for samsvar for tjenester som følger harmoniserte standarder publisert i EU-tidende.

WordPress har allerede valgt versjon. Kodestandardene for tilgjengelighet sier at kode i WordPress-økosystemet, inkludert kjernen, WordPress.org-sidene og offisielle utvidelser, forventes å oppfylle WCAG 2.2 nivå AA, og at nye redigeringsgrensesnitt bør følge ATAG 2.0.

#Hva som er endret fra WCAG 2.1 til WCAG 2.2

WCAG 2.2 ble W3C-anbefaling 5. oktober 2023, og gjeldende utgave er datert 12. desember 2024. Ifølge What’s new in WCAG 2.2 kommer det ni nye suksesskriterier:

Seks av dem teller mot et AA-mål. De tre AAA-kriteriene er likevel nyttige som designmål.

#Hvorfor WCAG 2.2 fjernet 4.1.1

4.1.1 Parsing er merket som utdatert og fjernet. W3C begrunner det med at hjelpemidler ikke lenger tolker HTML selv, men bruker nettleseren, og at feil som før brøt 4.1.1, i dag bryter 1.3.1 Informasjon og relasjoner eller 4.1.2 Navn, rolle, verdi. Som nevnt krever det norske regelverket fortsatt 4.1.1.

#Hvordan du oppfyller de nye WCAG 2.2-kriteriene i WordPress-temaer

#2.4.11 Fokus ikke skjult (minimum, AA)

Når en komponent får tastaturfokus, kan den ikke være helt skjult av innhold forfatteren har laget. AAA-varianten (2.4.12) krever at ingen del er skjult.

• Problemet: Du tabber nedover en side. Et element får fokus, men den faste toppmenyen eller cookie-banneret dekker det. Brukeren vet at fokus er et sted, men ser ikke hvor.
• Løsningen: Bruk scroll-padding-top på html-elementet, slik at fokuserte elementer ruller inn i det synlige området under toppmenyen.

html {
  scroll-padding-top: 80px; /* Høyden på den faste toppmenyen */
}

La cookie-banneret ligge i tabulatorrekkefølgen med en synlig lukkeknapp, og unngå overflow: hidden på beholdere som klipper bort fokusrammen.

#2.4.7 Synlig fokus og 2.4.13 Fokusutseende

Mange temaer fjerner outline av estetiske grunner uten å erstatte det. Det bryter 2.4.7 Synlig fokus, som fortsatt er nivå AA. Kriterium 2.4.13 (AAA) gir et målbart designmål: indikatorens areal skal være minst like stort som en 2 CSS-piksler tykk ramme rundt komponenten uten fokus, med kontrast på minst 3:1 mellom de samme pikslene med og uten fokus.

I blokktemaer hører :focus-visible-stilen hjemme i theme.json eller i et lite stilark som lastes både i redigeringsverktøyet og på nettstedet.

#2.5.7 Drabevegelser (AA)

All funksjonalitet som bruker drabevegelser, skal kunne utføres med én peker uten å dra, med mindre draingen er nødvendig. Det gjelder sorterbare menyer, glidebrytere og byggere i kanban-stil. Gutenberg har alternativer for mange interaksjoner; egne blokker som bare lytter etter dra-hendelser, trenger knapper eller skjemafelt.

#2.5.8 Målstørrelse (minimum, AA)

Pekermål skal være minst 24 ganger 24 CSS-piksler. Kriteriet har fem unntak:

• Avstand: et mindre mål består hvis en sirkel med 24 CSS-pikslers diameter sentrert på målet ikke krysser et annet mål eller sirkelen til et annet lite mål.
• Ekvivalent: samme funksjon finnes i en annen kontroll på siden som oppfyller kravet.
• I tekst: målet står i en setning, eller størrelsen begrenses av linjehøyden i teksten.
• Styrt av nettleseren: nettleseren bestemmer størrelsen, og forfatteren har ikke endret den.
• Nødvendig: en bestemt presentasjon er nødvendig eller lovpålagt.

Sjekk små «X»-knapper i popup-vinduer, pagineringspiler, rader med sosiale ikoner, avkrysningsbokser og karusellkontroller. Med padding, min-width og min-height blir trykkflaten større uten at ikonet endrer seg visuelt.

#3.2.6 Konsekvent hjelp (A)

Hvis hjelpemekanismer gjentas på flere sider, skal de stå i samme rekkefølge i forhold til resten av innholdet. Kriteriet dekker kontaktinformasjon til en person, en mekanisme for å kontakte en person, et selvhjelpsalternativ og en helautomatisk kontaktmekanisme, for eksempel en chatbot. Hold støttelenken eller chat-widgeten på samme sted i WordPress-malen på alle sider.

#3.3.7 Overflødig inntasting (A)

Informasjon brukeren allerede har oppgitt i samme prosess, skal fylles ut automatisk eller være tilgjengelig for valg. Unntakene er når ny inntasting er nødvendig, kreves av sikkerhetshensyn, eller når den tidligere verdien ikke lenger er gyldig. I WooCommerce dekker valget «fakturaadresse er lik leveringsadresse» det vanligste tilfellet.

#3.3.8 Tilgjengelig autentisering (minimum, AA)

Ingen steg i innloggingen kan kreve en kognitiv funksjonstest, som å huske et passord eller løse en gåte, med mindre steget gir minst ett av disse: en alternativ metode uten slik test, en mekanisme som hjelper brukeren (for eksempel en passordbehandler), en test på å gjenkjenne objekter, eller å gjenkjenne ikke-tekstlig innhold brukeren selv har lagt inn. AAA-varianten (3.3.9) fjerner de to siste unntakene.

• WordPress-påvirkningen: ikke blokker innliming i felt for passord og engangskoder, slik at passordbehandlere virker. Bruk innloggingslenker på e-post eller WebAuthn og passnøkler der produktet tillater det. Sjekk skript fra medlemsutvidelser som sperrer innliming, og botvegger fra tredjeparter.

#Hvorfor er semantisk HTML fundamentet for WCAG

De fleste varige rettelser er rett og slett korrekt HTML, uten utvidelser og overlegg.

• Landemerker: Bruk <main>, <nav>, <aside>, <footer>. Skjermleserbrukere hopper mellom disse regionene. Ikke drukne alt i <div>-suppe.
• Overskrifter: h1 til h6 er et hierarki, ikke et stilvalg. Ikke hopp fra h2 til h4 bare fordi du vil ha en mindre skrifttype. Bruk CSS for størrelse.
• Knapper og lenker:
  • Går til en ny URL? Bruk <a>.
  • Endrer noe på gjeldende side (åpner en meny)? Bruk <button>.
  • Bruk aldri <div onClick="...">. Det får ikke tastaturfokus, og skjermlesere annonserer det ikke som et interaktivt element.
• Bilder: bilder med innhold får alt, dekorative bilder får tom alt.

ARIA er et supplement der vanlig HTML ikke strekker til. En ekte <button> er bedre enn role="button" på et span.

#Hvilke Gutenberg-blokker som ofte feiler tilgjengelighetstester

Kjerneblokkene og blokkredigereren har fått bedre tastaturstøtte over flere versjoner. Det gjør ikke hver publiserte side tilgjengelig. Mønstre som fortsatt feiler:

• Gruppe- og omslagsblokker med tekst i lav kontrast over bilder. Sjekk kontrasten etter at temaets fargepalett er brukt.
• Navigasjonsblokken med megamenyer som bare åpnes ved musepeker over. Legg til åpning med klikk eller Enter og lukking med Escape.
• Egne blokker som viser interaktive widgeter uten fokuserbare elementer eller med feil aria-expanded.
• Mønstre fra markedsplasser med feil nestede overskrifter eller dobbel h1.

For skribenter: sjekk overskriftsrekkefølgen i listevisningen før publisering, og bruk de innebygde bilde- og galleriblokkene slik at alt-feltet kan redigeres. For temautviklere: test både lerretet i nettstedsredigereren og HTML-en på nettstedet, fordi de ikke alltid er like.

#Hvordan du tester klassiske temaer og blokktemaer

Klassiske PHP-temaer feiler når malene har utilgjengelige menyer hardkodet eller style.css fjerner fokusstiler. Hybride oppsett (klassisk tema med blokkmaldeler) trenger de samme testene av faste elementer og fokus i både PHP- og HTML-maler.

Blokktemaer (theme.json, maldeler) samler farger og typografi. Det hjelper på kontrasten hvis paletten er laget med AA-forhold. Det gjør det også lett å lansere en global fast toppmeny som bryter 2.4.11 på hver side: rettelsen gjøres én gang, i toppmenyens maldel.

WooCommerce og skjemautvidelser ligger oppå temaet. Kasse, konto og kontaktskjema trenger hver sin tastaturtest.

#Hva taggen accessibility-ready krever av et WordPress-tema

Temakatalogen på WordPress.org gir taggen accessibility-ready bare etter en ekstra gjennomgang. Håndboken til temateamet lister 18 obligatoriske krav:

1. lenke for å hoppe til innholdet;
2. landemerker med meningsfulle roller og navn;
3. full tastaturnavigasjon;
4. kontroller med tilgjengelig navn, rolle og tilstand;
5. skjemafelt med etiketter;
6. overskrifter med meningsfull struktur;
7. understrekede lenker i brødtekst;
8. ingen tvetydige lenketekster;
9. tilstrekkelig kontrast for tekst og kontroller;
10. alternativ tekst for bilder og grafikk;
11. tilgjengelig lyd, video og animasjon;
12. støtte for reflow, forstørrelse og endret tekstavstand;
13. ingen uventede kontekstendringer;
14. ingen lenker som åpner nye vinduer eller faner uten varsel;
15. tilgjengelig innhold ved musepeker eller fokus;
16. en tilgjengelighetserklæring;
17. ingen anbefaling av eller krav om utilgjengelige utvidelser;
18. støtte for tekst kun for skjermlesere.

Taggen sertifiserer ikke nettstedet ditt, fordi utvidelser, mønstre og innhold kan knekke et gjennomgått tema. Den gir et gjennomgått utgangspunkt og en sjekkliste for egne temaer.

#Hvorfor løser ikke accessibility-overlays WCAG

Du har sett dem: det lille ikonet med en person i en sirkel i hjørnet, som åpner en meny for å endre kontrast eller skriftstørrelse.

Ikke bruk dem som vei til samsvar.

• Falsk trygghet: De lover samsvar med én linje JavaScript, men retter ikke semantisk HTML i temaet.
• Brukerfriksjon: Blinde brukere har allerede satt opp skjermleserne sine. Et overlegg kan komme i konflikt med disse verktøyene.
• Regulatorisk risiko: 22. april 2025 godkjente det amerikanske handelstilsynet FTC en endelig ordre der accessiBe må betale én million dollar. FTC mente at påstandene om at widgeten kunne gjøre ethvert nettsted WCAG-samsvarende, var falske, villedende eller udokumenterte.

Den eneste reelle løsningen er tilgjengelig kode fra start, eller å rette den eksisterende koden.

#Hvordan tester du tilgjengelighet før hver lansering

Du kan ikke automatisere tilgjengelighet 100 %. Automatiske verktøy er første steg, men de overser de fleste tastaturfeller og mange tilfeller av skjult fokus.

#Tilgjengelighetstest i tre steg

1. Automatisert: Bruk axe-core eller tilgjengelighetsrevisjonen i Lighthouse på forside, arkiv, innlegg, søk, skjema og kasse. Dette fanger opp manglende alt-tekst, lav kontrast og feil i ARIA-attributter, og kan kjøres ved hver utrulling i CI.
2. Manuell tastatur: Koble fra musen. Kan du navigere i hele menyen, åpne undermenyene og sende kontaktskjemaet med kun Tab, Enter og Mellomrom? Sjekk at fokus er synlig, at rekkefølgen er logisk og at modaler lukkes med Escape.
3. Skjermleser: Slå på VoiceOver (Mac) eller NVDA (Windows) på samme flyt. Har skjemaene beskrivende etiketter, og blir statusendringer lest opp?

Test på nytt etter temaoppdateringer, etter oppdateringer av utvidelser som endrer markup, og etter malendringer i nettstedsredigereren. Mange regresjoner kommer med en CSS-endring som setter outline: none. Vi har også beskrevet en praktisk arbeidsflyt for tilgjengelighetsrevisjon som bygger på disse stegene.

Verktøy som passer i en WordPress-arbeidsflyt: axe DevTools i nettleseren, WAVE fra WebAIM, Pa11y på kommandolinjen i CI og utvidelsen Accessibility Checker i redigereren.

#Hvordan lager du tilgjengelige skjemaer i WordPress

Contact Form 7, Gravity Forms og egne skjemaer følger de samme reglene.

• Etiketter: Hvert felt trenger en <label> som er koblet programmatisk. Plassholdere er ikke etiketter, de forsvinner når du skriver.
• Feilmeldinger: «Feil funnet» er ubrukelig. «E-postadressen mangler @-tegnet» er tilgjengelig. Koble meldingen til feltet med aria-describedby.
• Fokusstyring: Når skjemaet kommer tilbake med feil, flytt tastaturfokuset til det første feilfeltet eller til et sammendrag med lenker til feltene.
• Obligatoriske felt: Bruk attributtet required, ikke bare en rød stjerne.
• Innliming: Ikke sperr innliming i felt for passord og engangskoder.

#Hvordan gjør du WooCommerce og headless WordPress tilgjengelig

Kassen i WooCommerce må fungere fra start til slutt med tastatur: legg i handlekurv, endre antall, bruk rabattkode, betal og les bekreftelsen. Produktsammenligninger trenger ekte <table> med <th> og scope. Varsler i handlekurven bør bruke aria-live="polite", slik at skjermleseren leser opp endringen uten å avbryte brukeren.

Headless-frontender i React, Next.js eller Astro har et problem klassiske temaer ikke har: ruteendringer i en enkeltsideapp laster ikke siden på nytt. Etter hver ruteendring flytter du fokus til hovedinnholdet, leser opp den nye sidetittelen via en aria-live-region og oppdaterer document.title. Rendering på serveren hjelper, fordi innholdet ligger i den første HTML-en før JavaScript kjører.

#Hva bør du prioritere for WCAG 2.2 i 2026

• Synlige :focus-visible-stiler i hele temaet, aldri skjult av toppmeny eller banner.
• Mål på 24 ganger 24 CSS-piksler, eller med avstanden 2.5.8 tillater.
• Et alternativ uten draing for hver kontroll som dras.
• Hjelp i samme rekkefølge på alle maler.
• Ingen gjentatt inntasting av de samme dataene i samme prosess.
• Innlogging som godtar innlimte passord og koder.
• De 35 norske minstekravene for privat sektor, inkludert 4.1.1, i tillegg til WCAG 2.2.

Trenger du en tilgjengelighetsrevisjon av maler, blokker eller kassen, starter WPPoland med en dokumentert gjennomgang av malene du faktisk publiserer, ikke med et overlegg. En bredere vurdering av EU-krav beskriver EU-samsvarsrevisjonen.