Værktøjer

Pa11y

Et open source kommandolinje-tilgængelighedstestværktøj. CI-venlig ledsager til axe-core CLI; pa11y-ci driver de natlige siteomspændende regressionsworkflows, som de fleste store tilgængelighedsprogrammer anvender.

Pa11y er et open source-automatiseret tilgængelighedstestværktøj. Oprindeligt udviklet hos Nature Publishing Group og nu vedligeholdt af et uafhængigt fællesskab har Pa11y været standardværktøjet til „tilgængelighedstests i CI“ i det seneste årti.

Hvad Pa11y gør

Pa11y tager en URL fra kommandolinjen og kører tilgængelighedstjek mod den renderede side og udsender en liste over overtrædelser:

$ pa11y https://example.com
Welcome to Pa11y

> Running Pa11y on 1 URLs:
...

Error: This element does not have an attribute "alt".
   • Element: <img src="..." />
   • Code: HTML_CS.Principle1.Guideline1_1.1_1_1.H37
   • Selector: body > section:nth-child(2) > img

Pa11y kører i en headless browser (Puppeteer eller Playwright under motorhjelmen), så det ser det renderede DOM frem for blot kilde-HTML — det betyder, at det kan gennemgå JavaScript-renderet indhold på samme måde, som en bruger ville møde det.

Hvilke kørselsmiljøer understøttes

Pa11y har historisk understøttet to regelmotorer:

  • HTML_CodeSniffer (standard; den originale Pa11y-rygrad).
  • axe-core (via pa11y --runner axe).

Du kan køre begge på én gang og flette resultaterne — en „alt, jeg kan opdage automatisk“-tilstand. De fleste moderne Pa11y-implementeringer bruger udelukkende axe-core-køreren, fordi axe-core har den mest aktive regeludvikling.

pa11y-ci — arbejdsgangen med mange URL’er

Standardanvendelsen er pa11y-ci, en indpakning der kører Pa11y mod mange URL’er på én gang og afslutter med en passende statuskode til CI:

$ pa11y-ci --sitemap https://example.com/sitemap.xml

Dette er præcis den arbejdsgang, de fleste tilgængelighedsprogrammer anvender til natlige regressioner: send sitekortet ind i pa11y-ci på et cron-schedule, lad bygget fejle, hvis der opstår nye overtrædelser, og udsend en advarsel, når antallet af overtrædelser stiger.

Konfigurationen ligger i .pa11yci (eller en JSON-fil) og tillader pr. URL ekskluderinger, alvorlighedstærskler, viewport-størrelser, brugerdefinerede handlinger (login, klikigennem) og anden automatisering.

Pa11y vs. axe-core vs. Lighthouse

En fornuftig mental model:

  • axe-core er regelmotoren — det underliggende detektionsbibliotek. Du bruger det via en indpakning.
  • Lighthouse er én indpakning, optimeret til hele sitetets kvalitetsaudits (Perf + A11y + Best Practices + SEO).
  • Pa11y er en anden indpakning, optimeret til tilgængeligheds-CI-kontrol på tværs af mange URL’er i stor skala.
  • axe-core CLI er den tredje — ren axe uden Pa11y-indpakning, også CI-venlig.

Til dybdegående gennemgange af enkeltssider er Lighthouse bedre. Til siteomspændende regressionstest med mange URL’er er Pa11y det praktiske standardvalg. Til byggeblokkerende PR-tjek på en enkelt URL fungerer axe-core CLI eller Lighthouse-CI begge fint.

Begrænsninger

Pa11y arver alle automatiserede værktøjers begrænsninger:

  • 30-40 % af WCAG-problemerne kan opdages automatisk; resten kræver menneskelig vurdering.
  • Det kan ikke teste tastaturnavigation, fokusrækkefølge eller skærmlæseradfærd.
  • Det kører i en headless browser og kan derfor ikke fange problemer, der kun opstår under reel brugerinteraktion (rage-klik, formularafbrud, uventet modal-stak).

Men inden for loftet for automatisk detektion er Pa11y det driftsmæssigt mest fleksible værktøj blandt de større muligheder — særligt når revisionens omfang er „hele sitet, hver nat“ frem for „denne specifikke PR“.