Käytettävyys, joka tarkistetaan vain kerran vuodessa, kertaluonteisessa manuaalisessa tarkistuksessa, heikkenee lähes aina nopeasti – mikä tahansa pieni koodipäivitys voi rikkoa jo korjatun. Ratkaisu: Liitä esteettömyystestaus itse kehitysprosessiin (CI/CD) automatisoituna vaiheena, jotta ongelmat jäävät kiinni ennen kuin ne pääsevät tuotantoon. Tämä artikkeli selittää, miten.
Lyhyesti: mitä tämä artikkeli käsittelee
Miksi kertatarkastus ei riitä
Kehitystiimi, joka toimittaa päivityksiä viikoittain tai joskus päivittäin, ei voi luottaa vuotuiseen esteettömyystarkastukseen ylläpitääkseen jatkuvaa vaatimustenmukaisuutta. Uusi komponentti, joka on lisätty esteettömyyttä ajatellen, tai CSS-muutos, joka alentaa kontrastia vahingossa, voi rikkoa jo korjatun esteettömyyden – eikä kukaan huomaa sitä ennen kuin käyttäjä tai valitus paljastaa sen. Sama periaate koskee myös asiakirjoja – katso oppaamme aiheestakartoituksen yleiset virheet.
Mitä automaattiset työkalut CI/CD-liukuhihnassa voivat saada kiinni
Työkalut, kuten axe-core, Pa11y tai Lighthouse CI, voivat toimia automaattisesti jokaisen vetopyynnön yhteydessä tai ennen jokaista käyttöönottoa – sekunneissa ne tarkistavat esimerkiksi värikontrastit, virheelliset tai päällekkäiset ARIA-tunnisteet, puuttuvat vaihtoehtoiset tekstit, puuttuvat lomaketunnisteet ja virheellinen otsikkojärjestys. Jos tarkistus epäonnistuu, vetopyyntö estetään automaattisesti yhdistämästä – aivan kuten tavallinen koodin tarkistus tai epäonnistunut yksikkötesti.
💡 Käytännön vinkki
Aloita "varoitustilassa" (ei-esto) muutaman viikon ajan nähdäksesi kuinka monta ongelmaa koodikannassa on jo olemassa, ja muuta tarkistus vasta ensimmäisen siivouksen jälkeen käyttöönoton estäjäksi – näin tiimi ei "jumiudu" kohtaamaan satoja virheitä ensimmäisenä päivänä.
Missä manuaalista testausta tarvitaan edelleen
Aivan kuten asiakirjojen testauksessa, CI/CD-putken automaattiset työkalut havaitsevat selkeitä rakenteellisia ongelmia, mutta ne eivät voi arvioida todellista käyttökokemusta: onko näppäimistön navigoinnissa järkeä, "kertooko näytönlukuohjelma johdonmukaisen tarinan" sivulla vai onko mukautettu komponentti (kuten karuselli tai modaali) aidosti käyttökelpoinen. Siksi meneillään olevat automaattiset tarkastukset kannattaa yhdistää säännölliseen manuaaliseen tarkastukseen – esimerkiksi neljännesvuosittain.
Kuinka se toteutetaan käytännössä
- Valitse testaustyökalu, joka sopii teknologiapinoosi (axe-core useimmille JavaScript-projekteille, Lighthouse CI selainpohjaisille projekteille).
- Suorita se vaiheena CI-putkistossasi – yleensä GitHub-toimintona, GitLab CI -työnä tai vastaavana vaiheena missä tahansa käyttämässäsi CI/CD-työkalussa.
- Aseta selkeä epäonnistumiskynnys (esimerkiksi: ei "kriittisten" tason ongelmia per axe-core), ennen kuin tarkistuksesta tulee esto.
- Peitä myös PDF-tiedostosi: jos organisaatiosi luo asiakirjat automaattisesti (laskut, raportit), harkitse myös automaattisen skannauksen lisäämistä niihin osana julkaisuprosessia.
Haluatko myös lisätä automaattisen PDF-testauksen prosessiisi?
Työkalumme skannaa PDF-tiedostoja ja antaa kullekin asiakirjalle saavutettavuuspisteen – voit suorittaa sen säännöllisenä tarkistuksena CI/CD-prosessin rinnalla.
Skannaa sivustosi ilmaiseksi ←Skannauksen jälkeen voit myös asettaa löydetyt asiakirjat saataville suoraan ja ilmaiseksiAccessiDoc.