Tilgjengelighetserklæring for WordPress: mal + EN-301-549-kartlegging

#Tilgjengelighetserklæring for WordPress: mal + EN-301-549-kartlegging

En tilgjengelighetserklæring er et eget leveranse, forskjellig fra en WCAG-revisjon. Du kan bestå hver automatisert skanning på en WordPress-nettside og likevel ikke være i samsvar med regelverket, fordi det som kreves er erklæringen selv: en publisert samsvarsstatus, standarden det er testet mot, en liste over kjente begrensninger og en fungerende tilbakemeldingsmekanisme en besøkende kan bruke for å sende en klage. Denne artikkelen er et støttestykke i samsvarsstakken for WCAG 2.2, BFSG og EU-regelverket om tilgjengelighet, med fokus spesifikt på erklæringsdokumentet og hvordan avsnittene kartlegges mot EN 301 549 - den europeiske standarden innkjøpsteam faktisk siterer.

#Hva du må publisere, kort fortalt

• En egen side lenket fra footeren, ikke et avsnitt inne i personvernerklæringen.
• En samsvarsstatus: full, delvis med navngitte unntak, eller ikke i samsvar.
• Standarden det er testet mot: i praksis WCAG 2.2 AA, referert mot EN 301 549 for innkjøpsmålgrupper.
• En liste over kjente begrensninger med, der mulig, en utbedringsdato.
• En kontaktinformasjon som faktisk når en overvåket innboks, pluss en klage- eller eskaleringsvei.
• En utarbeidelsesdato og en gjennomgangsrytme, fordi “vi testet dette én gang i 2023” ikke er en aktuell erklæring.

Ingenting av dette erstatter en teknisk revisjon. Det dokumenterer resultatet av en. Hvis du ikke har gjennomført en WCAG 2.2 AA-revisjon ennå, vil erklæringen enten overdrive samsvaret eller virke som en plassholder, og begge utfallene trekker mer oppmerksomhet enn å ikke ha noen erklæring i det hele tatt.

#Når en tilgjengelighetserklæring er obligatorisk

To overlappende rettsgrunnlag setter en tilgjengelighetserklæring på forpliktelseslisten til en norsk WordPress-operatør, og de retter seg ikke mot samme målgruppe.

Forskrift om universell utforming av IKT-løsninger (FOR-2013-06-21-732), den norske IKT-forskriften, har krevd universell utforming av nettløsninger og automater for offentlig sektor siden 1. juli 2014, og etter endringene i 2022, som gjennomfører EUs webdirektiv (WAD, direktiv 2016/2102) i EØS, også for deler av privat sektor. Forskriften viser til EN 301 549 v3.2.1, som i praksis betyr WCAG 2.1 AA. Tilsynet for universell utforming av IKT (Uu-tilsynet) forvalter regelverket og fører tilsyn.

Den europeiske tilgjengelighetsloven (EAA, direktiv 2019/882), som gjelder i EU fra 2025-06-28, utvider sammenlignbare forpliktelser til private operatører innen bestemte produkt- og tjenestekategorier: e-handel, banktjenester, transport, e-bøker og andre nevnt i direktivets bilag I. Per i dag er EAA fortsatt ikke tatt inn i EØS-avtalen, og gjennomføringen i Norge er forsinket uten en klar dato. Det betyr at norske virksomheter som opererer utelukkende innenlands ikke er direkte bundet av EAA ennå - men en norsk nettbutikk som selger til forbrukere i EU-land må oppfylle EAA-kravene, inkludert en publisert erklæring, i de markedene fra 28. juni 2025, uavhengig av status i norsk rett.

Nasjonale gjennomføringer fyller inn de operative detaljene. Under den norske IKT-forskriften ligger likestillings- og diskrimineringsloven av 2017 som et generelt bakteppe, og Uu-tilsynet publiserer egne veiledere for hvordan en tilgjengelighetserklæring etter forskriften skal se ut. I praksis betyr dette at en publisert erklæring er den enkleste måten å vise at en klageprosess eksisterer, før noen klage faktisk kommer inn - uavhengig av om EAA formelt er tatt inn i EØS-avtalen ennå.

Unntakene som er verdt å kjenne før du skriver noe: mikroforetak (under 10 ansatte, årlig omsetning eller balansesum under 2 mill. EUR) er unntatt fra flere av EAAs tjenesteforpliktelser, selv om unntaket er smalere for produktprodusenter. Offentlige virksomheter i Norge har ikke noe størrelsesunntak etter IKT-forskriften. Krav om uforholdsmessig belastning finnes i begge regimer, men krever en dokumentert vurdering, ikke en fotnote som sier “ikke relevant”.

Pillar-artikkelen om WCAG 2.2, BFSG og EU-regelverket om tilgjengelighet dekker hele samsvarsstakken, inkludert revisjonsrytmen som produserer samsvarsstatusen som dokumenteres i denne erklæringen.

#EN 301 549 vs. WCAG 2.2 AA: hva innkjøpere faktisk ber om

WCAG 2.2 AA er det utviklingsteamet ditt tester mot. EN 301 549 er det en innkjøper, et anbudsdokument eller en revisjon av offentlig sektor siterer, fordi det er den harmoniserte europeiske standarden for IKT-tilgjengelighet bredt, ikke bare webinnhold.

Versjonen som gjelder i dag er EN 301 549 v3.2.1, publisert i mars 2021. Den norske IKT-forskriften viser direkte til denne versjonen. Webkapittelet, kapittel 9, inkorporerer suksesskriteriene for WCAG 2.1 nivå A og AA ved referanse. En revisjon som inkorporerer WCAG 2.2 er under utarbeidelse i den felles ETSI/CEN/CENELEC-fagkomiteen, med forventet publisering i 2026 under Europakommisjonens standardiseringsmandat M/587, men det er ennå ikke den versjonen som er sitert i regelverket.

Dette skaper et praktisk gap som anbudsdokumenter sjelden løser tydelig: det juridisk refererte grunnlaget er WCAG 2.1 AA, mens dagens beste praksis-mål, og det de fleste byråer (inkludert oss) faktisk bygger etter, er WCAG 2.2 AA. Fordi 2.2 er en streng overmengde av 2.1 med ni tilleggskriterier, tilfredsstiller testing og dokumentasjon mot 2.2 AA også 2.1-AA-grunnlaget EN 301 549 viser til i dag. Det er ingen versjonsmismatch-risiko ved å bygge mot den nyere standarden; risikoen går den andre veien, hvis man bare bygger mot 2.1 og EN-301-549-revisjonen publiseres midt i en kontrakt.

Utover webkapittelet har EN 301 549 elleve andre kapitler. De tre som er mest relevante for et typisk WordPress-oppsett utover selve webinnholdet:

• Kapittel 10, ikke-web-dokumenter. PDF-er, regneark og presentasjoner publisert gjennom nettstedet (prislister, årsrapporter, anbudsdokumenter) trenger riktig tagging, leserekkefølge og tilgjengelige tabeller, uavhengig av hvor tilgjengelig selve den omgivende siden er.
• Kapittel 11, programvare. Relevant når selve WordPress-administrasjonen er produktet som vurderes, for eksempel et redaksjonelt team i offentlig sektor som bruker blokkredigereren som forfatterverktøy, eller et tilpasset plugin som eksponerer et formulargrensesnitt for sluttbrukere.
• Kapittel 12, dokumentasjon og støttetjenester. Hjelpesider, onboardingsguider og støttekanaler lenket fra nettstedet forventes å møte samme tilgjengelighetsnivå som hovedinnholdet, og selve støttekommunikasjonen må være tilgjengelig gjennom mer enn én kanal.

#Malavsnitt med kopieringsklare overskrifter

Avsnittsrekkefølgen under er strukturen som går igjen i de fleste tilgjengelighetserklæringer bygget på EN-301-549-/EAA-/IKT-forskrift-rammeverket. Den er illustrativ: fyll den med dine faktiske revisjonsresultater, ikke plassholdertekst, og få den godkjent av den som har ansvar for compliance-godkjenning i din organisasjon før du publiserer.

# Tilgjengelighetserklæring for [nettstedets navn]

## Samsvarsstatus
[Nettstedets navn] er [fullt i samsvar / delvis i samsvar / ikke i
samsvar] med WCAG 2.2 nivå AA, vurdert mot kravene referert i EN 301 549.
[Velg ett:]
- Fullt i samsvar betyr at innholdet fullt ut oppfyller standarden uten
  unntak.
- Delvis i samsvar betyr at enkelte deler av innholdet ikke fullt ut
  oppfyller standarden, listet under "kjente begrensninger" nedenfor.

## Gjeldende standard
Denne erklæringen er basert på en egenvurdering / en vurdering utført av
[navn eller rolle på vurderer] den [dato], mot:
- Web Content Accessibility Guidelines (WCAG) 2.2, nivå AA
- EN 301 549, [versjon], kapittel 9 (Web)
[List kapittel 10, 11, 12 her bare hvis ikke-web-dokumenter, programvare
eller støttetjenester også ble vurdert.]

## Kjente begrensninger
Følgende innhold er ikke ennå fullt tilgjengelig:
- [Konkret begrensning, f.eks. "det innebygde bestillingswidgetet på
  /kontakt/ kan ikke brukes med tastatur alene"], som påvirker [hvilket
  suksesskriterium], utbedringsmål: [dato eller "under vurdering"].
- [Gjenta for hvert kjent problem. Oppsummer ikke flere problemer i én
  vag linje; list dem individuelt.]

## Utarbeidelse av denne erklæringen
Denne erklæringen ble utarbeidet [dato] og sist gjennomgått [dato]. Den
ble utarbeidet basert på [egenvurdering / tredjepartsrevisjon], og dekker
[omfang: f.eks. "de offentlige sidene under example.com, unntatt
innebygd tredjepartsinnhold"].

## Tilbakemelding og kontaktinformasjon
Hvis du opplever en tilgjengelighetsbarriere på dette nettstedet,
kontakt oss:
- E-post: [overvåket adresse]
- [Valgfritt: telefon, URL til kontaktformular]
Vi tar sikte på å svare innen [X] virkedager.

## Klagebehandlingsprosedyre
Hvis du ikke er fornøyd med svaret vårt, kan du eskalere til:
[Nasjonalt tilsyns- eller tvisteløsningsorgan, med URL, relevant for
jurisdiksjonen operatøren er etablert i eller betjener.]

## Tekniske spesifikasjoner
Dette nettstedet er avhengig av følgende teknologier for samsvar:
HTML, CSS, JavaScript, WAI-ARIA.

To avsnitt fortjener mer omtanke enn en generisk mal kan gi dem. Kjente begrensninger er avsnittet flest erklæringer gjør feil, enten ved å utelate det helt (hevde fullt samsvar mens en automatisert skanning viser feil) eller ved å skrive det så vagt at det ikke gir noe bevis på en faktisk vurdering. Klagebehandlingsprosedyre trenger et reelt mål, ikke “kontakt din nasjonale myndighet”, fordi poenget med avsnittet er at en utilfreds besøkende kan handle på det uten ytterligere research.

#Kartleggingstabell: EN-301-549-krav til WordPress-implementering

Kapittel 4 i EN 301 549 setter opp funksjonelle ytelsespåstander (bruk uten syn, bruk med begrenset manuell fingerferdighet og lignende) som brukes når et bestemt suksesskriterium ikke kartlegger seg rent mot et nytt grensesnitt. For et standard WordPress-frontend skjer mest av kartleggingsarbeidet i kapittel 9, 10, 11 og 12.

Denne tabellen er ryggraden i en VPAT-lignende samsvarsrapport hvis en kunde i offentlig sektor ber om det; hver rad blir en linje med status bestått, delvis eller ikke bestått når revisjonen din er kjørt.

#Hvor erklæringen skal publiseres på WordPress: footer, egen side, schema

Footer-lenke, på hver side. Det mest sjekkede signalet i en tilsynsgjennomgang er om erklæringen er tilgjengelig fra hvor som helst på nettstedet uten å søke. En footer-lenke, ved siden av personvernerklæring og vilkår, dekker dette uten ekstra utviklingsarbeid. Hvis footeren i temaet ditt forvaltes gjennom et widgetområde eller en global footer-malfil, legg lenken der én gang, ikke per side.

Egen side, egen URL. Fold ikke erklæringen inn i personvernerklæringen eller vilkårene. Gi den en egen URL, som /tilgjengelighetserklaering/, satt opp gjennom en vanlig WordPress-side (eller en MDX-innholdsoppføring, i denne stacken), slik at den kan gjennomgås og versjoneres uavhengig av annet juridisk innhold.

Strukturerte data, valgfritt men nyttig for innkjøpsrevisjoner. En WebPage-JSON-LD-blokk på erklæringssiden, med sidens dateModified som samsvarer med din siste gjennomgangsdato, gir en automatisert crawler eller et innkjøpssjekkliste-verktøy en maskinlesbar bekreftelse på at erklæringen finnes og når den sist ble oppdatert. Dette erstatter ikke det menneskelesbare innholdet; det er et lite tillegg som fjerner tvil når noen kjører en automatisert samsvarsskanning mot domenet ditt.

Gjennomgangsrytme, dokumentert i erklæringen selv. Angi hvor ofte erklæringen gjennomgås (årlig, eller etter en større redesign) og hold deg til rytmen. En erklæring datert tre år tilbake, med et “sist gjennomgått”-felt ingen har rørt, er en av de første tingene en revisor eller en konkurrents juridiske team vil flagge.

#Klage- og tilbakemeldingsprosess

Tilbakemeldingsmekanismen er delen av regelverket en ren frontend-revisjon ikke kan oppfylle, fordi det er et prosesskrav, ikke et kodekrav.

1. Mottak. En overvåket e-postadresse eller et kontaktformular, atskilt fra generell support, slik at tilgjengelighetsklager ikke går tapt i en generisk kø. Rut den til den som eier compliance, ikke bare webmasteren.
2. Bekreftelse. Bekreft mottak innen et angitt tidsvindu (vanligvis noen få virkedager). Bekreftelsen bør gjenta den rapporterte barrieren slik at den besøkende vet at den er riktig forstått.
3. Undersøkelse. Reproduser barrieren, sjekk den mot det relevante WCAG-suksesskriteriet, og dokumenter funnet, uansett om det bekrefter en kjent begrensning som allerede står i erklæringen eller avdekker en ny.
4. Svar og utbedringsplan. Fortell den besøkende hva som ble funnet og, hvis det er en reell barriere, når den blir rettet eller hvorfor det ikke kan skje (uforholdsmessig belastning, tredjepartsinnhold utenfor din kontroll og lignende, dokumentert i stedet for bare påstått).
5. Eskaleringsvei. Hvis den besøkende ikke er fornøyd, vis dem til det relevante tilsyns- eller tvisteløsningsorganet. I Norge er det Tilsynet for universell utforming av IKT for IKT-forskriften; for EAA-relaterte klager i EU-markeder utpeker andre medlemsstater sine egne markedstilsyn.
6. Intern loggføring. Hold et register over hver mottatt klage og løsningen. Dette registeret er det som gjør “vi har en prosess” fra en påstand i erklæringen til et bevis under en revisjon eller en tilsynshenvendelse.

Ingen av disse trinnene krever ny programvare. En delt innboks, et enkelt regneark eller en ticket-tag, og en navngitt eier dekker kravet for de fleste WordPress-operatører. Det som betyr noe, er at prosessen er dokumentert i erklæringen og faktisk følges når en klage kommer, ikke oppfunnet i etterkant etter at en har kommet.

#Hvordan dette passer inn i EU-samsvarsrevisjonen

En tilgjengelighetserklæring er en av flere leveranser innenfor en bredere EU-samsvarsrevisjon for WordPress, som også dekker NIS2/DORA-leverandørkartlegging og AI Act-innholdsmerkingsforpliktelser der det er relevant. Innenfor tilgjengelighetsdelen av denne revisjonen er erklæringen leveransen som gjør en teknisk WCAG-2.2-AA-rapport til noe en compliance-ansvarlig, en innkjøper i offentlig sektor, eller et tilsynsorgan kan handle på uten å lese det underliggende skanneresultatet.

Sekvensen som produserer en forsvarlig erklæring, i den rekkefølgen vi kjører den:

1. Teknisk WCAG-2.2-AA-revisjon, automatisert pluss manuell, over det representative sideutvalget beskrevet i WCAG/BFSG/EAA-samsvarsstakken.
2. Gapliste knyttet til konkrete suksesskriterier, ikke et generisk “noen problemer funnet”-sammendrag, fordi erklæringens avsnitt om kjente begrensninger trenger konkrete, navngitte punkter.
3. Utkast til erklæring ved bruk av avsnittsstrukturen over, fylt med det faktiske revisjonsresultatet i stedet for en plassholder-samsvarspåstand.
4. Oppsett av tilbakemeldingsprosess, koblet til en reell innboks og en navngitt eier, testet med en dummy-klage før publisering.
5. Publisering, lenket fra footeren, på egen URL, med en gjennomgangsdato satt for neste syklus.

Hvis du kjører dette som del av et bredere EAA/WCAG-beredskapsprosjekt, er oversikten over den europeiske tilgjengelighetsloven og WCAG inngangspunktet for spørsmål om omfang (hvem er unntatt, hva betyr “lagt ut på markedet” for en tjenesteavtale), mens denne artikkelen dekker selve erklæringsdokumentet spesifikt, når den underliggende revisjonen er gjort.

#Videre lesning i klyngen

• Pillar: WCAG 2.2, BFSG og EU-regelverket om tilgjengelighet: samsvarsstakken 2026 for WordPress
• Europeisk tilgjengelighetslov og WCAG 2.1: hvordan implementere digital tilgjengelighet
• EU-samsvarsrevisjon for WordPress: tilgjengelighet, NIS2/DORA, AI Act