Hva er WCAG? En forklaring på vanlig norsk

Hva WCAG er, på vanlig norsk: de fire prinsippene, nivåene, hva norsk lov krever, og hvilke deler av sjekkingen du kan automatisere.

AI gjør at hvem som helst kan publisere et nettsted på en ettermiddag. WCAG er standarden som avgjør om alle faktisk kan bruke det.

WCAG står for Web Content Accessibility Guidelines, retningslinjer for tilgjengelig innhold på nett. Det er et sett med regler, publisert av W3C (gruppen som vedlikeholder standardene bak nettet), for å gjøre nettsteder og apper brukbare for personer med nedsatt funksjonsevne. Det gjelder folk som bruker skjermleser, folk som navigerer med tastatur i stedet for mus, folk som trenger teksting, og folk som forstørrer teksten til 200%.

Én tanke ligger under alt sammen: kan alle bruke dette, ikke bare noen som ser og klikker slik du gjør.

De fire prinsippene: POUR

Hver WCAG-regel kan spores tilbake til fire ord. På engelsk blir det forkortelsen POUR.

Mulig å oppfatte (Perceivable). Folk får tak i innholdet. Bilder har tekstalternativer, video har teksting, tekst har nok kontrast mot bakgrunnen.
Mulig å betjene (Operable). Folk kan bruke det. Alt fungerer med tastatur, ingenting blinker så kraftig at det kan utløse anfall, folk får nok tid til å lese og handle.
Forståelig (Understandable). Folk kan følge det. Teksten er lesbar, nettstedet oppfører seg forutsigbart, feilmeldinger sier hva som gikk galt og hvordan man retter det.
Robust (Robust). Det holder. Koden er ryddig nok til at hjelpemidler, som en skjermleser, kan tolke den pålitelig både nå og når verktøyene endrer seg.

Husker du ingenting annet, husk POUR. Det meste av tilgjengelighetsarbeid er bare ett av disse fire ordene brukt på en konkret ting.

De tre nivåene: A, AA, AAA

WCAG sorterer reglene i tre samsvarsnivåer.

Nivå A er gulvet. Bommer du her, er nettstedet ødelagt for hele grupper av mennesker.
Nivå AA er målet i praksis. Det er dette de fleste lover og kontrakter mener når de sier "tilgjengelig".
Nivå AAA er den høyeste lista. Nyttig å sikte deler av et nettsted mot, sjelden krevd for hele nettstedet.

Når noen sier at et nettsted skal være "WCAG-kompatibelt", mener de nesten alltid AA. Det er tallet du skal holde i hodet.

Hvilken versjon

WCAG har versjoner som programvare. 2.0 (2008), 2.1 (2018) og 2.2 (2023) er de som er i bruk. Hver versjon bygger stort sett videre på den forrige: 2.2 la til ni nye krav og fjernet ett utdatert (4.1.1 Parsing, som moderne nettlesere gjorde overflødig). Sikter du mot WCAG i dag, sikt mot 2.2 på nivå AA, så har du i praksis dekket de tidligere versjonene også.

Hvorfor dette gjelder i Norge

Dette er ikke bare god praksis, det er lov, og loven er skrevet i WCAG sine egne termer. Den norske forskriften om universell utforming av IKT-løsninger finner ikke opp egne regler, den peker på WCAG. Så å lære WCAG og å følge norsk lov er samme oppgave. Den håndheves av uu-tilsynet (Tilsynet for universell utforming av IKT) under Digitaliseringsdirektoratet.

Lista avhenger av hvem du er:

Privat sektor (de fleste virksomheter, en liten klinikk, et enkeltpersonforetaks nettsted): WCAG 2.0 på nivå A og AA, 35 suksesskriterier. Det er de 38 i 2.0 AA minus tre mediekriterier (forhåndsinnspilt og direkte lyd og video) som forskriften gjør unntak for.
Offentlig sektor: den strengere standarden EN 301 549, som trekker inn WCAG 2.1 på nivå A og AA, tolv kriterier mer enn gulvet for privat sektor. Offentlige virksomheter må også publisere en tilgjengelighetserklæring via uustatus.no, og en utvalgt virksomhet som ikke leverer en innen 15 virkedager, risikerer en dagmulkt på 5 000 kroner.

Så er det det som kommer. EUs tilgjengelighetsdirektiv (European Accessibility Act) har gjeldt i EU siden 28. juni 2025 og trekker langt flere digitale produkter og tjenester fra privat sektor inn under kravene. Per juni 2026 har Norge ennå ikke innlemmet det formelt i norsk rett: det er ikke skrevet inn i nasjonal lov ennå. Det arbeidet pågår og ventes å bygge på likestillings- og diskrimineringsloven, så foreløpig er det retningen det går, ikke en gjeldende norsk plikt. Å bygge mot den høyere lista i dag er den billige måten å være klar på.

Her er gevinsten. Fordi loven er definert i WCAG, slipper du å lære to ting. Treffer du WCAG 2.2 på nivå AA, klarer du dagens norske gulv for privat sektor (2.0 AA) med god margin, og du står allerede der EUs tilgjengelighetsdirektiv flytter alle. Én standard, lært én gang, dekker både praksisen og loven.

AI-delen de fleste hopper over

Her er delen som henger sammen med alt annet jeg underviser i. AI-verktøy, inkludert no-code-byggerne, lager gjerne et nettsted som ser ferdig ut og i det stille er utilgjengelig. Knappen har ingen merkelapp en skjermleser kan lese. Kontrasten er for lav. Skjemaet gir en feilmelding en tastaturbruker ikke når frem til. Nettstedet ser riktig ut på din skjerm og svikter for den personen det aller mest må fungere for.

Automatiske verktøy (Lighthouse, axe, WAVE) fanger kanskje en tredjedel til halvparten av WCAG-feilene. De er verdt å kjøre. De er ikke svaret. Resten må et menneske verifisere, den samme vanen som går igjen i all praktisk AI: ikke stol på resultatet fordi det ser ferdig ut, sjekk det verktøyet ikke kan se.

Noen sjekker hvem som helst kan gjøre i dag, helt uten kode:

Trekk ut musa. Bla gjennom nettstedet med bare tastaturet. Når du frem til og kan bruke alt, og ser du hvor du er?
Kjør én automatisk skann. Installer den gratis axe- eller WAVE-utvidelsen i nettleseren og les hva den flagger.
Sjekk kontrasten. Bruk en kontrastsjekker på hovedteksten og knappene. Sikt mot AA-verdiene.
Les din egen alt-tekst. Hvert meningsbærende bilde skal beskrive hva det viser, ikke si "bilde".

Ingenting av dette gjør deg til ekspert på tilgjengelighet. Men det flytter nettstedet ditt fra "ser ferdig ut" til "fungerer for flere mennesker", som er hele poenget med WCAG i én setning.

Hva du kan automatisere, og hva du ikke kan

Du vil ikke kjøre disse sjekkene for hånd hver gang du endrer noe. De delene som gjentar seg, bør gå av seg selv. Slik ser det ut i praksis, fra minst til mest oppsett.

Skann ved hver publisering. Koble en tilgjengelighetssjekker inn i steget som publiserer nettstedet, slik at hver endring blir skannet før den går live. De vanlige verktøyene er axe-core, Lighthouse CI og pa11y. Still den til å flagge ethvert nytt AA-avvik. Du endrer en knapp, sjekken kjører, og du oppdager det med en gang i stedet for tre uker senere.
Skann etter en tidsplan. Bygger du på en no-code-plattform uten et publiseringssteg å koble deg på, sett heller sjekken på en timer. En liten automatisering, et verktøy som n8n er laget nettopp for dette, kan besøke sidene dine én gang i uka, kjøre skannen og sende deg et sammendrag på vanlig språk over hva som er endret. Sett det opp én gang og glem det.
Gjør skannresultatet om til rettelser med AI. En rå tilgjengelighetsrapport leser som feilkoder. Lim den inn i Claude og be den forklare hvert problem på vanlig norsk og foreslå den konkrete endringen. Bruk samme grep på de kjedelige delene: lag utkast til alt-tekst for en bunke bilder, eller la Claude gå gjennom én komponent for tilgjengelighetsfeil før du publiserer den.

Så grensen, for det er her de fleste påstander om "vi automatiserte tilgjengelighet" stille faller fra hverandre. Automatisering fanger pålitelig det maskinen kan sjekke: manglende merkelapper, lav kontrast, ødelagt struktur, den tredjedelen til halvparten fra tidligere. Den er langt svakere på å vurdere om merkelappene gir mening, om tastaturflyten henger på greip, eller om en skjermleserbruker faktisk får fullført oppgaven. Den delen forblir menneskelig, i hvert fall foreløpig, og selv når verktøyene blir bedre på det, er det fortsatt du som tar avgjørelsen om å stole på resultatet.

Mønsteret er altså tre steg, og bare det midterste er nytt: oppdag automatisk, rett med AI-hjelp, verifiser for hånd. Maskinen flagger, AI-en lager utkast til rettelsen, mennesket bekrefter at den faktisk fungerer. Det er vanen fra pålitelig AI brukt på tilgjengelighet: automatiser den delen som gjentar seg, overlat vurderingen til et menneske, og la aldri det grønne haket erstatte noen som faktisk har tabbet seg gjennom det.

Jeg følger opp med en kort gjennomgang: hvordan sjekke ditt eget nettsted mot WCAG på rundt 20 minutter, og hvordan koble på den automatiske skannen slik at du bare gjør den manuelle runden når noe faktisk har endret seg. Er det nyttig for deg, er det den neste å lese.