Tilgjengelighetserklæring med teknisk WCAG-revisjon

En tilgjengelighetserklæring er en offentlig egenerklæring om hvor godt et nettsted eller en app oppfyller kravene til universell utforming av IKT. Alle offentlige virksomheter i Norge må publisere den i uustatus.no. Den viser status for hvert av de 48 kravene, forklarer hva som ikke virker, og gir brukerne en måte å melde fra på.

Erklæringen er ikke bedre enn testingen den bygger på. Under går vi gjennom hva erklæringen er og hva den skal inneholde, regelverket for offentlig og privat sektor (inkludert EAA), hvordan en WCAG-revisjon gjøres, og hvordan du holder dokumentasjonen oppdatert så den står seg ved tilsyn.

Vi er utviklere. Feilene revisjonen finner, retter vi i koden, eller vi viser utviklerne dine nøyaktig hvordan de gjør det.

Hva er en tilgjengelighetserklæring?

En tilgjengelighetserklæring er et offentlig dokument som beskriver i hvilken grad et nettsted eller en mobilapp oppfyller kravene til universell utforming av IKT. I Norge bygger kravene på den internasjonale standarden WCAG 2.1 (Web Content Accessibility Guidelines), nivå A og AA.

Erklæringen er nyttig for flere:

• For brukeren: Den forteller om barrierer i løsningen, så brukere med nedsatt funksjonsevne vet hva de kan vente seg, og den gir en enkel måte å melde fra om feil på.
• For virksomheten: Du må kartlegge løsningen systematisk, og da ser du hva som må rettes først.
• For tilsynet: Den er grunnlaget for kontrollene og statistikken til Tilsynet for universell utforming av ikt (Uu-tilsynet).
• Som juridisk vern: En korrekt utfylt erklæring viser at virksomheten tar lovkravene på alvor og har en plan for å rette avvikene. Det reduserer risikoen for sanksjoner.

Erklæringen er ikke det samme som revisjonsrapporten. Rapporten er skrevet for utviklerne og forteller nøyaktig hvor feilene er og hvordan de rettes. Erklæringen er skrevet for brukerne og forteller hva som virker, hva som ikke virker, og hva virksomheten gjør med det. Du trenger begge.

Hva skal stå i erklæringen?

En god erklæring er ærlig og konkret. Den skal svare på det brukerne lurer på, uten at de må forstå WCAG. Den inneholder som regel:

• Samsvarsstatus: om løsningen er i samsvar, delvis i samsvar eller ikke i samsvar med kravene, og status for hvert enkelt krav.
• Bruddene: hvilke krav som ikke er oppfylt, og hvor i løsningen feilene finnes.
• Konsekvensen for brukerne: hvilke grupper som rammes, for eksempel brukere uten syn, med nedsatt syn eller uten finmotorikk.
• Testgrunnlaget: hvordan løsningen er vurdert, og når.
• Tilbakemelding: hvordan brukerne kan melde fra om feil eller be om innholdet i en annen form.

Lenken til erklæringen skal være lett å finne, gjerne i bunnteksten på hver side. En erklæring som bare finnes hvis du vet hvor den ligger, hjelper ingen.

Skriv for brukeren. «Brudd på 1.3.1» sier lite til de fleste. «Skjemaet for timebestilling kan ikke fylles ut med skjermleser, fordi feltene mangler navn. Ring oss, så bestiller vi for deg» forteller brukeren hva som er galt og hva de kan gjøre i mellomtiden.

Offentlig sektor: forskriften og uustatus.no

For å forstå kravene må du skille mellom regelverket for offentlig og privat sektor. De tekniske kravene i WCAG overlapper ofte, men dokumentasjonsplikten og hjemmelsgrunnlaget er ulike.

Offentlige organer er underlagt forskrift om universell utforming av IKT-løsninger, som gjennomfører EUs webdirektiv (WAD).

• Krav: Alle nettsteder og mobilapper skal ha en oppdatert tilgjengelighetserklæring publisert i uustatus.no.
• Frist: For nettsteder utløp fristen 1. februar 2023, og for apper 1. februar 2024. Hver app skal ha sin egen erklæring.
• Sanksjon: Manglende publisering eller grovt mangelfull utfylling kan gi pålegg om retting og dagbøter (tvangsmulkt).

Privat sektor og EAA

EUs tilgjengelighetsdirektiv (EAA) ble vedtatt i 2019 og har gjeldt i EU siden 28. juni 2025. Målet er å samordne tilgjengelighetskravene for utvalgte produkter og tjenester i det indre markedet. EAA er per i dag ikke fullt gjennomført i norsk lov, men Norge har plikt til å innlemme direktivet gjennom EØS-avtalen, og det arbeidet pågår.

EAA gjelder bare et avgrenset sett av produkter og tjenester. For digitale tjenester betyr det at hele brukerreisen, med kjøp, betaling og kundedialog, skal være universelt utformet. Norske virksomheter som tilbyr slike produkter eller tjenester i EU, må derfor forholde seg til kravene allerede nå, selv om norsk lov ikke er endelig på plass.

For en norsk nettbutikk eller bank er det lurt å gjøre jobben før kravet kommer. En revisjon nå viser hvor langt du har igjen, og en frivillig tilgjengelighetserklæring på nettsiden gjør det lett for kundene å se at du tar det på alvor. Når kravet kommer, er det meste av dokumentasjonen allerede på plass.

Private virksomheter skal ikke bruke uustatus.no. EAA krever i stedet at virksomheten dokumenterer hvordan løsningen oppfyller kravene, i tjenestevilkårene eller i den tekniske dokumentasjonen for produktet. Dokumentasjonen bygger ofte på standarder som WCAG og EN 301 549.

• Omfang: E-handel, bank- og finansielle tjenester, transporttjenester, e-bøker og elektroniske kommunikasjonstjenester.
• Dokumentasjonsplikt: Beskrivelse av tilgjengeligheten i tjenestevilkårene eller den tekniske dokumentasjonen.
• Teknisk standard: WCAG 2.1 AA og EN 301 549.
• Konsekvens: Produkter og tjenester som ikke oppfyller kravene, kan nektes markedsadgang i EU og EØS.

Slik gjennomfører vi en WCAG-revisjon

En gyldig tilgjengelighetserklæring bygger på en grundig teknisk revisjon. En erklæring basert på antakelser eller enkle automatiske tester oppfyller ikke lovkravet om at vurderingen skal være «basert på en faktisk evaluering». Vi følger en fast metode som kombinerer automatisk skanning med manuell testing.

Utvalg. En stor webløsning kan bestå av tusenvis av sider, og det er sjelden fornuftig å teste alle. Vi velger et representativt utvalg etter WCAG-EM (Website Accessibility Conformance Evaluation Methodology). Det omfatter typisk forsiden og navigasjonsmenyene, innlogging og «Min side», kritiske brukerreiser som søknadsskjema, handlekurv og booking, sider med ulike innholdstyper som tabeller, video, kart og skjemaer, og kontaktinformasjon og hjelpesider.

Automatisert testing. Vi bruker verktøy som axe-core og ARC Toolkit for å finne syntaksfeil og programmatiske brudd: manglende lang-attributter, tomme lenker, alvorlige kontrastfeil, ugyldig HTML-struktur og skjemafelt uten ledetekst. Begrensningen er at automatiske verktøy bare kan sjekke rundt 20–30 % av WCAG-kravene. En side kan få null feil i en automatisk test og likevel være ubrukelig for en blind bruker.

Manuell kodesjekk. Her trengs teknisk dybde. Vi inspiserer koden direkte i nettleseren med DevTools for å se at semantikken holder. Brukes button til handlinger og a til navigasjon? Er overskriftene h1 til h6 kodet logisk, eller bare stylet til å se ut som overskrifter? Er WAI-ARIA-attributter som aria-expanded og role="dialog" brukt riktig for å formidle tilstand til hjelpemidler? Feil bruk av ARIA er ofte verre enn ingen ARIA. Vi tester også at innholdet skalerer riktig opp til 400 % zoom, uten at informasjon forsvinner eller krever horisontal rulling (WCAG 1.4.10).

Test med tastatur og skjermleser. Dette er den viktigste delen, for her tester vi løsningen slik brukerne opplever den. Med tastaturet sjekker vi at tab-rekkefølgen følger leseflyten, at fokus alltid er synlig, at alle interaktive elementer kan nås, og at det ikke finnes tastaturfeller. Med skjermleserne NVDA, JAWS og VoiceOver sjekker vi at skjemaer leser opp feilmeldinger riktig, at dynamisk innhold varsles med aria-live, og at bilder har meningsfull alternativ tekst.

Slik lager du en tilgjengelighetserklæring i uustatus

Offentlige virksomheter lager erklæringen i uustatus.no, Digdirs løsning for tilgjengelighetserklæringer. Slik går du frem:

1. Test løsningen. Gå gjennom et representativt utvalg sider og brukerreiser mot WCAG 2.1 AA, manuelt og med verktøy.
2. Logg inn i uustatus.no og opprett en erklæring for nettstedet eller appen.
3. Fyll inn status for hvert krav: oppfylt, ikke oppfylt eller ikke relevant.
4. Beskriv avvikene og hva de betyr for brukerne, med en plan for når de rettes.
5. Publiser og lenk til erklæringen fra bunnteksten på nettstedet eller fra appen.
6. Oppdater når løsningen endrer seg, og minst én gang i året.

Det er i punkt 3 og 4 de fleste erklæringer blir svake. Du kommer ikke langt ved å lime inn rapporten. Dette må være på plass:

Testgrunnlag. Du må oppgi om erklæringen bygger på en ekstern vurdering (tredjepartsrevisjon), en egenvurdering eller en leverandørvurdering. En ekstern vurdering gir erklæringen høyere troverdighet ved tilsyn.

Ikke samsvar. For hvert av de 48 suksesskriteriene i WCAG 2.1 oppgir du status. Ved avvik krever systemet en beskrivelse i fritekst. Beskriv feilen så presist at utviklere kan gjenskape den, og så forståelig at brukerne skjønner den:

• Dårlig: «Bilder mangler tekst.»
• Bra: «Informasjonsbærende grafikk på Om oss-siden mangler alt-attributt, så informasjonen er utilgjengelig for skjermlesere.»

Konsekvens. Du må beskrive hva feilen betyr for brukeren. Det viser at virksomheten forstår alvoret.

Fremdriftsplan. Tilsynet forventer at kjente feil har en plan for utbedring. Å oppgi feil uten en plan kan på sikt føre til sanksjoner.

Vanlige feil i tilgjengelighetserklæringer

Vi ser de samme feilene igjen og igjen når vi går gjennom erklæringer andre har laget:

• Samsvar uten test: Krav er merket som oppfylt uten at noen har testet dem manuelt. Ved tilsyn faller det raskt sammen.
• Bare automatisk skanning: Erklæringen bygger på et verktøy som finner under en tredjedel av feilene, så den gir et for godt bilde.
• Uklare avvik: «Noen skjemaer har feil» hjelper verken brukeren eller utvikleren. Hvert avvik må si hvor feilen er og hvem den rammer.
• Ingen plan: Kjente feil står oppført år etter år uten dato for når de skal rettes.
• Tredjeparter glemt: Kart, chat og videospillere er ikke vurdert, selv om virksomheten har ansvaret for dem.
• Gjemt lenke: Erklæringen finnes, men brukerne finner den ikke.

De fleste forsvinner når erklæringen bygger på en ordentlig revisjon.

Hvor ofte må erklæringen oppdateres?

Erklæringen skal oppdateres minst én gang i året. I tillegg bør den oppdateres når løsningen endres så mye at statusen ikke lenger stemmer, for eksempel etter en redesign, et nytt skjema eller et nytt innloggingsløp.

Vi anbefaler å planlegge neste revisjon allerede når erklæringen publiseres. Da blir oppdateringen en fast rutine, og du unngår at erklæringen viser feil som for lengst er rettet, eller skjuler nye feil som har kommet til. Mellom revisjonene fanger automatiske tester de enkle feilene ved hver endring, mens den manuelle gjennomgangen tar resten én gang i året.

Unntaket for uforholdsmessig stor byrde

Loven (§ 18) åpner for unntak dersom kravene utgjør en «uforholdsmessig stor byrde». Unntaket er snevert og blir ofte misforstått. At det er dyrt eller teknisk krevende å rette en feil, er sjelden gyldig grunn alene.

Unntaket gjelder først og fremst hvis virksomheten måtte ha lagt ned kjernevirksomhet for å ha råd til tilpasningen, eller hvis teknologien som trengs ikke finnes. Bruker du unntaket, må det dokumenteres grundig i erklæringen. Vi hjelper deg å vurdere om unntaket gjelder, før det skrives inn.

Leverandører og tredjepartsløsninger

En av de vanligste årsakene til manglende samsvar er innhold fra tredjeparter. Det kan være kart som Google Maps, chatroboter, videospillere fra Vimeo og YouTube, eller rekrutteringssystemer som er bygget inn med iFrame.

Hovedregelen er at virksomheten som eier nettstedet, er juridisk ansvarlig for alt innhold på det, også tredjepartsløsningene. Du må derfor stille krav til underleverandørene. En grundig WCAG-revisjon avdekker feil i disse modulene, og rapporten kan du bruke aktivt i kontraktsforhandlinger og leverandøroppfølging for å kreve retting.

Leverer du selv programvare til det offentlige, er det motsatt. Det formelle ansvaret for erklæringen ligger hos oppdragsgiveren, men leverandøren har plikt til å levere løsninger som oppfyller kravene. I praksis må universell utforming være på plass i selve koden, og kunden trenger dokumentasjon for å fylle ut erklæringen riktig.

Uustatus.no har derfor en egen leverandørportal. Der kan leverandøren legge inn en ferdig leverandørvurdering, som kundene kan importere rett inn i sin egen erklæring. Det sparer kundene for mye arbeid, og en grønn leverandørvurdering er et konkurransefortrinn.

Hva koster det?

Tilgjengelighetserklæringen er sluttresultatet av en grundig teknisk revisjon, ikke et skjema som fylles ut for seg. Arbeidet krever manuell testing og teknisk forståelse. For mindre nettsteder starter en full WCAG-revisjon med tilgjengelighetserklæring på 35 000 kr.

For større løsninger avhenger prisen mest av hvor stort utvalget må være:

• Antall sidemaler: hver mal testes, uansett hvor mange sider som bruker den.
• Brukerreiser: innlogging, skjemaer i flere steg og kjøp tar lengre tid å teste enn rene innholdssider.
• Apper: en app trenger sin egen revisjon og sin egen erklæring.
• Utbedring: hvor mye som er galt, avgjør hva rettingen koster.

Utbedring av avvikene tar vi på timepris fra 1 500 kr, eller som fastpris når revisjonen har gjort omfanget tydelig.

Skal du bare oppdatere en erklæring vi har laget før, blir jobben mindre. Da tester vi det som er endret siden sist, kontrollerer at rettingene holder, og oppdaterer statusen for kravene som er berørt.

Fra rapport til løsning

Vi reviderer som utviklere. En lang liste med feil hjelper lite alene, så vi legger vekten på å rette dem. Når vi hjelper deg med tilgjengelighetserklæringen, får du:

• Teknisk revisjon: En fullstendig gjennomgang av kode og innhold mot WCAG 2.1 AA.
• Prioritert tiltaksliste: Feilene sortert etter alvorlighetsgrad, fra blokkerende feil til mindre avvik.
• Kodeeksempler: Vi viser utviklerne dine nøyaktig hvordan feilen rettes i koden, i React, Vue eller HTML.
• Selve erklæringen: Vi skriver tekstene til uustatus.no eller dokumentasjonen for EAA, sørger for at de er presise, og hjelper til med publiseringen.
• Ny test: Når feilene er rettet, tester vi på nytt, så erklæringen viser den faktiske statusen.

Alle hos oss har over ti års erfaring, og egne løsninger bygger vi etter WCAG 2.2 AA. En korrekt utfylt erklæring viser brukerne og tilsynet at du har kontroll på løsningen.