Alt for mange organisationer bruger meget tid og mange penge på at få dokumenteret deres tilgængelighedsfejl og -mangler, men formår ikke faktisk at få rettet fejlene. Og det nytter altså ikke noget.

Udgivet 12. maj 2025
Niels Abildgaard interviewer Anne Thyme Nørregaard

“En stor dansk bank havde købt stort ind i tilgængelighedstests. Hvert år lavede vi, for relativt mange penge, en stor gennemgang af deres hjemmeside, men på fire år var det kun lykkedes dem at løse omkring 25% af de fejl, der var dokumenteret i den første test,” fortæller Anne Thyme Nørregaard, “og samtidig havde de formået at introducere en tilsvarende mængde fejl i de nye features, de havde bygget.”

Det er desværre ikke et enestående tilfælde. Der er rigtig mange organisationer, især dem, hvor sikkerhed og dokumentation er vigtig, der bruger mange penge på at dokumentere deres fejl, men ikke formår effektivt at arbejde fejlene ned.

Det var måske fint nok, da webtilgængelighed var noget, man tænkte ind i sine systemer af sit gode hjerte (læs: det var det ikke, men for visse organisationer var det nemmere at retfærdiggøre), og fordi det værdimæssigt passede ind i ens organisation. Men fra juni 2025 træder den nye lov om tilgængelighed i produkter og tjenester i kraft, og nu følger der konkrete konsekvenser af ikke at overholde loven.

Betyder det så, at tilgængelighedstests med store, fine rapporter er spild? Nej – for en tilgængelighedserklæring bliver et krav under den nye lov, og den skal præcist beskrive, hvilke fejl og mangler der findes i ens systemer. Men man er ikke sikker, bare fordi man har beskrevet sine mangler præcist. Man skal altså også løse dem.

Hvor skal I starte?

Hvis I ikke ved, hvordan det står til med jeres tilgængelighed, kan det virke som en god idé at få et overblik i form af nogle rapporter, der opremser alle de fejl, der findes. Så har man et sted at starte!

Men vores erfaring er, at man ofte kan få et endnu bedre overblik ved at bruge mindre tid. En hurtig og ikke-fyldestgørende gennemgang af jeres systemer kan ofte give en god idé om, hvordan tilgængelighedsproblemer er fordelt, og dermed hvor I bør lægge jeres indsats.

Man kan ofte hurtigt identificere fejl, der fylder meget i en vurdering, men er ret hurtige at få rettet til. Og hvis man retter fejlene, behøver de ikke at komme med i den store, forkromede rapport. I stedet kan man bruge letvægtsafrapporteringsværktøjer til at synliggøre de mest signifikante fejl i et sprog, der kan forstås direkte af udviklere.

Der er to situationer, der bør føre til, at I får lavet en dybdegående rapport:

• Jeres system er i så god stand, at man ved en dybdegående rapport vil finde de småting, der er tilbage, og samtidig kan dokumentere, hvor godt det går.
• Der er for store fejl til, at I hurtigt kan få løst dem, og det er vigtigt at leve op til kravet om dokumentation.

Timingen er vigtig for en effektiv dokumentationsproces. Der er ingen grund til at blive ved med at lave dybdegående rapporter, der hvert år dokumenterer de samme fejl. Så når I først er forbi første runde dokumentation, er det på tide at fokusere på, hvordan I faktisk får rettet fejl, inden I får lavet en ny rapport.

Det’ kultur, jo

Anne fortæller videre om den store danske bank, hun har arbejdet sammen med: “De endte med at vente til den årlige test, før de fik feedback på fejl og mangler i deres nye features. Her fandt de ofte ud af, at de måder, de havde bygget på deres features på, ikke gjorde det muligt at sikre tilgængelighed.”

Det er altid rigtig træls at få en lang liste fejl eller ønsker et eller andet sted oppefra med besked om at fixe dem. For det meste mangler der kontekst, der forklarer, hvorfor det enkelte punkt er en fejl, og det er svært at vurdere, hvad der skal til for at løse den. Typisk er der for hver tilgængelighedsfejl mange mulige løsninger, men det kan være svært at vælge den rigtige – eller være sikker på, at man har tænkt over alt i implementationen af den nye løsning.

Det samme princip gælder for al softwareudvikling. Det er derfor, der er så mange tiltag, der sigter efter at binde forretningstanker og softwareudvikling tættere sammen, og at stille den relevante forretningsviden til rådighed for udviklere. Det betyder, at man som softwareudvikler eller designer ikke bare udfører punkter på en liste efter bedste evne, men har mulighed for at stille spørgsmål og styrke ens forståelse for problemet, så man kan implementere så god en løsning som muligt.

Selvom det er gængs viden, at den bedste software bygges af udviklere, der forstår de problemer, de løser, er det meget varierende, i hvor høj grad organisationer er gode til at efterleve det princip.

For mange organisationer kommer tilgængelighed lidt ind fra højre som en helt ny ting, man skal tage stilling til, og som man ikke er vant til at integrere ind i udviklingsprocessen. Og så kan man ende med, at det er jura-afdelingen, der er ansvarlig for compliance (herunder tilgængelighed) og troskyldigt sender lister med påkrævede udbedringer til udviklerne, der aldrig rigtig munder ud i, at man faktisk får reduceret mængden af fejl.

Det er kernen af problemet: Tilgængelighedsloven ændrer ved spillereglerne på en måde, der nødvendiggør, at man får tænkt tilgængelighed tænkt ind tidligt. Det er ikke længere godt nok at løse tilgængelighedsproblemer engang i fremtiden – de skal løses, før man lancerer. Og den nemmeste måde at opnå det på er at mindske sandsynligheden for, at de opstår.

Der skal ændres i udviklingskulturen. Udviklere og designere skal oplæres i at tænke tilgængelighed ind i alle dele af produktudviklingen, lidt ligesom vi i dag gør med mobilvenlige designs.

Det er i kulturændringen, I bør lægge de fleste af jeres kræfter, så I ikke spilder jeres penge på tilgængelighedsaudits.

Måske kan vi hjælpe

I deranged er vi ikke bare skarpe til tilgængelighed. Vi hjælper også virksomheder med at etablere, træne og styrke deres softwareudviklingsteams og tilsvarende for salg, marketing og operations. Det betyder, at vi er gode til at integrere langt ind i de virksomheder, vi samarbejder med, og hjælpe med at etablere varige kulturændringer, hvor der er behov for det.

Tag fat i os, hvis det lyder som noget, der giver mening i jeres organisation.