Guider
WCAG-rapport: eksempel, innhold og metode
Kjør din første skanning gratis og lag en PDF-rapport med funn fra ditt eget nettsted. Se også hva rapporten bør inneholde, og hvordan resultatene bør følges opp.
Av Eivind Pihl Martinsen, Synli.aiSist oppdatert 1. september 2026
En WCAG-rapport er først nyttig når en utvikler kan finne feilen, en produkteier kan forstå konsekvensen, og en ny vurderer kan gjenta testen. En prosent, en lang liste med verktøyvarsler eller et grønt symbol er ikke nok. Rapporten må fortelle hva som ble testet, med hvilken metode, hvilke bevis som finnes, hva som fortsatt er uavklart – og hvem som følger opp.
Fra skanning til et gjennomgått arbeidsgrunnlag
- Avgrens skanningenVelg løsning, sider, innlogging, roller og tilstander verktøyet faktisk kan nå
- Samle funn og bevisKoble observerte problemer til side, WCAG-kriterium, alvorlighet og utbedringsforslag
- Gjennomgå resultateneBekreft eller avvis funnene, marker det som er usikkert, og dokumenter de faglige vurderingene
- Eksporter rapportenDel det registrerte arbeidsgrunnlaget uten å skjule avgrensninger eller manglende dekning
- Rett og test på nyttKoble tiltak til ansvar og versjon, og verifiser resultatet etter endringen
Hva en tilgjengelighetsrapport bør inneholde
| Del | Ta med | Hvorfor |
|---|---|---|
| Identitet og versjon | Løsning, miljø, URL/appversjon, dato og rapport-ID | Knytter resultatet til det som faktisk ble evaluert på et bestemt tidspunkt. |
| Omfang | Inkluderte og utelatte områder, roller, sider, tilstander, språk og brukeroppgaver | Hindrer at et lite utvalg blir tolket som dekning av hele produktet. |
| Mål og grunnlag | WCAG-versjon, nivå, aktuelt kriteriesett og formålet med evalueringen | Gjør det tydelig hva resultatene sammenlignes med – uten å avgjøre juridisk virkeområde automatisk. |
| Metode og verktøy | Automatiske og manuelle tester, verktøyversjoner, nettlesere og hjelpemidler | Viser hvordan resultatet ble produsert og hvilke begrensninger metodene har. |
| Utvalg | Representative sider, felles komponenter, komplette prosesser og begrunnelse for valget | Gjør evalueringen etterprøvbar og synliggjør hull i dekningen. |
| Funn | Kriterium, side eller tilstand, bevis, konsekvens for brukerne, alvorlighet, forslag og status | Gir teamet nok informasjon til å forstå, prioritere, rette og teste på nytt. |
| Vurderere | Navn eller rolle, relevant kompetanse, beslutning, dato og eventuell merknad | Skiller verktøyresultatet fra en dokumentert faglig vurdering. |
| Begrensninger og oppfølging | Kriterier som ikke er testet, utilgjengelige områder, usikkerhet, ansvar, frist og ny test etter retting | Forebygger en sterkere konklusjon enn bevisene støtter. |
Synli-eksport og grundig WCAG-evaluering er ikke det samme
| Tema | Synli-eksport | Grundig WCAG-evaluering |
|---|---|---|
| Formål | Prioritere og dele registrerte skannerfunn og vurderinger. | Evaluere hvor godt et definert digitalt produkt møter et bestemt WCAG-mål. |
| Omfang | Sidene og tilstandene skanneren nådde i den valgte kjøringen. | Et entydig definert produktomfang som utforskes før utvalget bestemmes. |
| Utvalg | Nettskannerens dekning og eventuelle innloggede sider som er åpnet manuelt. | Et begrunnet, representativt utvalg med felles visninger og komplette prosesser. |
| Metoder | Støttede automatiske og KI-assisterte kontroller, supplert med registrert gjennomgang. | Alle relevante kriterier vurdert med nødvendig verktøybruk, manuell testing og fagkompetanse. |
| Konklusjon | Status og dokumentasjon for registrerte funn i det testede omfanget. | Dokumenterte resultater og avgrensninger; en eventuell evalueringsuttalelse må være presis og støttet av metoden. |
| Riktig bruk | Utvikling, prioritering, leverandøroppfølging, regresjon og underlag for videre testing. | Faglig evaluering, styring og dokumentasjon der bestillerens formål krever større bredde og dybde. |
WCAG-EM 2: fem trinn fra omfang til rapport
W3C publiserte WCAG Evaluation Methodology (WCAG-EM) 2.0 som en Group Note 23. juli 2026. Metoden gir en verktøyuavhengig struktur for grundig evaluering av nettsteder, apper og andre digitale produkter. Den legger ikke til nye WCAG-krav, men beskriver hvordan evalueringen kan gjennomføres og rapporteres.
- Definer omfangetAvklar produkt, mål, WCAG-nivå, støttegrunnlag og eventuelle tilleggskrav
- Utforsk produktetFinn felles visninger, viktig funksjonalitet, innholdstyper og nødvendige teknologier
- Velg representativt utvalgTa med strukturert og tilfeldig utvalg samt komplette brukerprosesser
- Evaluer utvalgetVurder relevante suksesskriterier, tilgjengelighetsstøtte og hele prosesser
- Rapporter funneneDokumenter hvert trinn, resultater, avgrensninger og eventuelle uttalelser
W3C forutsetter solid kunnskap om WCAG, tilgjengelig design, hjelpemidler, evalueringsteknikker og hvordan mennesker med ulike funksjonsnedsettelser bruker digitale produkter. Verktøy kan gjøre evalueringen mer effektiv og hjelpe med utvalg, men kan ikke overta denne kompetansen.
Skriv hvert funn slik at det kan rettes og testes på nytt
- Gi funnet en stabil ID og koble det til riktig WCAG-kriterium og avtalt kravgrunnlag.
- Oppgi nøyaktig side, skjerm, komponent, rolle og tilstand – gjerne med selektor eller skjermbilde når det er trygt.
- Beskriv det observerte problemet uten å kopiere en generell kriterietekst som om den var bevis.
- Forklar konsekvensen for brukerne: hvem som blir hindret, i hvilken oppgave og hvor alvorlig hindringen er.
- Skill mellom automatiske treff, faglig bekreftede avvik, falske treff, kriterier som ikke er relevante, og uavklarte resultater.
- Foreslå en testbar retting og registrer ansvar, versjon og dato for ny test etter retting.
- Behold opprinnelig bevis og ny teststatus slik at endringen kan etterprøves senere.
En kopierbar disposisjon for din egen rapport
- Sammendrag – formål, viktigste barrierer, prioriteringer og tydelige forbehold.
- Produkt og omfang – versjon, miljø, målgrupper, inkluderte og utelatte områder.
- Kravgrunnlag – WCAG-versjon, nivå, kriteriesett og eventuelle kontraktskrav.
- Metode og kompetanse – utvalg, verktøy, manuelle tester, hjelpemidler og vurderere.
- Dekning og begrensninger – sider, tilstander, komplette prosesser og kjente hull.
- Resultater – status per kriterium med sporbare funn, bevis og konsekvens for brukerne.
- Tiltaksplan – prioritet, anbefaling, ansvar, frist og avhengigheter.
- Ny test etter retting og endringslogg – hva som ble kontrollert på nytt, av hvem og i hvilken versjon.
- Kilder og vedlegg – kriterielenker, verktøyutdrag, skjermbilder og eventuelle eksporter fra skanninger.
Hvor Synli passer inn – og hvor ansvaret fortsatt ligger
Synli kan brukes tidlig i arbeidet til å skanne tilgjengelige sider, samle støttede funn, koble dem til WCAG, dokumentere registrerte vurderinger og eksportere et konsistent arbeidsgrunnlag. Det er nyttig før lansering, i feilretting, ved leverandøroppfølging og som en repeterbar regresjonskontroll.
Spørsmål og svar
Hva bør en WCAG-rapport inneholde?
Minst et entydig testomfang, dato og versjon, WCAG-mål, metode og verktøy, et representativt utvalg, ansvarlige vurderere, resultat per kriterium, konkrete bevis, konsekvens for brukerne, rettingsforslag, avgrensninger og en plan for ny test etter retting. En kort eksport fra en skanning kan være et vedlegg eller arbeidsgrunnlag, men må ikke fremstilles som en fullstendig evaluering hvis disse delene mangler.
Er en automatisk WCAG-rapport nok til å hevde samsvar?
Nei. Uu-tilsynet sier at automatiske verktøy ikke kan erstatte manuell testing fullt ut. WCAG-EM krever blant annet definert omfang, representativt utvalg, komplette prosesser, relevant ekspertise og evaluering av det valgte utvalget. En skannerapport dokumenterer det verktøyet faktisk undersøkte; den beviser ikke at hele løsningen oppfyller alle krav.
Kan jeg lage en gratis WCAG-rapport i PDF-format med Synli?
Ja. Den første skanningen er gratis innenfor sidegrensen som vises når du starter. Når skanningen er ferdig og funnene som krever gjennomgang er vurdert, kan du laste ned en PDF-rapport med resultatene fra ditt eget nettsted. Rapporten er et internt arbeidsgrunnlag, ikke automatisk en fullstendig WCAG-EM-evaluering, tilgjengelighetserklæring eller samsvarserklæring.
Hva er forskjellen på en WCAG-rapport og en tilgjengelighetserklæring?
En WCAG-rapport dokumenterer testomfang, metode, resultater og oppfølging. En tilgjengelighetserklæring er en offentlig erklæring med bestemte krav til innhold og ansvar i regelverket som gjelder virksomheten. Testrapporten kan være et underlag, men blir ikke automatisk en gyldig erklæring.
Lager Synli en komplett WCAG-EM-evaluering?
Nei. Synli kan skanne tilgjengelige sider og tilstander, strukturere WCAG-knyttede funn, registrere gjennomgang og eksportere et arbeidsgrunnlag. Verktøyet velger ikke alene et representativt utvalg, gjennomfører ikke alle nødvendige manuelle tester, sertifiserer ikke løsningen og avgir ikke en juridisk samsvarskonklusjon.