En tilgængelig hjemmeside er ikke dokumenteret, fordi den har bestået en automatisk test eller fordi leverandøren erklærer, at den følger WCAG. Dokumentationen skal kunne forklare, hvad der er testet, hvad der ikke er, hvilke fejl der er fundet, og hvordan ansvaret er placeret. Denne guide til WCAG-dokumentation hjælper jer med at etablere et spor, der kan bruges af både udviklere, ledelse, indkøb og myndigheder.
WCAG-dokumentation er ikke kun relevant ved lancering. Den er en del af den løbende forvaltning af en digital løsning. Det gælder særligt for offentlige organisationer, men også private virksomheder, hvor tilgængelighedskrav kan følge af sektorregler, kontrakter eller European Accessibility Act.
Hvad skal WCAG-dokumentation bevise?
Formålet er ikke at producere et stort dokument til en mappe. God dokumentation gør det muligt at træffe beslutninger på et oplyst grundlag. Den viser, hvilket tilgængelighedsniveau løsningen sigter mod, hvordan det er vurderet, og hvilke kendte afvigelser der fortsat findes.
WCAG er bygget op omkring fire principper: Indholdet skal være opfatteligt, anvendeligt, forståeligt og robust. I praksis omsættes principperne til konkrete succeskriterier, for eksempel tekstalternativer, tastaturnavigation, fokusmarkering, kontrast, overskrifter, formularfejl og korrekt semantik i koden.
Dokumentationen bør derfor ikke nøjes med formuleringen “WCAG 2.1 AA-kompatibel”. Den formulering er ofte for bred, især hvis der findes kendte fejl, redaktionelt indhold uden alt-tekster eller tredjepartskomponenter, som ikke er testet. En præcis vurdering er mere værdifuld end en perfekt erklæring, som ikke kan underbygges.
Start med afgrænsning og ansvar
Før I tester, skal I beslutte, hvad dokumentationen omfatter. Et website kan bestå af langt mere end almindelige indholdssider: login, selvbetjening, checkout, dokumentarkiv, indlejrede videoer, cookie-banner, kort, chat og integrationsbaserede funktioner. Hver del kan have sin egen tekniske ejer og sin egen risikoprofil.
Beskriv den konkrete løsning med version, domæner, sprog, centrale brugerrejser og relevante brugergrupper. Angiv også, om mobilapp, PDF-filer, e-mails eller ekstranet indgår i vurderingen. Det forebygger en klassisk misforståelse, hvor en test af forsiden senere bruges som dokumentation for hele den digitale platform.
Ansvar skal være synligt. Udvikling har ansvar for kode, komponenter og tekniske fejl. Redaktionelle brugere har ansvar for tilgængelige tekster, overskrifter, links, billeder og dokumenter. Produktansvarlige prioriterer fejlrettelser, mens drift og leverandørstyring skal sikre, at opdateringer, integrationer og nye moduler ikke introducerer nye barrierer.
Når ansvaret ikke er beskrevet, bliver WCAG ofte en opgave mellem to stole. Det er særligt risikabelt i løsninger med flere leverandører, hvor eksempelvis betalingsflow, videoplayer eller samtykkeløsning er leveret af tredjeparter.
Guide til WCAG-dokumentation: Byg et testgrundlag
Et brugbart testgrundlag kombinerer automatiske værktøjer med manuel gennemgang. Automatiske scanninger er gode til at finde gentagne fejl som manglende labels, tomme links og svage kontraster. Men de kan ikke afgøre, om en alternativ tekst giver mening, om tastaturflowet er logisk, eller om en formularfejl er forståelig for brugeren.
Dokumentér derfor testmetoden, ikke kun resultatet. Notér hvilken WCAG-version og hvilket niveau I vurderer imod, datoen for testen, hvilke skabeloner og brugerrejser der er gennemgået, samt hvilke browsere og hjælpemidler der er anvendt. Hvis testdækningen er stikprøvebaseret, skal det fremgå tydeligt.
En typisk manuel gennemgang omfatter tastaturnavigation uden mus, synligt fokus, korrekt rækkefølge mellem interaktive elementer, overskriftsstruktur, formularer, fejlmeddelelser, dialogbokse og dynamisk indhold. Brug af skærmlæser bør indgå, når løsningen har komplekse funktioner, men det skal ske med en klart beskrevet testopsætning. En tilfældig kontrol på én computer er ikke det samme som en reproducerbar test.
For en webshop bør dokumentationen prioritere de brugerrejser, der har direkte forretningsmæssig betydning: produktsøgning, filtrering, valg af variant, kurv, levering, betaling og ordrebekræftelse. For et intranet eller en selvbetjeningsløsning vil roller, rettigheder, tabeller, vedhæftede dokumenter og arbejdsgange ofte være vigtigere end en visuel gennemgang af forsiden.
Registrér fund, så de kan rettes
En fejlrapport skal give et udviklingsteam mulighed for at genskabe og rette problemet uden gætterier. Hvert fund bør have en entydig identifikation, en placering eller en vej til at genskabe fejlen, det relevante WCAG-succeskriterium og en kort beskrivelse af konsekvensen for brugeren.
Tilføj alvorlighed, ansvarlig ejer, forventet løsningsdato og status. Det er også nyttigt at skelne mellem fejl i design, kode, indhold og tredjepartsløsninger. Den skelnen gør det langt lettere at prioritere og at se, om de samme problemer vender tilbage.
Beskriv den forventede adfærd frem for kun den tekniske mangel. I stedet for at skrive “mangler aria-label” kan I skrive, at en bruger med skærmlæser ikke kan afgøre, hvad en ikonknap gør. Den tekniske løsning kan stadig være en aria-label, men konsekvensen gør prioriteringen forståelig uden for udviklingsteamet.
Ikke alle fund har samme vægt. En manglende fokusmarkering i et kritisk betalingsflow kan blokere en bruger helt. En mindre upræcis alternativ tekst kan være væsentlig, men typisk ikke lige så akut. Prioriteringen skal afspejle både brugerens barriere, løsningens formål og hvor ofte komponenten bruges.
Håndtér undtagelser og tredjepart ærligt
Nogle afvigelser kan ikke løses straks. Det kan skyldes en ældre platform, en standardkomponent med begrænsninger eller en ekstern integration, som virksomheden ikke selv udvikler. Det fritager ikke organisationen for at registrere forholdet.
Dokumentér i stedet, hvad afvigelsen er, hvem der ejer den, hvilke brugere den påvirker, om der findes et alternativ, og hvornår den skal vurderes igen. Hvis et tredjepartsværktøj er forretningskritisk, bør tilgængelighed være et dokumenteret krav i leverandørdialogen og ved nye indkøb.
Her er der en reel afvejning. En hurtig integration kan give funktionalitet på kort sigt, men den kan samtidig skabe en permanent tilgængelighedsrisiko, hvis leverandøren ikke kan eller vil rette fejl. Åbne standarder, dokumenterede grænseflader og løsninger, I kan flytte eller vedligeholde, giver bedre kontrol over den risiko.
Gør dokumentationen driftsegnet
WCAG-status ændrer sig, når redaktører publicerer nyt indhold, når et tema opdateres, eller når en integration ændrer sit interface. Derfor skal dokumentationen indgå i den almindelige udviklings- og driftsproces frem for at være en årlig engangsøvelse.
Knyt relevante tilgængelighedskrav til designreview, udviklingsopgaver, kvalitetssikring og release-noter. Ved større ændringer bør I teste de berørte brugerrejser før produktion. Ved mindre løbende ændringer kan faste stikprøver og periodiske scanninger være tilstrækkelige, hvis de suppleres med manuel kontrol.
Gem testresultater, beslutninger og rettelser et sted, hvor de kan findes ved leverandørskifte, audit eller intern opfølgning. Formatet er mindre vigtigt end ejerskab og sporbarhed. En dokumentation, der kun ligger i en enkelt konsulents indbakke, er ikke en kontrollerbar dokumentation.
For offentlige digitale løsninger skal dokumentationen desuden understøtte tilgængelighedserklæringen. Erklæringen er rettet mod brugeren, mens den interne dokumentation skal kunne forklare vurderingen bag og vise, hvordan rapporterede problemer håndteres.
Hvornår er dokumentationen god nok?
Den er god nok, når I kan svare konkret på fem spørgsmål: Hvad er omfattet? Hvad er testet? Hvilke fejl kender I? Hvem retter dem? Hvornår følger I op? Hvis svarene kan findes hurtigt og er baseret på faktiske testresultater, har I et brugbart grundlag.
Det betyder ikke, at løsningen skal være fejlfri, før dokumentationen har værdi. Tværtimod er den mest troværdige dokumentation den, der gør restarbejdet synligt og omsætter det til ansvarlige, prioriterede handlinger. Det er sådan tilgængelighed bliver en del af kvaliteten i jeres digitale løsning – også efter næste release.
