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 tema 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 gjort 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 inngangen 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.
