Tilgængelighed, der kun kontrolleres én gang om året, i en engangsmanuel gennemgang, eroderer næsten altid hurtigt – enhver lille kodeopdatering kan ødelægge noget, der allerede var rettet. Løsningen: Indbygg tilgængelighedstest i selve udviklingsprocessen (CI/CD) som et automatiseret trin, så problemer bliver fanget, før de når produktionen. Denne artikel forklarer hvordan.

Kort sagt – hvad denne artikel dækker

  1. Hvorfor er et engangstjek ikke nok
  2. Hvad automatiserede værktøjer i CI/CD-pipelinen kan fange
  3. Hvor manuel test stadig er nødvendig
  4. Sådan implementeres det i praksis

Hvorfor er et engangstjek ikke nok

Et udviklingsteam, der sender opdateringer hver uge eller nogle gange hver dag, kan ikke stole på en årlig tilgængelighedsrevision for at opretholde løbende overholdelse. En ny komponent tilføjet uden tilgængelighed i tankerne, eller en CSS-ændring, der ved et uheld sænker kontrasten, kan bryde tilgængelighed, der allerede var rettet - og ingen bemærker det, før en bruger eller en klage afslører det. Det samme princip gælder også for dokumenter - se vores vejledning omkortlægning af almindelige fejl.

Hvad automatiserede værktøjer i CI/CD-pipelinen kan fange

Værktøjer som axe-core, Pa11y eller Lighthouse CI kan køre automatisk ved hver pull-anmodning eller før hver implementering – inden for få sekunder tjekker de ting som: farvekontrast, forkerte eller duplikerede ARIA-tags, manglende alt-tekst, manglende formularetiketter og forkert overskriftsrækkefølge. Hvis kontrollen mislykkes, blokeres pull-anmodningen automatisk fra at flette - ligesom en almindelig kodegennemgang eller en mislykket enhedstest.

💡 Praktisk tip

Start i "advarselstilstand" (ikke-blokerende) i et par uger for at se, hvor mange problemer der allerede eksisterer i kodebasen, og først efter en indledende oprydning forvandler checken til en implementeringsblokering - på den måde bliver teamet ikke "fast" og står over for hundredvis af fejl på dag ét.

Hvor manuel test stadig er nødvendig

Ligesom med dokumenttest, fanger automatiserede værktøjer i CI/CD-pipelinen klare strukturelle problemer, men de kan ikke bedømme den faktiske brugeroplevelse: om tastaturnavigation giver mening, om en skærmlæser "fortæller en sammenhængende historie" på siden, eller om en tilpasset komponent (som en karrusel eller modal) kan bruges i den virkelige verden. Derfor er det værd at parre de løbende automatiserede kontroller med en periodisk manuel revision - for eksempel kvartalsvis.

Sådan implementeres det i praksis

  1. Vælg et testværktøj, der passer til din teknologistack (øksekerne til de fleste JavaScript-projekter, Lighthouse CI til browserbaserede projekter).
  2. Kør det som et trin i din CI-pipeline - normalt som en GitHub-handling, et GitLab CI-job eller et tilsvarende trin i et hvilket som helst CI/CD-værktøj, du bruger.
  3. Indstil en klar fejltærskel (for eksempel: ingen "kritiske"-niveau problemer pr. øksekerne), før kontrollen bliver en blokering.
  4. Dæk også dine PDF-filer: Hvis din organisation genererer dokumenter automatisk (fakturaer, rapporter), overvej også at tilføje automatisk scanning for dem som en del af udgivelsesprocessen.

Vil du også tilføje automatiseret PDF-test til din proces?

Vores værktøj scanner PDF-filer og giver hvert dokument en tilgængelighedsscore – du kan køre det som en periodisk kontrol sammen med din CI/CD-proces.

Scan dit websted gratis ←

Efter scanning kan du også gøre de dokumenter, der blev fundet, tilgængelige direkte og gratis viaAccessiDoc.