Universell utforming av nettsider: krav og sjekkliste

Dette er den vanligste misforståelsen. Kravene til universell utforming av IKT er ikke noe som «kommer». De har vært bindende i årevis:

• Nye nettløsninger: siden 1. juli 2014.
• Alle eksisterende nettløsninger: siden 1. januar 2021 (forskriften § 11).
• Offentlig sektor, utvidede krav: fra 1. februar 2023.
• Synstolking av video, offentlig sektor: fra 1. februar 2024.

Med andre ord: har du en nettside i dag, skal den allerede oppfylle kravene. Hjemmelen er likestillings- og diskrimineringsloven §§ 17 og 18 og forskrift om universell utforming av IKT-løsninger.

Her er det lett å bli forvirret, fordi tallene ligner på hverandre:

• Privat sektor: WCAG 2.0 nivå A og AA – 35 av kravene for nettsteder (29 for apper). Nivået ble ikke hevet da offentlig sektor fikk strengere krav.
• Offentlig sektor: WCAG 2.1 nivå A og AA – 48 krav, via den harmoniserte standarden EN 301 549.
• WCAG 2.2: ikke et lovkrav i Norge i dag. Uutilsynet er tydelige på at det ikke endrer seg på kort sikt – en oppdatering krever først at EU tar 2.2 inn i EN 301 549, deretter en nasjonal forskriftsprosess som typisk tar et par år.

Praktisk råd: bygg mot WCAG 2.2 nivå AA likevel. De nye kriteriene i 2.1 og 2.2 handler stort sett om ting du vil ha uansett – større klikkflater, at innhold tåler zoom, at hjelp ligger på samme sted, at innlogging ikke krever at du husker et puslespill. Da er du trygg når regelverket oppdateres, og du slipper å gjøre jobben to ganger.

1. Kontrast mellom tekst og bakgrunn (1.4.3). Minst 4,5:1 for vanlig tekst, 3:1 for stor tekst (fra 24 px, eller 18,66 px i fet skrift). Test: mål fargene med et kontrastverktøy. Lysegrå tekst på hvitt er den desidert vanligste feilen på nett.
2. Alternativ tekst på bilder (1.1.1). Bilder som formidler noe trenger en alt-tekst som sier hva bildet formidler – ikke «bilde1.jpg». Rent dekorative bilder skal ha tom alt-tekst, så skjermleseren hopper over dem. Test: slå av bildene og se om innholdet fortsatt gir mening.
3. Ledetekst på alle skjemafelt (1.3.1 og 3.3.2). Hvert felt trenger en synlig ledetekst som er koblet til feltet i koden. En «placeholder» inne i feltet er ikke nok – den forsvinner idet du begynner å skrive. Test: klikk på ledeteksten. Får feltet fokus, er den koblet riktig.
4. Tomme lenker og knapper (2.4.4 og 4.1.2). Ikon-knapper uten tekst leses opp som «lenke» eller «knapp» – helt uten innhold. Gi dem et tilgjengelig navn. Test: naviger med tastatur og hør/les hva hvert element heter.
5. Alt må kunne brukes med tastatur (2.1.1). Menyer, modaler, karuseller, egendefinerte nedtrekk og «lukk»-kryss er de vanlige syndene. Test: legg bort musen og gå gjennom hele siden med Tab, Shift+Tab, Enter og piltaster.
6. Synlig fokusmarkering (2.4.7). Tastaturbrukere må se hvor de er. outline: none uten en erstatning er en ren tilgjengelighetsfeil. Test: trykk Tab og se om noe endrer seg visuelt.
7. Ekte overskriftsstruktur (1.3.1 og 2.4.6). Én H1, deretter H2 og H3 i logisk rekkefølge – overskrifter er struktur, ikke skriftstørrelse. Skjermlesere navigerer med dem, og søkemotorer leser dem på samme måte. Test: se på overskriftslista i et tilgjengelighetsverktøy.
8. Sidetittel som sier hva siden er (2.4.2). «Hjem | Firma» på samtlige sider gjør nettstedet uleselig i faner og i skjermleser – og koster deg klikk i Google. Test: les gjennom title-taggen på de tolv viktigste sidene.
9. Språkkode på siden (3.1.1). Mangler lang="nb" leses norsk tekst opp med engelsk uttale, og blir nesten uforståelig. Test: se etter lang-attributtet på html-elementet.
10. Teksting av video (1.2.2). Alt forhåndsinnspilt med tale skal tekstes. Automatisk teksting må korrekturleses – navn og fagord blir feil. Test: se videoen med lyden av.
11. Feilmeldinger som forklarer feilen (3.3.1). «Ugyldig utfylling» hjelper ingen. Si hvilket felt det gjelder og hva som er galt. Test: send inn skjemaet tomt og les det som kommer tilbake.
12. Stopp, pause eller skjul bevegelse (2.2.2). Karuseller som bytter selv, animasjoner i løkke og autospill må kunne stanses. Test: finn av-knappen. Finnes den ikke, er kravet brutt.

WebAIM tester automatisk de én million mest besøkte forsidene i verden hvert år. I februar 2026 hadde 95,9 % av dem feil som en maskin kan påvise – i snitt 56 feil per side. Seks feiltyper står for 96 % av alt:

• For svak tekstkontrast: 83,9 % av sidene
• Manglende alternativ tekst: 53,1 %
• Skjemafelt uten ledetekst: 51 %
• Tomme lenker: 46,3 %
• Tomme knapper: 30,6 %
• Manglende språkkode: 13,5 %

Det er verdt å merke seg at tallene har gått feil vei de siste årene, ikke riktig vei. Og listen er nesten identisk med sjekklista over – som betyr at du kommer forbi de fleste med overkommelig innsats.

Norske tall peker samme retning: i Uutilsynets egne tilsyn fra 2015 og fram til i dag hadde 98 % av de 88 kontrollerte løsningene brudd som måtte rettes. Dette er altså ikke noe som rammer «de andre».

Uutilsynet fører tilsyn både etter tips og på eget initiativ. Gangen er forutsigbar: kontroll, rapport, åtte uker på å rette, og deretter pålegg om retting med varsel om tvangsmulkt. Retter du innen frist, skjer det ikke mer.

Gjør du det ikke, kan mulkten bli reell. Det mest kjente eksempelet er SAS Norge, som i 2018 ble ilagt tvangsmulkt på 150 000 kroner per dag – med 10 % økning per måned – etter at 35 av 182 påviste feil i billettbestillingen fortsatt ikke var rettet. For offentlige virksomheter kan også manglende tilgjengelighetserklæring utløse dagmulkt.

I tillegg kommer det som ikke står i noe vedtak: kunder som ikke får fullført kjøpet, søkere som ikke får sendt skjemaet, og en omdømmerisiko du ikke velger tidspunktet for.

Offentlige virksomheter må ha en tilgjengelighetserklæring (forskriften § 4e, gjeldende fra 1. februar 2022). Den lages i Uutilsynets løsning uustatus.no, skal beskrive hva som ikke er i orden, ha en tilbakemeldingskanal, og oppdateres minst én gang i året.

Private virksomheter har ikke dette kravet – men en kort tilgjengelighetsside er billig tillit: hva dere har gjort, hva som gjenstår, og hvor man sier fra hvis noe ikke virker. Det du får tilbake er konkrete feilmeldinger fra dem som faktisk møter problemene.

Prisen avhenger av hvor gammel løsningen er og hvor mye som er egenutviklet. To ting er likevel nesten alltid sanne: det er langt billigere å bygge det inn fra starten enn å rette det etterpå, og de første tiltakene gir mest per krone. Kontrast, ledetekster, alt-tekster og fokusmarkering er småpenger å rette sammenlignet med å bygge om en egenutviklet karusell.

En rekkefølge som fungerer:

1. Egentest av de fem viktigste sidetypene (kvarteret over).
2. Fagperson går gjennom de samme sidene manuelt og lager en prioritert liste – ikke bare en verktøyrapport.
3. Rett det som stopper folk først: kasse, skjema, innlogging, søk. Der taper du faktiske kunder.
4. Legg kravene i kravspesifikasjonen neste gang du bestiller design eller utvikling: «WCAG 2.2 nivå AA, testet med tastatur og skjermleser, dokumentert ved levering». Én setning som sparer deg for en hel runde senere.
5. Test på nytt ved hver større endring. Et nytt tema, en ny modul eller en ny utvikler kan sette deg tilbake.

Skal du hente inn hjelp, be om noe konkret: en gjennomgang av navngitte sider, manuell tastatur- og skjermlesertest, og en prioritert liste med anslag per punkt. Da kan du sammenligne tilbud, og du vet hva du får.