Gør tilgængelighed til en driftskompetence (ikke en eftertanke): en købsguide
Tilgængelighed er ikke et “nice-to-have”, man lægger på til sidst. I moderne websites og mobilapps er det en driftskompetence: noget der skal defineres, testes og vedligeholdes-release efter release.
Når tilgængelighed fejler, er det sjældent fordi nogen er ligeglade. Den mest almindelige årsag er drift: du lancerer med fornuftig tilgængelighed, og derefter får små designændringer, nye komponenter og content-opdateringer stille og roligt ødelagt tastaturnavigation, labels, kontrast eller skærmlæser-flows.
Denne guide er til dig, der køber et website eller en app og ønsker en enkel måde at bestille, verificere og fastholde tilgængelighed-uden at skulle være specialist i alle tekniske detaljer.
1) Definér målbare acceptkriterier (så “done” er tydeligt)
Start med at fastsætte standarden. For mange organisationer betyder det WCAG 2.2 AA (eller det niveau, jeres branche/krav kræver). Oversæt derefter standarden til konkrete checks, som kan valideres i QA.
Eksempler på køber-venlige acceptkriterier:
- Tastatur: Alle interaktive elementer kan nås med tastatur, fokus er altid synligt, og der er ingen tastaturfælder.
- Formularer: Felter har programmatiske labels, obligatoriske felter er tydelige, og fejl bliver annonceret korrekt.
- Kontrast: Tekst og essentielle UI-kontroller overholder minimumskrav-også i hover/focus/disabled-states.
- Billeder: Meningsfulde billeder har hjælpsom alt-tekst; dekorative billeder ignoreres af skærmlæsere.
- Dynamisk UI: Modals, toasts og live-opdateringer annoncerer ændringer korrekt (uden at forvirre brugeren).
Tip: Bed leverandøren om en én-sides tjekliste pr. sidetype/skabelon (fx marketing, produkt, checkout, dashboards), så godkendelse bliver ensartet.
2) Bed om dokumentation-ikke løfter
Tilgængelighed lyder ofte godt i tilbud, men du har brug for beviser. Kræv en kort dokumentationspakke som en del af leverancen:
- En audit-rapport med fund, alvorlighed og hvilke rettelser der er udført.
- En AT-testmatrix: hvilke browsere + skærmlæsere der er testet (for eksempel VoiceOver/Safari på macOS og NVDA/Chrome på Windows).
- Validering af kritiske flows: noter eller korte optagelser der viser, at nøglerejser kan gennemføres (tilmelding, køb, booking, kerneopgaver).
For mobilapps bør du også spørge, hvordan der er testet på iOS og Android (VoiceOver og TalkBack), især ved custom komponenter.
3) Indbyg automatiske tilgængelighedstjek i CI (så regressioner fanges)
Automatisering fanger ikke alt (især ikke alle brugbarhedsnuancer), men det er effektivt til at stoppe de typiske fejl, før de kommer i produktion.
Bed om at tilgængelighed bliver en del af build-pipelinen:
- Linting for basale semantik- og ARIA-problemer.
- Automatiserede UI-tests (ofte axe-baserede) på kritiske sider og almindelige UI-tilstande.
- Build-gates der fejler buildet, hvis der introduceres “kritiske” tilgængelighedsfejl.
Det gør tilgængelighed til en kontinuerlig praksis i stedet for en sjælden audit.
4) Gør tilgængelighedsleverancer eksplicitte i kontrakt og SOW
Hvis det ikke står i aftalen, er det svært at håndhæve. Jeres statement of work bør have tilgængelighed som en førsteordens leverance, fx:
- Acceptkriterier pr. skabelon eller feature.
- Udbedring inkluderet for fund under QA og UAT (med en tydelig proces og tidsplan).
- Dokumentation til designere og udviklere: komponentregler, content-guidance (alt-tekst, headingstruktur) og design tokens for kontrast.
- Re-audit efter lancering (fx efter 60–90 dage, eller kvartalsvist for hurtigt udviklende produkter).
En lille men vigtig kontrakt-detalje: definér hvordan tilgængelighedsissues triageres (blocker/major/minor), og hvad der er “acceptabelt” før go-live.
5) Let governance, så tilgængelighed ikke “driver” efter lancering
Du behøver ikke bureaukrati-du behøver ejerskab og en gentagelig rutine:
- Udpeg en tilgængelighedsansvarlig på produktsiden og en teknisk ansvarlig på leverandør-/team-siden.
- Inkludér tilgængelighed i jeres definition of done (design review, QA og release checks).
- Lav en kvartalsvis gennemgang af top-flows og nye komponenter siden sidste release.
God tilgængelighed er sjældent ét “projekt”. Det er resultatet af konsekvente valg og gentagelige checks.
Hos Jensen Technologies har vi bygget og driftet websites og mobilapps i mange år, og vi har set forskellen på “vi prøver at være tilgængelige” og “tilgængelighed er en del af, hvordan vi leverer.” Den anden tilgang reducerer risiko, forbedrer brugeroplevelsen for alle og øger ofte konvertering og fastholdelse.
Hvis du vil vende tilgængelighedskrav til et kommende projekt, gennemgå en leverandørs tilbud eller etablere praktisk test og governance for et eksisterende produkt, så tag gerne kontakt-vi hjælper gerne med at gøre tilgængelighed til en stabil kapabilitet i din forretning.