Tillgänglighet som bara kontrolleras en gång om året, i en manuell engångsgranskning, urholkas nästan alltid snabbt – vilken liten koduppdatering som helst kan bryta något som redan var fixat. Lösningen: bygg in tillgänglighetstester i själva utvecklingsprocessen (CI/CD) som ett automatiserat steg, så att problem fastnar innan de når produktionen. Den här artikeln förklarar hur.
Kort sagt – vad den här artikeln täcker
Varför räcker det inte med en engångskontroll
Ett utvecklingsteam som skickar uppdateringar varje vecka, eller ibland varje dag, kan inte lita på en årlig tillgänglighetsrevision för att upprätthålla kontinuerlig efterlevnad. En ny komponent som läggs till utan tillgänglighet i åtanke, eller en CSS-ändring som av misstag sänker kontrasten, kan bryta tillgängligheten som redan var fixad – och ingen märker det förrän en användare eller ett klagomål avslöjar det. Samma princip gäller även för dokument — se vår guide ommappning av vanliga fel.
Vad automatiserade verktyg i CI/CD-pipelinen kan fånga
Verktyg som axe-core, Pa11y eller Lighthouse CI kan köras automatiskt vid varje pull-begäran eller före varje distribution – inom några sekunder kontrollerar de saker som: färgkontrast, felaktiga eller duplicerade ARIA-taggar, saknad alt-text, saknade formuläretiketter och felaktig rubrikordning. Om kontrollen misslyckas, blockeras pull-begäran automatiskt från att slås samman - precis som en vanlig kodgranskning eller ett misslyckat enhetstest.
💡 Praktiskt tips
Börja i "varningsläge" (icke-blockerande) i några veckor för att se hur många problem som redan finns i kodbasen, och först efter en första rensning förvandla kontrollen till en distributionsblockerare - på så sätt "fastnar inte teamet" och ställs inför hundratals fel på dag ett.
Där manuell testning fortfarande behövs
Precis som med dokumenttestning, fångar automatiserade verktyg i CI/CD-pipelinen tydliga strukturella problem, men de kan inte bedöma den faktiska användarupplevelsen: om tangentbordsnavigering är vettigt, om en skärmläsare "berättar en sammanhängande historia" på sidan eller om en anpassad komponent (som en karusell eller modal) är användbar i verkligheten. Det är därför det är värt att para ihop de pågående automatiserade kontrollerna med en periodisk manuell revision – till exempel kvartalsvis.
Hur man implementerar det i praktiken
- Välj ett testverktyg som passar din teknikstack (axe-core för de flesta JavaScript-projekt, Lighthouse CI för webbläsarbaserade projekt).
- Kör det som ett steg i din CI-pipeline - vanligtvis som en GitHub Action, ett GitLab CI-jobb eller ett motsvarande steg i vilket CI/CD-verktyg du än använder.
- Sätt en tydlig feltröskel (till exempel: inga "kritiska"-nivåproblem per axelkärna) innan kontrollen blir en blockerare.
- Täck även dina PDF-filer: om din organisation genererar dokument automatiskt (fakturor, rapporter), överväg att lägga till automatisk skanning även för dem, som en del av publiceringsprocessen.
Vill du lägga till automatisk PDF-testning i din process också?
Vårt verktyg skannar PDF-filer och ger varje dokument ett tillgänglighetspoäng – du kan köra det som en periodisk kontroll tillsammans med din CI/CD-process.
Skanna din webbplats gratis ←Efter skanning kan du även göra de dokument som hittades tillgängliga direkt och gratis viaAccessiDoc.