Tilgjengelighet som bare kontrolleres én gang i året, i en manuell engangsgjennomgang, eroderer nesten alltid raskt – enhver liten kodeoppdatering kan ødelegge noe som allerede var fikset. Løsningen: bygg tilgjengelighetstesting inn i selve utviklingsprosessen (CI/CD) som et automatisert trinn, slik at problemer fanges opp før de når produksjon. Denne artikkelen forklarer hvordan.

Kort sagt – hva denne artikkelen dekker

  1. Hvorfor er en engangssjekk ikke nok
  2. Hva automatiserte verktøy i CI/CD-pipelinen kan fange opp
  3. Hvor manuell testing fortsatt er nødvendig
  4. Hvordan implementere det i praksis

Hvorfor er en engangssjekk ikke nok

Et utviklingsteam som sender oppdateringer hver uke, eller noen ganger hver dag, kan ikke stole på en årlig tilgjengelighetsrevisjon for å opprettholde løpende samsvar. En ny komponent lagt til uten tilgjengelighet i tankene, eller en CSS-endring som ved et uhell reduserer kontrasten, kan ødelegge tilgjengeligheten som allerede var fikset – og ingen legger merke til det før en bruker eller en klage avslører det. Det samme prinsippet gjelder også for dokumenter - se vår veiledning omkartlegging av vanlige feil.

Hva automatiserte verktøy i CI/CD-pipelinen kan fange opp

Verktøy som axe-core, Pa11y eller Lighthouse CI kan kjøres automatisk på hver pull-forespørsel eller før hver distribusjon – i løpet av sekunder sjekker de ting som: fargekontrast, feil eller dupliserte ARIA-tagger, manglende alt-tekst, manglende skjemaetiketter og feil overskriftsrekkefølge. Hvis kontrollen mislykkes, blokkeres pull-forespørselen automatisk fra å slå sammen - akkurat som en vanlig kodegjennomgang eller en mislykket enhetstest.

💡 Praktisk tips

Start i "advarselsmodus" (ikke-blokkerende) i noen uker for å se hvor mange problemer som allerede eksisterer i kodebasen, og bare etter en innledende opprydding gjør sjekken om til en distribusjonsblokkering - på den måten blir ikke teamet "fast" og står overfor hundrevis av feil på dag én.

Hvor manuell testing fortsatt er nødvendig

Akkurat som med dokumenttesting, fanger automatiserte verktøy i CI/CD-pipelinen opp klare strukturelle problemer, men de kan ikke bedømme den faktiske brukeropplevelsen: om tastaturnavigering gir mening, om en skjermleser "forteller en sammenhengende historie" på siden, eller om en tilpasset komponent (som en karusell eller modal) er brukbar i den virkelige verden. Det er derfor det er verdt å koble de pågående automatiserte kontrollene med en periodisk manuell revisjon – for eksempel kvartalsvis.

Hvordan implementere det i praksis

  1. Velg et testverktøy som passer din teknologistabel (øksekjerne for de fleste JavaScript-prosjekter, Lighthouse CI for nettleserbaserte prosjekter).
  2. Kjør det som et trinn i CI-pipelinen din - vanligvis som en GitHub-handling, en GitLab CI-jobb eller et tilsvarende trinn i det CI/CD-verktøyet du bruker.
  3. Sett en klar feilterskel (for eksempel: ingen "kritiske"-nivåproblemer per øksekjerne) før sjekken blir en blokkering.
  4. Dekk PDF-filene dine også: hvis organisasjonen genererer dokumenter automatisk (fakturaer, rapporter), vurder å legge til automatisk skanning for disse også, som en del av publiseringsprosessen.

Vil du legge til automatisert PDF-testing i prosessen din også?

Verktøyet vårt skanner PDF-filer og gir hvert dokument en tilgjengelighetsscore – du kan kjøre det som en periodisk sjekk sammen med CI/CD-prosessen.

Skann nettstedet ditt gratis ←

Etter skanning kan du også gjøre dokumentene som ble funnet tilgjengelige direkte og gratis viaAccessiDoc.