Pa11y
Ett open source-verktyg för tillgänglighetstest i kommandoraden. CI-vänligt komplement till axe-core CLI; pa11y-ci driver nattliga regressionstest för hela webbplatser i de flesta stora tillgänglighetsprogram.
Pa11y är ett open source-verktyg för automatiserat tillgänglighetstest. Det utvecklades ursprungligen hos Nature Publishing Group och underhålls nu av ett oberoende community. Under det senaste decenniet har Pa11y varit standardvalet för tillgänglighetstest i CI-miljöer.
Vad Pa11y gör
Pa11y tar en URL via kommandoraden och kör tillgänglighetskontroller mot den renderade sidan, med en lista av fel som utdata:
$ 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örs i en headless-webbläsare (Puppeteer eller Playwright under huven) och ser det renderade DOM-trädet — inte bara HTML-källkoden — vilket innebär att JavaScript-renderat innehåll granskas precis som en användare möter det.
Vilka regelkörare som stöds
Pa11y har historiskt stött två regelkörare:
- HTML_CodeSniffer (standardval; Pa11ys ursprungliga ryggrad).
- axe-core (via
pa11y --runner axe).
Man kan köra båda samtidigt och slå ihop resultaten — ett läge för “allt jag automatiskt kan detektera”. De flesta moderna Pa11y-installationer använder axe-core-köraren uteslutande, eftersom axe-core har den mest aktiva regelutvecklingen.
pa11y-ci — arbetsflödet för flera URL:er
Det viktigaste användningsfallet är pa11y-ci, ett omslag som kör Pa11y mot många URL:er på en gång och returnerar en lämplig statuskod för CI:
$ pa11y-ci --sitemap https://example.com/sitemap.xml
Det är exakt det arbetsflöde de flesta tillgänglighetsprogram använder för nattliga regressionstest: mata in webbplatsens webbplatskarta i pa11y-ci via ett cron-schema, misslyckas bygget om nya fel dyker upp och larma när felantalet ökar.
Konfigurationen finns i .pa11yci (eller en JSON-fil) och tillåter undantag per URL, allvarlighetströsklar, visningsportsstorlekar, anpassade åtgärder (inloggning, genomklickning) och övrig automatisering.
Pa11y vs axe-core vs Lighthouse
En rimlig mental modell:
- axe-core är regelköraren — den underliggande detekteringsbiblioteket. Man använder den via ett omslag.
- Lighthouse är ett omslag, optimerat för fullständiga webbplatsgransningar (Prestanda + Tillgänglighet + Bästa praxis + SEO).
- Pa11y är ett annat omslag, optimerat för tillgänglighetsspecifik CI-granskning över många URL:er i stor skala.
- axe-core CLI är det tredje — ren axe, inget Pa11y-omslag, också CI-vänligt.
För djupgranskning per sida är Lighthouse bättre. För webbplatsomfattande regressionstest med många URL:er är Pa11y den praktiska standarden. För byggblockerande PR-kontroller på en enskild URL fungerar axe-core CLI eller Lighthouse-CI lika bra.
Begränsningar
Pa11y ärver alla begränsningar hos automatiserade verktyg:
- 30–40 % av WCAG-problem kan detekteras automatiskt; resten kräver mänskligt omdöme.
- Verktyget kan inte testa tangentbordsnavigering, fokusordning eller skärmläsarbeteende.
- Det körs i en headless-webbläsare och kan därför inte fånga problem som bara uppstår under verklig användarinteraktion (envist klickande, formuläravhopp, oväntad modal-stapeling).
Men inom det automatiserade detektionstaket är Pa11y det operativt mest flexibla verktyget bland de stora alternativen — särskilt när granskningsomfånget är “hela webbplatsen, varje natt” snarare än “den här specifika PR:en”.