Hva WCAG krever av norske bedriftsnettsider i 2026

WCAG er W3C sin standard for tilgjengelig webinnhold. I Norge skal private virksomheter oppfylle 35 suksesskriterier fra WCAG 2.0 nivå A og AA, mens offentlig sektor følger 48 av 78 i WCAG 2.1. De vanligste avvikene er kontrast, manglende alternativ tekst og skjemaer uten etiketter, og de rettes billigst mens siden bygges.

Når norske bedrifter spør oss hva WCAG krever, er det sjelden selve standarden de er usikre på. Det er hvilken versjon som gjelder dem, hvor mange suksesskriterier som faktisk er lov, og om en liten bedriftsside med kontaktskjema er omfattet. Svaret er ja — du er omfattet — men tallet er et annet enn det mange artikler oppgir. Denne teksten går gjennom hva standarden er, hva forskriften i Norge faktisk peker på, og hva det koster å rette det som vanligvis er galt.

Et forbehold først: WCAG er en internasjonal teknisk standard. Den er ikke norsk lov i seg selv. Det som er lov, er forskrift om universell utforming av IKT-løsninger, som viser til bestemte versjoner og unntak. Forveksle ikke de to. Standarden forklarer hvordan innhold skal bygges. Forskriften sier hvilken del av standarden du er pliktig til å følge. Bakgrunnen — hvorfor dette finnes, og hva det betyr for brukerne — har vi skrevet mer om under universell utforming som prinsipp.

Hva WCAG er — og hva forkortelsen faktisk dekker

WCAG står for Web Content Accessibility Guidelines, på norsk retningslinjer for tilgjengelig webinnhold. Standarden skrives av W3C, den samme organisasjonen som forvalter HTML og CSS. Den beskriver testbare suksesskriterier for at innhold i en nettleser skal kunne brukes av flest mulig, inkludert folk som bruker skjermleser, forstørrelse, bare tastatur, eller som ser dårlig i sterkt lys. Kriteriene er gruppert i tre nivåer: A (grunnleggende), AA (det nivået de fleste lover peker på) og AAA (strengere, sjelden et lovkrav).

De fire prinsippene bak hvert kriterium

Hvert suksesskriterium hører til ett av fire prinsipper, ofte forkortet POUR på engelsk. På norsk: innholdet skal være mulig å oppfatte, mulig å betjene, forståelig og robust. Oppfatte betyr at informasjonen ikke bare ligger i farge, form eller lyd. Betjene betyr at du skal klare hele løpet uten mus. Forståelig betyr at felt, feilmeldinger og navigasjon er forutsigbare. Robust betyr at koden er semantisk nok til at hjelpemidler og fremtidige nettlesere forstår strukturen — overskrift, knapp, liste og skjemafelt, ikke bare pyntede bokser.

Versjonene 2.0, 2.1 og 2.2

WCAG 2.0 kom i 2008 og er den versjonen forskriften peker på for private. WCAG 2.1 fra 2018 la til 17 suksesskriterier, mest for mobil: berøring, gester, zoom til 200 prosent og kontrast på knapper, ikke bare brødtekst. W3C sin WCAG 2.1-standard setter kontrastkravet for vanlig tekst til minst 4,5:1 mot bakgrunnen, og 3:1 for stor tekst. WCAG 2.2 fra 2023 legger blant annet til minstemål på treffflater og innlogging uten å huske en kode. Innhold som oppfyller 2.2, oppfyller også 2.1 og 2.0 — derfor er 2.2 et fornuftig mål på nye sider.

Hva som gjelder for WCAG i Norge

Her er skillet de fleste hopper over. Forskriften § 4 sier at private virksomheters nettløsninger minst skal utformes i samsvar med WCAG 2.0 på nivå A og AA, med unntak for suksesskriteriene 1.2.3, 1.2.4 og 1.2.5 — synstolking og teksting av direktesending. WCAG 2.0 har 38 kriterier på A og AA. Tre er unntatt. Det gir 35 minstekrav. Tilsynet for universell utforming av ikt slår fast at private virksomheter ikke fikk nye plikter da EUs webdirektiv ble norsk rett, og at dagens 35 minstekrav gjelder fortsatt. Offentlig sektor skal derimot følge 48 av 78 suksesskriterier i WCAG 2.1, gjennom den europeiske standarden EN 301 549. De 12 ekstra kriteriene fra 2.1 handler i stor grad om mobil.

Kravene gjelder nettløsninger som er hovedløsninger rettet mot eller stilt til rådighet for allmennheten. En bedriftsside der kunder leser om tjenestene, booker time eller sender skjema, er omfattet. Det finnes ingen nedre grense for antall ansatte eller omsetning. Rene interne fagsystemer bak innlogging for ansatte er i utgangspunktet unntatt, med unntak for offentlige intra- og ekstranett som er nye eller vesentlig endret etter 1. februar 2023. Eksisterende løsninger skulle vært i orden innen 1. januar 2021. Fristen er altså for lengst passert.

EUs tilgjengelighetsdirektiv har vært virksomt i EU siden 28. juni 2025 og rammer blant annet netthandel. Innlemmelse i EØS har ligget etter, så inntil videre er det forskriftens to spor som gjelder her hjemme — ikke det nyeste W3C har publisert.

Hva de 35 minstekravene betyr på en vanlig bedriftsside

Du trenger ikke å pugge alle suksesskriteriene. På en typisk norsk SMB-side er det et knippe feil som går igjen, og de overlapper med det internasjonale bildet. I WebAIM Million-rapporten for 2025 hadde 94,8 prosent av én million forsider automatisk påvisbare WCAG-brudd, med 51 feil per side i snitt. Nitten av tjue sider rammes. 96 prosent av alle oppdagede feil falt i seks kategorier: lav kontrast, manglende alternativ tekst, skjemafelt uten etikett, tomme lenker, tomme knapper og manglende språk i koden. Det er de samme kategoriene vi ser når vi åpner en norsk bedriftsside som ikke er bygget med dette i hodet.

• Kontrast: brødtekst under 4,5:1, knapper og ikoner under 3:1. Nesten alltid en arv fra en mal med lysegrå tekst.
• Bilder: meningsbærende bilder uten alternativ tekst, og pyntebilder uten tom alt-attributt. Lenkede bilder uten tekst blir usynlige for skjermleseren.
• Skjema: plassholdertekst i stedet for synlig etikett, feilmelding som bare er rød farge, og felt som ikke kan fylles ut med tastatur.
• Navigasjon: menyer og karuseller som krever mus, fokusmarkering som er slått av i CSS, og «les mer»-lenker uten kontekst.
• Struktur: hopp i overskriftsnivå, språk ikke satt til norsk i HTML, og PDF-er lastet opp som skannede bilder.

Flere av disse punktene er det samme arbeidet som god teknisk kvalitet uansett. Et oppsett som tilpasser seg mobil klarer zoom-kravet uten ekstra runder. Fargevalg og typografi i designet avgjør kontrastkravet før en eneste linje kode er skrevet. Og bilder som er komprimert og merket, hjelper både lastetid og skjermleser. Det er derfor vi behandler tilgjengelighet som en del av å lage en ny bedriftsnettside, ikke som en ettertanke etter lansering.

I tekniske SEO-gjennomganger hos Box er de tre vanligste funnene manglende/feil canonical-tagger, uoptimaliserte bilder og treg mobil-lastetid — alle tre er normalt løst på under en arbeidsdag.

De samme gjennomgangene avdekker ofte manglende alternativ tekst i samme slengen som de uoptimaliserte bildene. Det er sjelden et eget prosjekt. Det er tre–fire timer med merking, komprimering og et par linjer CSS for fokus og kontrast. Det vi ser oftest, er at bedriften har betalt for en visuell mal som ser pent ut på et stort skjermbilde og faller gjennom så snart noen tabber, zoomer eller slår på mørk modus.

Hva det koster å oppfylle kravene

Kostnaden styres av alder og kompleksitet, ikke av antall suksesskriterier på papiret. På en side bygget de siste årene i et moderne publiseringssystem er de vanlige avvikene kontrast, alternative tekster, skjemaetiketter og fokusmarkering. Det er arbeid i timer, ikke uker. På eldre løsninger med tredjepartsmoduler — gamle kalendere, kart og timebestillingsverktøy som ikke kan betjenes uten mus — kan du ende med å bytte komponent. Da er det et utviklingsløp, og det lønner seg ofte å ta det samtidig med annen opprydding, særlig ved utvikling på WordPress der tema og utvidelser styrer mye av grensesnittet.

En automatisk test er et billig første steg, men den fanger bare en del av kriteriene. Resten krever tastatur og skjermleser. Vi rapporterer avvik som konkrete oppgaver med timeanslag, ikke som en score mellom 0 og 100. Skal du budsjettere en helt ny side, ligger rammene i gjennomgangen av hva en ny nettside koster. Og kravene hører hjemme i kravspesifikasjonen før prosjektet starter — da slipper du å betale for å rette det som burde vært med i tilbudet.

Når arbeid med WCAG ikke er riktig sted å starte

Vi fraråder å bruke penger på å rette kontrast i et tema som skal ut innen seks måneder. Da tar du standarden inn i den nye løsningen. Det samme gjelder hvis siden i dag ikke leverer henvendelser: da er problemet innhold og tilbud, ikke tilgjengeligheten alene. Rett begge deler i samme runde, eller vent til du vet at du beholder plattformen.

• Du skal bytte publiseringssystem eller redesigne innen et halvår — da er lapping bortkastet.
• Siden har fem undersider og ingen skjemaer utover en enkel kontakt. Da holder noen timer med opprydding, ikke en formell revisjon.
• Du eier ikke koden, for eksempel i en låst nettsidebygger der temaet ikke lar seg overstyre. Da er bytte av verktøy riktigere enn å jakte unntak.
• Innholdet er det som stenger folk ute — skannede PDF-er, video uten teksting, språk ingen forstår — og koden er i orden. Da er det redaktørarbeid, ikke utviklerarbeid.

Vi mener også at enmannsbedriften med en enkel presentasjonsside ikke skal bruke et femsifret beløp på en revisjonsrapport. Den skal bruke noen timer, dokumentere hva som er gjort, og gå videre. For virksomheter med timebestilling, innlogging eller salg er terskelen reelt høyere, både juridisk og kommersielt. Tilsynet kan gi pålegg om retting og tvangsmulkt. Den største kostnaden er likevel kundene som ikke får sendt skjemaet eller fullført kjøpet.

Testing som faktisk ender i retting

Det vi ser oftest, er at bedriften kjører en automatisk test, får en lang liste, og lar den ligge. En bedre rekkefølge er tre steg. Først en automatisk gjennomgang for å finne det maskinen er god på: kontrast, manglende alternativ tekst, tomme knapper, språk i koden. Deretter manuell tastaturnavigasjon av forsiden, kontaktløpet og eventuelle skjemaer. Til slutt en runde med skjermleser på de samme sidene. Metodikken er den samme som når vi tar en teknisk gjennomgang av nettsiden — avvikene skal kunne gjøres om til oppgaver, ikke til en score.

Etter retting hører dette hjemme i den løpende driften av nettsiden. Nye bilder uten alternativ tekst og nye utvidelser som ødelegger tastaturet, er like vanlige som de opprinnelige feilene. Standarden er en egenskap ved hvordan dere publiserer, ikke et prosjekt du krysser av. Kontrast, fokus og skjemamønstre bør ligge i designsystemet — se hvordan vi tenker rundt nettsider for bedrifter hvis du skal bygge nytt.