Hva EAA og WCAG 2.1 betyr for WordPress-nettsteder
Siden 28. juni 2025 har den europeiske tilgjengelighetsloven (EAA, direktiv 2019/882) gjeldt for produkter og tjenester som legges ut på EU-markedet for første gang. For en nettside eller en webapplikasjon betyr det å oppfylle WCAG 2.1 AA, en W3C-standard som definerer hvordan digitalt innhold skal være oppfattbart, anvendelig, forståelig og robust. EAA spesifiserer ikke suksesskriteriene i WCAG selv; direktivet viser til den europeiske harmoniserte standarden EN 301 549, som i dag inkorporerer WCAG 2.1 nivå AA. WCAG 2.2 er nå den gjeldende W3C-anbefalingen, men den juridiske gulvet de fleste nettsteder i EU må forholde seg til i dag, er fortsatt 2.1 AA - noe som er nettopp grunnen til at det er verdt å forstå standarden på egne premisser før man går videre.
For norske lesere er det en viktig presisering nødvendig helt fra start: per i dag er EAA ikke tatt inn i EØS-avtalen, og direktivet er derfor ikke en del av norsk rett. Uu-tilsynet, det norske tilsynet for universell utforming av IKT, bekrefter at gjennomføringen i Norge, Island og Liechtenstein er forsinket, uten en klar dato for når EAA blir en del av EØS-avtalen. Det betyr likevel ikke at norske virksomheter kan ignorere loven: en norsk nettbutikk som selger til forbrukere i EU-land må følge EAA-kravene i de markedene fra 28. juni 2025, uavhengig av at loven ennå ikke gjelder innenlands i Norge. Og innenlands har Norge allerede et regelverk som i praksis dekker mye av samme grunn: forskrift om universell utforming av IKT-løsninger (FOR-2013-06-21-732), som har krevd WCAG 2.1-etterlevelse for offentlig sektor siden 2014 og for større private virksomheter gjennom senere endringer.
Denne artikkelen er inngangspunktet. Den beskriver hvem som faktisk er omfattet, hvilke unntak som holder og hvilke som ikke gjør det, hvordan WCAG 2.1 AA ser ut på et reelt WordPress-prosjekt, og hvor man går videre. Les mer om WordPress-utviklingstjenester hos WPPoland hvis du trenger et team som bygger tilgjengelige løsninger, ikke bare reviderer dem.
To tall forklarer hvorfor dette ikke er en nisjebekymring. Rundt 15 prosent av EUs befolkning lever med en form for funksjonsnedsettelse, og en mye større andel har nytte av tilgjengelighet situasjonsbetinget: eldre brukere, noen med en midlertidig skade, alle som leser på en liten skjerm i sterkt sollys. Tilgjengelighetsarbeid overlapper også kraftig med grunnleggende SEO - semantisk struktur, beskrivende alt-tekst og ren markup hjelper søkemotorer og AI-svarmotorer like mye som de hjelper hjelpemiddelteknologi. Begge disse trådene går gjennom resten av denne guiden.
Viktige datoer og hvem som er omfattet
Ikrafttredelsesdatoen for EAA er fast, men “omfattet” er ikke et enkelt ja/nei-svar - det avhenger av produkt- eller tjenestekategori, kontraktsdato og hvilken type kunde som betjenes. Tabellen under er det praktiske sammendraget; juridiske nyanser i grensetilfeller hører hjemme hos en advokat, ikke et blogginnlegg.
| Frist | Hva den omfatter | B2C- vs. B2B-nyanse |
|---|---|---|
| 2025-06-28 | EAAs tilgjengelighetskrav gjelder produkter og tjenester som legges ut på EU-markedet for første gang: e-handel, forbrukerbank, e-bøker, elektronisk kommunikasjon, tilgangstjenester til audiovisuelle medietjenester og grensesnitt for persontransport (bilag I) | E-handelskategorien er definert rundt en forbrukeravtale (artikkel 3(30)); andre kategorier som bank og elektronisk kommunikasjon har ikke samme begrensning til forbrukere |
| 2025-06-28 til 2030-06-28 | Overgangsvindu: tjenesteavtaler inngått før 2025-06-28 kan fortsette på opprinnelige vilkår til senest denne datoen | Gjelder uavhengig av kundetype - det avgjørende er kontraktsdatoen, ikke om kjøperen er forbruker eller virksomhet |
| Installasjonsdato + opptil 20 år | Selvbetjeningsterminaler (bankautomater, billettautomater, innsjekkingskiosker) installert før fristen kan brukes til slutten av sin brukstid, maksimalt 20 år | I hovedsak et hardware-poeng for fysiske terminaler; sjelden relevant for et rent WordPress-prosjekt, med mindre det styrer en kiosk i en fysisk butikk |
| Løpende, per regnskapsår | Ny vurdering av mikroforetak: hvis en tjenesteyters antall ansatte eller omsetning overstiger terskelen i artikkel 4(5), opphører unntaket fra det regnskapsåret | Gjelder kun tjenesteytere - produktforpliktelser har aldri vært dekket av dette unntaket, uansett størrelse |
| Nasjonale gjennomføringsdatoer | De fleste EU-medlemsstater gjennomførte direktivet nær EU-datoen; Norge og de andre EØS-landene ligger derimot etter, og det er fortsatt uklart når EAA blir en del av EØS-avtalen og norsk rett | Gjelder for markedet produktet eller tjenesten legges ut på, ikke operatørens etableringsland |
Den praktiske lesningen: hvis en WordPress-nettside selger til forbrukere i EU, driver en WooCommerce-kasse, eller tilbyr en tjeneste i en av bilag I-kategoriene inn i et EU-marked, er fristen allerede forbi og forpliktelsen er aktiv nå - ikke noe å planlegge for “en gang senere”.
Unntak og avgrensning for mikroforetak
Dette er avsnittet som oftest blir lest feil. “Vi er små, så vi er unntatt” er en vanlig antagelse, og den er oftere feil enn riktig. Direktiv 2019/882 definerer flere smale unntak, ikke et generelt fritak for små virksomheter.
| Unntak | Hvem kan bruke det | Vilkår | Hva det IKKE dekker |
|---|---|---|---|
| Mikroforetaksunntaket (artikkel 4(5)) | Foretak med under 10 ansatte OG årlig omsetning eller balansesum under 2 mill. EUR | Begge vilkår må være oppfylt samtidig; unntaket opphører det regnskapsåret én av tersklene overskrides | Unntar kun tjenester. Forpliktelser knyttet til produksjon, import eller distribusjon av produkter gjelder uavhengig av foretaksstørrelse |
| Uforholdsmessig belastning (artikkel 14, bilag VI) | Enhver økonomisk aktør, uansett størrelse | Krever en dokumentert vurdering mot kriteriene i bilag VI, som vekter kostnad mot nytte for brukerne; må fornyes minst hvert femte år og fremlegges for myndighetene på forespørsel | Ikke et generelt fritak - operatøren må fortsatt oppfylle alle krav som ikke er vist å være uforholdsmessige |
| Grunnleggende endring (artikkel 14) | Enhver økonomisk aktør, uansett størrelse | Gjelder kun der det å oppfylle et krav ville grunnleggende endret produktets eller tjenestens natur | Sjelden relevant for typiske WordPress-funksjoner (navigasjon, formularer, innhold); mer relevant for spesialisert hardware eller skreddersydd programvare |
| Eksisterende tjenesteavtaler (artikkel 32) | Uansett størrelse | Tjenesteavtaler inngått før 2025-06-28 kan fortsette på opprinnelige vilkår til senest 2030-06-28 | Gjelder ikke nye avtaler signert etter fristen, selv med en eksisterende kunde |
| Selvbetjeningsterminaler i bruk (artikkel 32) | Uansett størrelse, typisk hardware-operatører | Terminaler installert før fristen kan fortsette til slutten av brukstiden, maksimalt 20 år | Gjelder ikke nye terminaler kjøpt eller installert etter fristen |
| Forhåndsinnspilt medie publisert før 28. juni 2025 (artikkel 2(4)) | Uansett størrelse | Tidsbaserte medier (lyd/video) publisert før fristen er unntatt med tilbakevirkende kraft | Nye tidsbaserte medier publisert etter fristen må oppfylle kravene fra dag én |
En reell avgrensningssak, gjennomarbeidet steg for steg. Ta en WooCommerce-butikk med fire ansatte og omsetning godt under 2 mill. EUR, som selger direkte til forbrukere i et EU-marked. Etter artikkel 4(5) er dette et mikroforetak innen tjenester, så tilgjengelighetsforpliktelsene for selve handle- og kasse-tjenesten gjelder ikke for den. Unntaket opphører i det øyeblikket butikken ansetter nummer fem til ti og går over ti ansatte, eller omsetningen overstiger 2 mill. EUR - direktivet selv har ingen overgangsperiode innebygd, så den tryggeste planleggingsforutsetningen er å tape unntaket fra det regnskapsåret terskelen overskrides, ikke fra en senere fornyelsesdato.
Endre nå ett faktum: samme fireperson-butikk, men den opererer som grossist under en forhandlet avtale med et større selskap, uten noen direkte forbrukerkasse i det hele tatt. Da skjer det to separate ting, ikke ett. Først er e-handelskategorien i EAA definert rundt det å inngå en forbrukeravtale (artikkel 3(30), fortalens punkt 42) - en ren B2B-salgskanal kan stå utenfor denne kategorien alene av den grunn, uavhengig av mikroforetaksunntaket. For det andre, og dette er delen som ofte snubler folk: å stå utenfor EAAs egen e-handelsforpliktelse betyr ikke at butikken er fri fra tilgjengelighetskrav i den relasjonen. Hvis den større kjøperen selv er underlagt EAA, NIS2 eller anbudsklausuler om tilgjengelighet, kan dennes eget compliance-program kontraktuelt kreve WCAG-konforme leverandørverktøy, uavhengig av om leverandøren er et mikroforetak eller står utenfor e-handelskategorien i EU-retten. EAA-unntaket beskytter mot håndhevingen av EAA selv; det gjør ingenting mot en kundes kontraktsmessige tilgjengelighetsklausul.
Dette er en faktabeskrivelse, ikke juridisk rådgivning - hvis en konkret klassifisering er omtvistet, eller omsetningstallene ligger nær terskelen, bør det bekreftes med jurist før man baserer seg på et unntak i en offentlig erklæring eller et anbudssvar.
WCAG 2.1 AA i praksis på WordPress
WCAG 2.1 AA er ikke en sjekkliste man krysser av én gang; det er et sett testbare suksesskriterier som enten er oppfylt eller ikke på en gitt side, et formular eller en komponent. Fire områder står for det meste av det praktiske arbeidet på et WordPress-nettsted.
Tastaturbetjening. Hvert interaktivt element - meny, nedtrekksmeny, modal, karusellstyring, legg-i-kurv-knapp - må kunne nås og betjenes med kun Tab, Shift+Tab, Enter og piltastene, med en synlig fokusindikator ved hvert steg. Dette er der page builders og slider-plugins svikter oftest: et lysbildeshow som bare går videre ved musehover, eller en mega-meny som åpnes ved hover, men aldri ved fokus, stenger stilltiende ute alle som ikke kan bruke mus. Løsningen er sjelden en omskriving; det er vanligvis å legge til de manglende keyboard-event-handlerne og en synlig :focus-stil med tilstrekkelig kontrast.
Fargekontrast. WCAG 2.1 AA krever et kontrastforhold på minst 4,5:1 for normal tekst og 3:1 for stor tekst mot bakgrunnen. Merkevarepaletter bygget for en logo, ikke for løpetekst, er den vanligste feilen: en lys grå på hvitt som ser elegant ut i en mockup, men som ikke oppfyller forholdet for noen med nedsatt syn. Kontrastfeil er billige å rette når de er avdekket, og kostbare å la stå, fordi de påvirker hver side som arver temaets typografiinnstillinger.
Formularer. Hvert inndatafelt trenger en programmatisk tilknyttet etikett (<label for="id">, ikke bare en placeholder-tekst som forsvinner ved fokus), hvert obligatoriske felt må varsle at det er obligatorisk, og hver valideringsfeil må beskrives i tekst nær feltet, ikke bare formidles gjennom en rød ramme. Kasse- og kontaktformularer er de høyest-innsats-flatene her, fordi et formular en skjermleser-bruker ikke kan fullføre, er en tapt transaksjon, ikke bare et etterlevelsesgap.
Medier. Video trenger undertekster, lyd trenger transkripsjon, og hvert meningsbærende bilde trenger alt-tekst som beskriver funksjonen eller innholdet, i stedet for å gjenta filnavnet. Dekorative bilder (bakgrunnstekstur, mellomrom) bør ha en tom alt="", slik at hjelpemiddelteknologi hopper over dem i stedet for å annonsere støy. Dette er et av områdene der redaksjonell disiplin betyr like mye som kode: en utvikler kan bygge en tilgjengelig bildekomponent, men bare en opplært redaktør holder hver nye opplasting etterlevende.
Vanlige WordPress-feilmønstre vi ser i revisjoner
Noen mønstre går igjen i nesten hver WordPress-revisjon vi utfører, uavhengig av tema eller nisje. Overskriftshierarkiet brekker først: page builders sender ofte ut en <h1> eller <h2> for hero-teksten i hver seksjon, uavhengig av dens faktiske plass i dokumentstrukturen, så en side kan ha fem h1-tagger og ingen logisk h2/h3-nesting under dem. Skjermleser-brukere navigerer etter overskriftsstruktur; en brutt struktur gjør siden langt vanskeligere å skanne enn seende brukere noensinne vil merke.
Rene ikonkontroller kommer neste - en legg-i-kurv- eller søkeknapp gjengitt som et bart ikon uten synlig tekst og, ofte, uten aria-label heller, gir hjelpemiddelteknologi ingenting å annonsere. Automatisk roterende karuseller er en tett tredje: ingen pause-kontroll, ingen tastaturnavigasjon, og innhold som endres hvert fjerde sekund uavhengig av om leseren har lest ferdig gjeldende lysbilde.
Det fjerde mønsteret er stillere, men like betydningsfullt: cookie-samtykkebannere og nyhetsbrevmodaler som fanger tastaturfokuset. En bruker tabber inn i modalen og kan aldri tabbe seg tilbake til sideinnholdet, fordi utvikleren aldri koblet inn en fokusfelle som slippes ved Escape eller en lukkehandling. Det er usynlig i en musedrevet QA-gjennomgang og umiddelbart tydelig første gang noen tester med bare tastatur.
Ingen av disse er eksotiske feil. De er det direkte, repeterbare resultatet av populære plugins og temaer brukt på den måten de fleste nettsteder bruker dem - og nettopp derfor finner en revisjon de samme håndfulle mønstrene på tvers av urelaterte prosjekter. Artikkelen om samsvarsstakken 2026 går gjennom feillisten plugin for plugin - page builders, WooCommerce-maler, slider-plugins, formular-plugins - med det spesifikke WCAG-suksesskriteriet hver av dem bryter og den konkrete løsningen for hver.
Implementeringsvei: revisjon, utbedring, erklæring, overvåking
Å gjøre “vi må bli etterlevende” til et levert, forsvarbart resultat følger den samme fire-trinns veien i hvert prosjekt vi kjører.
Revisjon. Start med en avgrenset gjennomgang av WCAG 2.1 AA mot nettstedets faktiske kundereiser - forside, navigasjon, søk, formularer og hvert inntektskritiske kassesteg - ikke bare en automatisert skanning av forsiden. Automatiserte verktøy (axe-core, Lighthouse, WAVE) fanger opp om lag halvparten av de reelle problemene; resten krever en menneskelig tester med tastatur og skjermleser.
Utbedring. Rett opp i den rekkefølgen som beskytter de mest verdifulle reisene først: tastaturfeller og umerkede kassekontroller før kosmetiske kontrastjusteringer på en fotlenke. Én rettelse i en delt komponent - temaets fokusstil, formular-pluginens etikett-markup - fjerner ofte dusinvis av gjentatte funn samtidig, og det er derfor utbedring bør rettes mot delte maler før enkeltsider.
Publiser en tilgjengelighetserklæring. En erklæring som fastslår samsvarsnivået, kjente begrensninger og en fungerende kontaktkanal for tilgjengelighetsklager er obligatorisk etter flere lands gjennomføringslover og god praksis alle andre steder. Den gir også innkjøpsteam noe konkret å legge i saksmappen.
Overvåking. Tilgjengelighet driver i det øyeblikket en ny plugin-oppdatering, en ny page-builder-mal, eller en ny innholdsredaktør kommer inn uten opplæring. En automatisert kontroll i CI fanger regresjoner ved hver utrulling; en årlig manuell retest fanger det automatiseringen ikke ser.
For hele det rettslige bildet - WCAG 2.2s ni nye suksesskriterier, forholdet mellom EAA og norsk regelverk, og detaljer på plugin-nivå - les samsvarsstakken 2026 for WordPress. Hvis du ønsker en avgrenset, skriftlig revisjon i stedet for en selvbetjent sjekkliste, dekker EU-samsvarsrevisjon for WordPress tilgjengelighet sammen med NIS2/DORA- og AI Act-eksponering i ett engasjement, med individuelt tilbud basert på nettstedets faktiske omfang.
Hvorfor tilgjengelighet overlapper med SEO og AI-lesbarhet
Det meste av det tekniske arbeidet bak WCAG 2.1 AA er, uavhengig av dette, også god SEO og god hygiene for AI-svaremotorer, og det er derfor tilgjengelighetsbudsjetter er lettere å forsvare enn de først ser ut til å være. Et klart, sekvensielt overskriftshierarki er nøyaktig det søkemotor-crawlere og oppsummerende språkmodeller bruker for å forstå hva en side egentlig handler om; samme rettelse som hjelper en skjermleser-bruker å navigere en side, hjelper også et AI-system å hente ut riktig seksjon når det svarer på et spørsmål om den. Beskrivende alt-tekst gjør dobbelt arbeid - som signal for bildesøk og som en reservebeskrivelse ethvert AI-system som leser sidens markup kan bruke når selve bildet ikke blir behandlet.
Semantisk HTML - ekte <button>- og <nav>-elementer i stedet for stylet <div>-suppe, riktige <label>-tilknytninger i formularer - produserer markup som er både tilgjengelig og lettere å tolke pålitelig for automatiserte systemer, uansett om det systemet er en skjermleser, en søkecrawler, eller en retrieval-pipeline bak en AI-assistent. Ingenting av dette er en tilfeldighet: både tilgjengelighet og maskinlesbarhet konvergerer mot samme underliggende krav, nemlig innhold som bærer sin egen struktur og mening i markupen, i stedet for å basere seg helt på visuell styling. Å behandle et WCAG-utbedringsprosjekt som en rent juridisk kostnad overser at en stor del av arbeidet betaler for seg selv i organisk synlighet.
Hvor du går videre
Klar til å gå fra vurdering til handling? Kontakt oss for å avgrense en tilgjengelighetsgjennomgang for nettstedet ditt, eller start med den ressursen som passer der du er:
- Trenger du det dypere juridiske og tekniske kartet, inkludert WCAG 2.2? Les artikkelen om samsvarsstakken 2026.
- Trenger du en avgrenset, skriftlig revisjon med en utbedringsbacklog du kan gi til en utvikler? Se EU-samsvarsrevisjon for WordPress.
- Trenger du et team som bygger rettelsen, ikke bare diagnostiserer den? Utforsk våre WordPress-utviklingstjenester.
