Tilgjengelighet og WCAG 2.2: hvordan WordPress holder mål i 2026

WCAG 2.2 er den tekniske terskelen. Den juridiske rammen i Norge er nasjonal, ikke EU sin. Det er den enkleste setningen å starte med, og den er også den oftest misforståtte i samtaler om tilgjengelighet på WordPress. Norge er med i EØS, ikke i EU, og det betyr at Web Accessibility Directive ikke gjelder direkte. Forpliktelsene dine er forankret i norsk rett: Likestillings- og diskrimineringsloven og Forskrift om universell utforming av IKT-løsninger, som de fleste kjenner som WAD-forskriften eller Tilgjengelighetsforskriften. WCAG 2.2 er det målepunktet som forskriften viser til når den definerer hva universell utforming faktisk betyr på nett.

#TL;DR

• Tilgjengelighet i Norge styres av Likestillings- og diskrimineringsloven og Forskrift om universell utforming av IKT-løsninger, ikke av EU-direktivet direkte.
• WCAG 2.2 ble W3C-anbefaling 5. oktober 2023 og legger ni nye suksesskriterier over WCAG 2.1.
• Digitaliseringsdirektoratet, Digdir, er tilsynsmyndighet og kan kreve dokumentasjon av samsvar.
• WordPress kan møte kravet, men det forutsetter et accessibility-ready tema, gransket bruk av plugins og en disiplinert audit-rytme.
• En headless WordPress-installasjon arver ikke tilgjengelighet fra WordPress: det er front-end-rammeverket som har ansvaret.

#Hva norsk lov krever

Det første sporet er Likestillings- og diskrimineringsloven. Den slår fast et generelt forbud mot diskriminering, inkludert manglende universell utforming, og er den loven en bruker kan påberope seg dersom et nettsted i praksis stenger vedkommende ute. Loven peker videre til mer spesifikke regler om hva universell utforming betyr på IKT-feltet.

Det andre sporet er Forskrift om universell utforming av IKT-løsninger. Denne forskriften gjennomfører Web Accessibility Directive, formelt Directive 2016/2102, i norsk rett. Det skjedde fordi Norge gjennom EØS-avtalen har forpliktet seg til store deler av EU sitt regelverk for det indre marked, men gjennomføringen skjer alltid via en norsk forskrift eller lov, og det er den norske teksten som gjelder for norske aktører. Den juridiske terskelen din er altså forskriften, ikke direktivet.

Det tredje sporet er tilsynet. Digitaliseringsdirektoratet, Digdir, fører tilsyn med at virksomheter etterlever forskriften, og publiserer veiledning, testresultater og statusrapporter. Digdir kan be om dokumentasjon, kan teste sider, og kan reagere når avvik ikke lukkes. Det betyr i praksis at tilgjengelighet ikke er en intern øvelse: den er noe en ekstern myndighet kan komme tilbake til deg på.

Når det gjelder hvem som er omfattet, er hovedlinjen tydelig. Offentlig sektor er fullt omfattet. Private virksomheter er omfattet når de retter seg mot allmennheten, altså når nettstedet i praksis er en kanal for tjenester eller varer til folk flest. Det vil si at en kommune sin selvbetjeningsportal og en nettbutikk på WooCommerce begge ligger innenfor virkeområdet. En lukket intern HR-portal kan stå i en annen posisjon, men selv der lønner det seg å bruke samme målestokk fordi ansatte og partnere også kan ha funksjonsnedsettelser.

#Hva WCAG 2.2 legger på toppen

WCAG 2.2 er ikke en omveltning av WCAG 2.1, men den lukker reelle hull. Anbefalingen ble publisert 5. oktober 2023 og introduserer ni nye suksesskriterier. Her er hovedlinjene, oversatt til hva de faktisk betyr i et redaktørgrensesnitt eller en kasseflyt:

• Synlig fokusmarkering, Focus Appearance: når en bruker tabulerer gjennom siden, skal det aktive elementet ha en markering som er kontrastrik nok og stor nok til å sees uten anstrengelse.
• Fokus skal ikke skjules, Focus Not Obscured: et sticky header eller en cookie-banner som dekker fokuset til et tastaturnavigerende element, er ikke lenger akseptabelt.
• Alternativer til drabevegelser, Dragging Movements: alt som krever å dra med musen, må også kunne utføres med en enkelt tap eller klikk. Drag-and-drop i sortering, kart og slidere må ha tastaturalternativer.
• Klikkflate, Target Size Minimum: interaktive elementer skal være minst 24 ganger 24 CSS-piksler, med definerte unntak. Dette rammer ikoniske handlingsknapper i mange WordPress-temaer hardt.
• Konsistent hjelp, Consistent Help: når et nettsted tilbyr hjelp, kontaktinformasjon eller chat, skal den være på samme sted på tvers av sider.
• Redundant inntasting, Redundant Entry: brukeren skal slippe å fylle inn samme informasjon flere ganger i samme flyt, med mindre det er nødvendig av sikkerhetsgrunner.
• Tilgjengelig autentisering, Accessible Authentication: pålogging skal ikke være avhengig av kognitive tester som å huske eller løse oppgaver, dersom det ikke finnes et alternativ.

For en WordPress-eier oversettes dette til konkrete spørsmål: dekker checkout-temaet ditt minste klikkflate på alle ikoner og lenker? Mister tastaturbrukeren fokuset bak det sticky kjøp-baren din? Krever 2FA-løsningen din å huske et bilde, uten et alternativ? Hver av de ni nye kriteriene har en direkte motpart i typiske WordPress-mønstre.

#Hvordan WordPress matcher kravet

WordPress sin egen posisjon er ikke nøytral. Plattformen har et offisielt accessibility-team som setter krav til kjernen, til standardtemaer som Twenty Twenty-Four og Twenty Twenty-Five, og til editor-grensesnittet. Når et temå publiseres på WordPress.org og søker merket accessibility-ready, må det bestå en strukturert gjennomgang av accessibility-teamet. Det merket er en god basislinje, men det er ikke en sluttattest for nettstedet ditt. Det dekker temaet, ikke innholdet, ikke skjemaene dine, ikke pluginsene dine.

Editor-siden er en større fortelling. Block-editoren er bygget med tilgjengelighet på agendaen og har gjørt betydelige fremskritt. Det betyr at en redaktør med skjermleser eller tastatur i prinsippet kan opprette og publisere innhold uten å falle ut av flyten. I praksis avhenger det fortsatt av plugins som registrerer egne blokker, og av hvordan tredjepartstemaer overstyrer komponenter. Den realistiske vurderingen er: WordPress kjerne er en samarbeidspartner i tilgjengelighetsarbeidet, men WordPress-økosystemet er det ikke automatisk.

#Hvor WordPress feiler oftest

Når en norsk WordPress-side faller på en Digdir-test eller en intern revisjon, er det sjelden kjernen som skylder. Det er fem mønstre som går igjen.

For det første er det page builders. Visuelle byggere som genererer dyp DOM, mister overskriftshierarki, eller pakker knapper inn i div-elementer uten role-attributter, gir nesten alltid avvik på navigasjon, fokus og semantisk struktur. Mange av dem har egne tilgjengelighetsmoduser, men det krever at redaktøren vet hva de gjør.

For det andre er det slideshow- og karusellplugins. Auto-roterende karuseller som ikke kan stoppes, ikke kan tabuleres gjennom, og som mangler tekstbeskrivelse av aktivt slide, bryter med flere kriterier samtidig. WCAG 2.2 sin Pause Stop Hide-arv fra 2.1 er fortsatt en av de mest oversette i praksis.

For det tredje er det WooCommerce og e-handel. Ikoniske handle-, hjerte- og delingsknapper som er mindre enn 24 ganger 24 CSS-piksler, eller som kun har et ikon uten tekst og uten aria-label, faller direkte på Target Size Minimum og Name Role Value. Dette er den feilen vi finner oftest i norske nettbutikker.

For det fjerde er det skjemaer. Skjemaer uten label-for, skjemaer som rapporterer feil bare i farge, og skjemaer som ikke har et tilgjengelig sammendrag av valideringsresultatet, er den enkleste måten å falle på. Selv kjente plugins har historisk hatt avvik her, og det krever testing per skjema, ikke per plugin.

For det femte er det egenkodede modaler og overlay-bannere. En modal som ikke fanger fokuset, ikke har Escape-lukking, ikke restaurerer fokus til utløserelementet, og som dekker fokuset til underliggende elementer, er en av de mest klassiske defektene. WCAG 2.2 sitt Focus Not Obscured-kriterium gjør disse defektene mer synlige enn før.

#Forholdet mellom headless WordPress og tilgjengelighet

En vanlig misforståelse er at en headless arkitektur arver tilgjengelighet fra WordPress. Det stemmer ikke. I en headless oppsett bruker du WordPress som content-API, og leverer front-end gjennom et annet rammeverk, ofte Astro, Next.js, Nuxt eller en egen edge-tjeneste. Det betyr at temaet ditt på WordPress-siden er irrelevant for hva sluttbrukeren ser. Hele tilgjengelighetsarbeidet flyttes over til front-end-koden.

Det har to konsekvenser. Den første er at “accessibility-ready”-merket på WordPress.org ikke betyr noe for et headless-prosjekt. Den andre er at front-end-teamet må eie alle de ni nye WCAG 2.2-kriteriene direkte i komponentbiblioteket sitt. Knappekomponenten må selv håndheve minste klikkflate. Modal-komponenten må selv håndheve fokushåndtering. Karusellen, hvis den eksisterer, må selv ha tastaturkontroller og pause-knapp.

Det er en av grunnene til at vi pleier å si at headless WordPress er en teknisk vinning, men en disiplinert satsing. Den fjerner ikke ansvaret. Den flytter det.

#Hva vi gjør på WPPoland for norske kunder

For norske kunder kjører vi tilgjengelighet som en arbeidsstrøm, ikke som et engangsprosjekt. Det starter med å rydde i temaet, fordi et tema som ikke er accessibility-ready, koster mer å lappe enn å bytte ut. Det går videre til en pluginrevisjon, der vi går gjennom alle aktive plugins og dokumenterer hvilke som introduserer egne komponenter med tilgjengelighetsrisiko. Deretter setter vi opp en automatisert testkjede som kjører ved hver utrulling. Til slutt legger vi inn en årlig manuell revisjon med tastatur, skjermleser og forstørrelse.

Når kunden velger en headless arkitektur, peker vi på vår headless WordPress-pilar for hvordan tilgjengelighetsansvaret flyttes til front-end-laget, og vi bygger komponentbiblioteket med WCAG 2.2 som spesifikasjon, ikke som ettertanke. Den viktigste konsekvensen er at en redaktør på WordPress-siden ikke kan ødelegge tilgjengeligheten ved en uoppmerksom endring, fordi reglene er kodet i komponentene som rendrer innholdet.

#Audit-rytmen vi anbefaler

Det finnes ingen automatisert test som beviser at et nettsted er WCAG 2.2-konformt. De automatiserte verktøyene fanger en delmengde, anslagsvis halvparten av kriteriene i en god konfigurasjon, og resten må verifiseres manuelt. Den rytmen vi anbefaler ser slik ut:

• Ved hver build i CI: kjør axe-core eller pa11y mot kritiske maler. Bryt builden ved alvorlige feil, ikke ved varsler.
• Ved hver utgivelse: kjør et røyktest-skript som logger seg inn, navigerer kjernebrukerflyten med tastatur, og sjekker at fokus aldri forsvinner ut av synet.
• Hvert kvartal: kjør en målrettet manuell test på de mest besøkte malene, med en faktisk skjermleser, NVDA på Windows eller VoiceOver på macOS.
• Årlig: bestill eller utfør en full WCAG 2.2-revisjon med rapport, og oppdater tilgjengelighetserklæringen.

Tilgjengelighetserklæringen i seg selv er for øvrig en del av forpliktelsen. Norske virksomheter må publisere en erklæring som beskriver i hvilken grad nettstedet etterlever forskriften, hvilke avvik som finnes, og hvordan brukere kan rapportere problemer. Erklæringen er det første Digdir leter etter, og er ofte selve inngången til en tilsynssak.

#Hvor denne artikkelen passer inn

Dette stykket står i klyngen rundt regulatorisk WordPress for norske eiere. Den juridiske oversikten over EAA og BFSG i WordPress-sammenheng finner du i WCAG, BFSG og EAA på WordPress. For den bredere etterlevelsesrammen som også omfatter sikkerhet og operasjonell motstandsdyktighet, se NIS2 og DORA på WordPress. For ytelsessiden av tilgjengelighet, der edge-distribusjon og caching påvirker både Core Web Vitals og opplevd reaksjonstid for skjermleserbrukere, se Cloudflare Workers for WordPress og WooCommerce. For diskusjonen om hvem som faktisk leverer disse løsningene i Norden, se Polske senioringeniører som nordisk standard. På den engelskspråklige siden av nettstedet finner du den teknisk-redaksjonelle motparten i SEO patterns for headless WordPress, som er nyttig dersom front-end-laget ditt skal bære både tilgjengelighet og synlighet.

Den polemiske posisjonen vi avslutter med er denne: WCAG 2.2 er den tekniske terskelen. Den juridiske rammen i Norge er nasjonal. Hvis du argumenterer for at “EU sin EAA løser dette”, er du teknisk på feil hylle. Det er Likestillings- og diskrimineringsloven og Forskrift om universell utforming av IKT-løsninger som gjelder for nettstedet ditt, og det er Digdir som ringer. WordPress kan møte kravet helt fint i 2026, men ikke ut av esken. Det krever et tema som er bygget for det, en pluginpolitikk som rydder, og en redaksjonell rytme som ikke skyver tilgjengelighet til siste sprint.

#Europeiske lovkrav til digital tilgjengelighet (European Accessibility Act)

Med innføringen av European Accessibility Act (EAA) har kravene til universell utforming gått fra å være en anbefaling til et ufravikelig lovkrav for næringslivet:

• Obligatorisk tilgjengelighet for nettbutikker og digitale tjenester: Bedrifter som selger varer eller tjenester til forbrukere innenfor EØS-området plikter å sikre at hele kjøpsprosessen – fra produktvisning og filtervalg til betaling og ordrebekreftelse – kan betjenes av personer med nedsatt funksjonsevne.
• Tekniske krav under WCAG 2.2: De nyeste kriteriene krever blant annet tilstrekkelig trykkflate for interaktive elementer på berøringsskjermer (minimum 24x24 piksler), tydelig fokusmarkering for tastaturnavigasjon og fravær av tidsbegrensninger som hindrer kognitivt tilpasset navigasjon.
• Automatiserte og manuelle revisjonsmetoder: Selv om automatiserte testverktøy (som axe-core og Lighthouse) er nyttige for å fange opp opplagte kontrastfeil, avdekker de bare rundt 30-40 prosent av tilgjengelighetsbarrierene. Regelmessige brukertester med skjermlesere (som NVDA og VoiceOver) er nødvendig for å garantere full samsvar og unngå kostbare sanksjoner.
• Konklusjon: Å prioritere universell utforming handler ikke bare om å unngå bøter, men om å åpne nettstedet for alle brukere, noe som direkte øker konverteringen og styrker virksomhetens omdømme i markedet.

#Praktisk implementering av tilgjengelighetsforbedringer i WordPress

For å oppnå full samsvar med kravene i WCAG 2.2 på en WordPress-nettside, må utviklere følge konkrete retningslinjer:

• Semantisk HTML5-struktur og ARIA-landemerker: Bruk korrekte tagger som <header>, <nav>, <main> og <footer> i stedet for generiske div-elementer. Sørg for at skjermlesere enkelt kan hoppe direkte til hovedinnholdet ved hjelp av en synlig „Hopp til innhold”-lenke øverst på siden.
• Fokusstyring i modaler og menyer: Når en mobilmeny eller et popup-vindu åpnes, må tastaturfokuset låses inne i elementet (focus trap) og returneres til den opprinnelige knappen når vinduet lukkes med Escape-tasten.
• Kontrast og dynamisk tekststørrelse: Tekst må ha et kontrastforhold på minst 4,5:1 mot bakgrunnen (3:1 for stor tekst), og layouten må tåle opptil 200 % tekstforstørrelse i nettleseren uten at innholdet overlapper eller skjæres av.
• Skjemaoptimalisering og feilmeldinger: Alle skjemafelter må ha tydelige <label>-elementer koblet sammen med for-attributter, og feilmeldinger må beskrives presist med forslag til hvordan brukeren kan rette feilen.
• Oppsummering: Tilgjengelighet er en kontinuerlig prosess som forbedrer brukeropplevelsen for alle besøkende, reduserer juridisk risiko og sikrer at bedriftens digitale tjenester forblir inkluderende og fremtidsrettede.

#Sjekkliste for kontinuerlig tilgjengelighetskontroll

Universell utforming krever faste rutiner gjennom hele nettstedets levetid:

• Faste automatiske skanninger i CI/CD-rørledningen: Integrer automatiserte tilgjengelighetstester i byggeprosessene, slik at nye kildekode-endringer eller komponenter som bryter WCAG-krav blokkeres før de når produksjonsserveren.
• Opplæring av innholdsprodusenter: Redaktører må instrueres i å alltid skrive meningsfulle alt-tekster som beskriver bildenes faktiske funksjon, bruke beskrivende lenketekster i stedet for intetsigende „klikk her”-fraser, og unngå å formidle viktig informasjon utelukkende gjennom farger.
• Regelmessig revisjon av tredjepartsutvidelser: Mange tilgjengelighetsfeil oppstår fra dårlig kodede kontaktskjemaer, bildegallerier eller popup-løsninger fra tredjepartsutviklere. Grundig evaluering av alle installerte plugins er avgjørende for å opprettholde et feilfritt nivå.
• Sluttkonklusjon: Å investere i universell utforming er den beste måten å sikre likeverdig tilgang for alle, samtidig som det styrker nettstedets autoritet og synlighet i moderne søkemotorer. Universell utforming er et etisk samfunnsansvar som samtidig gir målbar forretningsmessig verdi. Nettsteder som er bygget for alle, opplever høyere engasjement, bedre søkerangeringer og mer fornøyde brukere. Å satse på kvalitet og inkludering er den beste investeringen for en bærekraftig digital fremtid. Grundig metodikk og kontinuerlig forbedring sikrer at alle løsninger opprettholder høyeste standard over tid. Profesjonalitet i utviklingen gir varig trygghet for virksomheten. Tilgjengelighet for alle er fremtidens standard.