Universell utforming av nettsider: dette bør norske bedrifter vite i 2026

Norske nettsider rettet mot allmennheten må følge WCAG 2.1 nivå AA, der 47 av 49 suksesskriterier er gjort til norsk lov. I praksis handler det om kontrast, tastaturnavigasjon, skjemaer med tydelige ledetekster, alternativ tekst på bilder og en kodestruktur skjermlesere forstår. Det meste rettes billigst mens nettstedet bygges.

De fleste som googler dette lurer egentlig på én ting: «Må vi gjøre noe, og hva koster det?» Svaret for de aller fleste norske bedrifter er ja, dere må gjøre noe – og nei, det trenger ikke bli dyrt hvis dere tar det på riktig tidspunkt. Kravene til tilgjengelige nettsider er ikke en anbefaling fra en designer, men forskriftsfestet rett som Tilsynet for universell utforming av ikt fører kontroll med. Denne artikkelen går gjennom hva regelverket faktisk krever, hvilke feil vi finner igjen og igjen når vi går gjennom eksisterende nettsteder, hva retting koster i praksis, og når det faktisk er riktig å vente.

Hva loven faktisk krever av nettstedet ditt

Hjemmelen ligger i likestillings- og diskrimineringsloven § 18, som pålegger virksomheter rettet mot allmennheten å gjøre IKT-løsningene sine universelt utformet. Detaljene står i forskrift om universell utforming av IKT-løsninger, som siden februar 2023 viser til WCAG 2.1 nivå AA som norsk standard. Av de 49 suksesskriteriene på nivå A og AA er 47 gjort gjeldende i Norge; de to unntakene gjelder lydbeskrivelse og mediealternativ for forhåndsinnspilt video, som Tilsynet for universell utforming av ikt beskriver nærmere. Kravet om publisert tilgjengelighetserklæring gjelder foreløpig bare offentlige virksomheter, men selve WCAG-kravene gjelder også deg som driver en helt vanlig bedriftsside.

Det er verdt å understreke hva «rettet mot allmennheten» betyr i praksis: en nettside der hvem som helst kan lese om tjenestene dine, fylle ut et kontaktskjema eller bestille noe, er omfattet. Rene interne fagsystemer bak innlogging for ansatte har hatt en mildere behandling historisk, men grensen flyttes. Vi går grundigere gjennom rekkevidden i artikkelen om hvilke krav som gjelder for ulike virksomheter, og forklarer prinsippene bak standarden i den generelle innføringen i temaet universell utforming.

De fire prinsippene, oversatt til noe du kan bruke

• Mulig å oppfatte: tekst må ha nok kontrast mot bakgrunnen (4,5:1 for vanlig tekst, 3:1 for stor tekst), bilder som bærer mening må ha alternativ tekst, og video må ha teksting.
• Mulig å betjene: alt skal kunne brukes med tastatur alene. Menyer, karuseller, popup-vinduer og «lukk»-knapper er de klassiske fellene.
• Forståelig: skjemafelt må ha synlige ledetekster, feilmeldinger må si hva som er galt og hvordan det rettes, og språket må være satt i koden (lang="no").
• Robust: koden må være semantisk, slik at skjermlesere og andre hjelpemidler forstår hva som er en overskrift, en knapp og en liste – ikke bare visuelt formaterte div-elementer.

Kontrastkravene og resten av suksesskriteriene er dokumentert i detalj i WCAG 2.1 fra W3C. Vårt råd er å lese kriterium 1.4.3 (kontrast) og 2.1.1 (tastatur) før du godkjenner et designforslag – de to alene fanger opp en stor del av feilene som ellers oppdages først etter lansering.

Hva skjer med EUs tilgjengelighetsdirektiv?

EUs tilgjengelighetsdirektiv (direktiv 2019/882) fikk virkning i EU 28. juni 2025 og utvider kravene til produkter og tjenester som netthandel, banktjenester, e-bøker, billettautomater og elektronisk kommunikasjon. Direktivet er EØS-relevant, og norsk innføring er under arbeid. Praktisk betyr det at terskelen for netthandel og selvbetjeningsløsninger blir høyere, ikke lavere, de neste årene. Vi mener derfor det er feil økonomi å planlegge en ny nettside i 2026 etter minstekravene fra 2013 – bygg heller etter WCAG 2.1 AA med et øye til WCAG 2.2, som blant annet stiller krav til målområdestørrelse og at hjelpetekst ikke skjules av flytende elementer.

Feilene vi finner oftest når vi gjennomgår norske nettsider

Det vi ser oftest er ikke eksotiske brudd, men de samme sju–åtte tingene om igjen. Under er listen slik den pleier å se ut når vi kjører en gjennomgang av et eksisterende nettsted, enten det er bygget i WordPress, Webflow eller en egen løsning.

• Lysegrå tekst på hvit bakgrunn i ingresser og bildetekster – ser stilrent ut, men lander ofte på 2,8:1 mot kravet på 4,5:1.
• Hamburgermeny som ikke kan åpnes eller lukkes med tastatur, og der fokus ikke låses inne i menyen når den er åpen.
• Skjemaer der ledeteksten kun ligger som plassholdertekst inni feltet, og forsvinner så snart brukeren begynner å skrive.
• Bilder uten alternativ tekst – eller, nesten like ille, dekorative bilder med lange alt-tekster som skjermleseren leser opp i ett kjør.
• Knapper laget som lenker og lenker laget som knapper, slik at hjelpemidler feiltolker hva som skjer ved klikk.
• Overskriftsnivåer valgt etter skriftstørrelse i stedet for struktur: H4 før H2, eller tre H1-er på samme side.
• Videoer uten teksting, ofte lagt inn som bakgrunnsvideo med tekst oppå – som både bryter kontrastkravet og er umulig å pause.
• Informasjonskapsel-banner og samtykkedialog som ikke kan betjenes med tastatur, og som blokkerer hele siden.

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

Poenget med å nevne dette her er sammenhengen: mange av funnene i en teknisk gjennomgang av søkemotoroptimalisering er de samme filene og malene som må røres for å rette tilgjengelighetsfeil. Bilder som mangler komprimering mangler som regel også alternativ tekst. Maler med rotete overskriftsstruktur er rotete både for Google og for skjermlesere. Skal du først inn i koden, er det dårlig ressursbruk å gjøre det to ganger. Trenger du en rask temperaturmåling før du bestemmer deg, har vi skrevet om hvordan du kan sjekke nettsiden din selv.

Universell utforming av IKT henger sammen med synlighet i søk

Universell utforming av IKT handler formelt om at alle skal kunne bruke digitale løsninger, uavhengig av funksjonsevne. Men den tekniske jobben overlapper påfallende med det som gjør et nettsted lett å lese maskinelt. Semantisk HTML, riktig overskriftshierarki, beskrivende lenketekster og alternativ tekst på bilder er nøyaktig det som gjør at en side kan tolkes av både en skjermleser og en språkmodell. Når Google viser AI Overview øverst i resultatene, og når folk stiller spørsmål direkte til ChatGPT eller Perplexity, er det sidene med tydelig struktur som blir plukket opp og sitert. Vi har beskrevet mekanikken nærmere i artikkelen om hvordan AI-søk endrer synligheten din.

Box legger inn strukturerte data og llms.txt som standard på alle nye nettsider, fordi sider med tydelig maskinlesbar struktur er de vi ser bli plukket opp av AI-søk først.

En liten advarsel mot overtolkning: tilgjengelighet er ikke en rangeringsfaktor i seg selv, og du blir ikke nummer én fordi kontrasten er riktig. Men ytelse og mobilvennlighet er målbare signaler, og de forbedres nesten alltid samtidig med tilgjengelighetsarbeidet, fordi begge deler krever opprydding i bilder, skript og stilark.

Etter Lighthouse-optimalisering (bildekomprimering, caching, opprydding i skript) forbedres ytelsesscore hos Box sine kunder typisk fra under 55 til over 80.

Lighthouse gir forresten også en egen tilgjengelighetsscore. Den er nyttig som en første temperaturmåling, men den fanger bare opp de feilene som kan oppdages automatisk – typisk rundt en tredjedel av kriteriene. Tastaturnavigasjon, fokusrekkefølge og om alternativteksten faktisk beskriver bildet, må testes manuelt. Vi fraråder å bruke en grønn automatisk score som dokumentasjon på at nettstedet er i orden.

Hva koster det – og hva bør du budsjettere med?

Kostnaden avhenger nesten utelukkende av når i løpet du tar tak i det. Bygger du en ny side, er tilgjengelighet i praksis et sett med designbeslutninger og kodevaner som ikke koster ekstra timer – det koster at noen kan faget. Skal du rette et eksisterende nettsted med femten sidemaler, et bookingsystem fra en tredjepart og fire år med publiserte artikler, er det en helt annen øvelse.

• Gjennomgang og prioritert tiltaksliste for et typisk bedriftsnettsted: som regel en til to dagsverk, inkludert manuell tastaturtest og skjermlesertest av de viktigste brukerreisene.
• Rette kontraster, overskriftsstruktur, alternativtekster og fokusmarkering i eksisterende maler: ofte tre til åtte dagsverk, avhengig av antall maler.
• Bygge om skjemaer, meny og eventuell bestillingsløsning: dette er den store posten, og den varierer mest – her kan et tredjepartsverktøy som ikke er tilgjengelig velte hele regnestykket.
• Nytt nettsted bygget riktig fra start: tilgjengelighet utgjør i vår erfaring en marginal del av totalprisen, fordi arbeidet ligger i beslutningene, ikke i ekstra utviklingstimer.

Vi anbefaler at du ber leverandøren skille dette ut som en egen linje i tilbudet, slik at du ser hva du faktisk betaler for. Er du usikker på hva som er normalt nivå, har vi samlet erfaringstall i gjennomgangen av hva en nettside koster. Husk også at tilgjengelighet ikke er en engangsjobb: hver gang noen publiserer en artikkel med et bilde uten alt-tekst eller limer inn en tabell fra Word, forfaller nettstedet litt. Det hører hjemme i den løpende driften av nettsiden, på samme måte som oppdateringer og sikkerhetskopier.

Når universell utforming ikke er riktig sted å bruke pengene nå

Det finnes tilfeller der vi faktisk råder kunder til å vente. Det viktigste er dette: skal du bytte plattform eller redesigne innen seks til tolv måneder, er det bortkastet å bruke seks dagsverk på å rette maler som skal kastes. Da retter vi de få tingene som er reelt ekskluderende – kontrast, tastaturfeller i menyen og skjemaer som ikke kan fylles ut – og tar resten i det nye bygget. Samme logikk gjelder hvis nettstedet ditt i praksis er én enkelt temaet landingsside mens all reell aktivitet skjer i et bookingsystem fra en tredjepart: da ligger den største barrieren hos leverandøren av systemet, og der er ditt viktigste virkemiddel kontrakten, ikke utviklertimer.

Vi fraråder derimot to snarveier vi ser ofte. Den første er «tilgjengelighetsoverlegg» – skript som legger seg over siden med en meny for kontrast og skriftstørrelse. De retter ikke den underliggende koden, de kan forstyrre skjermlesere brukeren allerede har, og de gir deg ingen dokumentasjon som holder i en tilsynssak. Den andre er å utsette alt til «etter neste kampanje». Tilsynet kan gi pålegg om retting med tvangsmulkt, og en klage fra en bruker kommer sjelden på et beleilig tidspunkt.

Slik ville vi lagt opp arbeidet

Rekkefølgen betyr mer enn ambisjonsnivået. Vi ville startet der brukerne faktisk mister muligheten til å gjøre noe, ikke der antallet automatiske feilmeldinger er høyest.

• Kartlegg de tre viktigste brukerreisene: finne tjenesten, ta kontakt, eventuelt bestille eller logge inn. Test dem med tastatur og skjermleser.
• Rett det som blokkerer: samtykkedialog, meny, skjemaer, feilmeldinger. Dette er tiltakene som flytter noen fra «umulig» til «mulig».
• Rett det som er systematisk: kontrastverdier i designsystemet, fokusmarkering, overskriftsnivåer i malene. Én endring treffer alle sidene.
• Rydd i innholdet: alternativtekster, beskrivende lenketekster, teksting av video. Dette kan redaksjonen ofte gjøre selv.
• Sett en publiseringsrutine i redaktørverktøyet, slik at nye sider ikke innfører gamle feil på nytt.
• Dokumenter status – også hvis du er privat virksomhet uten plikt til å publisere tilgjengelighetserklæring. Det er verdt mye å kunne vise hva som er testet og når.

Punkt fem er det som avgjør om jobben holder. Valget av publiseringsløsning betyr mye her: et redaktørverktøy som krever alternativtekst før publisering, og som ikke lar deg velge fritt blant overskriftsnivåer, sparer deg for årevis med opprydding. Det samme gjelder responsivt webdesign – kravet om at innhold skal fungere ved 400 % forstørring henger tett sammen med at mobilvisningen er ordentlig bygget. Og mens du først er i gang med det juridiske sporet: sjekk at personvernerklæringen er oppdatert, og at samtykkeløsningen faktisk kan betjenes med tastatur.

Skal du bygge nytt, er dette en naturlig del av spesifikasjonen fra dag én. Vi tar det med som standard i alle prosjekter vi leverer innenfor nettside, sammen med teknisk struktur, ytelse og sporing.