1. Johdanto
Automaattinen saavutettavuustestaus kannattaa ottaa osaksi CI/CD-putkea, jotta ongelmat havaitaan mahdollisimman aikaisessa vaiheessa.
Mutta millainen testausstrategia toimii parhaiten käytännössä?
Yksi toimivimmista ratkaisuista on yhdistää kaksi lähestymistapaa:
- Kohdennetut tarkistukset kriittisissä käyttötilanteissa (esim. modaalit, kirjautumiset)
- Koko sivuston auditointi, joka tuottaa kattavan raportin kaikista sivuista
Tässä artikkelissa käymme läpi esimerkin GitHub Actions -putkesta, jossa yhdistetään Playwright + axe-core modaalien testaamiseen ja Pa11y koko sivun saavutettavuusauditointiin.
Artikkelin lopussa on myös linkki Githubiin, jossa voi tarkastella asiantuntijamme kehittämiä esimerkkikoodeja aiheesta.
💡 Mikäli aihe ei ole sinulle vielä tuttu, aiempi artikkelimme ”Saavutettavuustestauksen automatisointi – mitä voi automatisoida ja miten?” toimii hyvänä aloituksena, jossa käymme läpi saavutettavuustestauksen perusteet ja sen, mitä voidaan automatisoida.
2. Yhdistelmästrategian idea
Pelkkä koko sivun auditointi ei aina riitä, koska dynaamiset tilat, kuten modaalit ja dropdownit, jäävät helposti testaamatta. Toisaalta pelkät E2E-testit eivät kata kaikkia sivuja ja näkymiä.
Siksi on järkevää käyttää molempia lähestymistapoja:
- Playwright + axe-core testaa saavutettavuuden siinä tilassa, johon käyttäjä oikeasti päätyy (esim. modalin avaus).
- Pa11y käy läpi koko sivuston ja raportoi laajemmat ongelmat.
3. Kohdennetut saavutettavuustestit Playwrightilla
Playwright mahdollistaa saavutettavuuden tarkistamisen osana end-to-end -testejä. Tässä mallissa modalin avaus simuloidaan ja sen sisältö tarkistetaan axe-core-kirjastolla.
Näin varmistetaan, että modaali ei ainoastaan avaudu oikein, vaan sen sisältö on saavutettavaa myös ruudunlukijoille ja näppäimistönavigoinnille. Alla on esimerkkitesti, jossa Playwrightin ja axe-core:n avulla tarkistetaan modaalin saavutettavuus.
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';
test.describe('Modal accessibility', () => {
test('modal meets WCAG 2.0/2.1 A/AA', async ({ page }) => {
await page.goto('/', { waitUntil: 'domcontentloaded' });
// Avaa modaali
await page.getByTestId('chocolate-cake').getByTestId('view-button').click();
// Varmista, että dialogi on avautunut
const dialog = page.getByRole('dialog');
// Suorita axe-tarkistus vain modaalin sisällölle
const results = await new AxeBuilder({ page })
.withTags(['wcag2a', 'wcag2aa']) // rajaa tarkistukset WCAG 2.0/2.1 A/AA -tasoon
.include(['[role="dialog"]', '.dqpl-modal', '.RecipeModal']) // kohdistetaan analyysi modaalielementteihin
// .disableRules(['color-contrast']) // esimerkki: voidaan ohittaa tietty sääntö tilapäisesti
.analyze();
// Raportoi mahdolliset virheet
if (results.violations.length) {
console.log('Havaitut saavutettavuusongelmat modaalissa:\n');
for (const v of results.violations) {
console.log(`- ${v.id} (${v.impact}) — ${v.help}`);
v.nodes.forEach((n, i) => {
console.log(` ${i + 1}) ${n.target.join(' ')}`);
if (n.failureSummary) console.log(` ${n.failureSummary}`);
});
}
}
// Epäonnistuu, jos saavutettavuusongelmia havaitaan
expect(results.violations, 'Modal should have no a11y violations').toEqual([]);
});
});4. Koko sivuston auditointi Pa11yllä
Pa11y soveltuu koko sivuston laajuisiin tarkistuksiin. Se voidaan konfiguroida käymään läpi sivut ja tuottamaan raportit, jotka liitetään osaksi CI/CD-putkea.
Alla ote CI/CD skriptin (YML) tärkeimmistä stepeistä, joissa asennetaan ja ajetaan pa11y. Sen alla on Pa11y-konfiguraatio (JSON), joka määrittelee miten saavutettavuustestit ajetaan pay11y:llä.
- name: Asenna pa11y-ci
run: npm install -g pa11y-ci
- name: Suorita saavutettavuustesti ja tallenna raportti
shell: bash
run: |
set -o pipefail
pa11y-ci --config=pa11yci.json --reporter json | tee pa11y-report.json{
"defaults": {
"standard": "WCAG2AA",
"timeout": 30000,
"chromeLaunchConfig": {
"args": [
"--no-sandbox",
"--disable-setuid-sandbox",
"--disable-dev-shm-usage",
"--disable-background-timer-throttling",
"--disable-backgrounding-occluded-windows",
"--disable-renderer-backgrounding",
"--disable-features=TranslateUI",
"--disable-ipc-flooding-protection"
],
"headless": true
}
},
"urls": [
"https://broken-workshop.dequelabs.com"
],
"crawler": true,
"ignore": []
}Tarvittaessa Pa11y voidaan myös ohjata avaamaan erikoistapauksia, kuten modaalit tai kirjautumissivut. Näin sen käyttö ei rajoitu pelkästään staattisiin näkymiin.
5. GitHub Actions -putken toteutus
Esimerkkiputkessa GitHub Actions ajaa kaksi vaihetta:
- Playwright + axe-core
- Testaa saavutettavuuden kriittisissä käyttötilanteissa
- Esim. modalit, kirjautumiset, kassaprosessi
- Pa11y auditointi
- Käy läpi koko sivuston
- Raportti tallennetaan ja liitetään ajon artefaktiksi
Tämä yhdistelmä varmistaa, että virheet löydetään ajoissa mutta kattavasti.
6. Hyödyt ja opit
- Nopeat, kohdennetut tarkistukset jokaisessa commitissa
- Laajempi auditointi esimerkiksi kerran yössä tai viikossa
- Kriittiset virheet löydetään heti, mutta pienemmätkin ongelmat tulevat näkyviin säännöllisesti
- Raportit voidaan jakaa tiimille, jolloin saavutettavuus pysyy jatkuvasti keskustelussa
7. Yhteenveto
Playwright + axe-core ja Pa11y täydentävät toisiaan: toinen tuo nopeutta ja käytännön tarkistuksia, toinen kattavuutta ja laajemman näkymän palvelun tilaan.
Kun nämä integroidaan CI/CD-putkeen, saavutettavuustestauksesta tulee osa normaalia kehityssykliä – ei erillinen projekti, joka aloitetaan vasta ongelmien ilmaannuttua. Tämä esimerkkimme on vain yksi tapa tehdä asia., pääasia on, että saavutettavuustestaus tulee tehdyksi säännöllisesti ja mahdollisimman aikaisessa vaiheessa kehitystyötä.
👉 Tämän artikkelin esimerkkikoodit ja GitHub Actions -workflow löytyvät GitHub-reposta.
Kiinnostuitko?
Ota yhteyttä:
Janne Lepistö, CEO
+358 50 487 3265
janne.lepisto@qubilea.fi
Lue lisää testauspalveluistamme >>
Tutustu myös muihin artikkeleihimme:
