Pa11y

Pa11y è uno strumento di test automatizzato per l’accessibilità open source. Originariamente sviluppato presso il Nature Publishing Group e ora mantenuto da una community indipendente, Pa11y è lo strumento di riferimento per «i test di accessibilità in CI» nell’ultimo decennio.

Cosa fa Pa11y

Pa11y da riga di comando accetta un URL, esegue controlli di accessibilità sulla pagina renderizzata e restituisce un elenco di violazioni:

$ 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 viene eseguito in un browser headless (con Puppeteer o Playwright come motore sottostante), quindi vede il DOM renderizzato — non solo il sorgente HTML — il che significa che può sottoporre ad audit i contenuti generati da JavaScript così come li incontra un utente reale.

Runner supportati

Pa11y ha storicamente supportato due motori di regole:

• HTML_CodeSniffer (il default; lo storico backbone di Pa11y).
• axe-core (tramite pa11y --runner axe).

È possibile eseguirli entrambi contemporaneamente e unire i risultati — una modalità «tutto ciò che riesco a rilevare automaticamente». La maggior parte delle implementazioni moderne di Pa11y usa il runner axe-core in via esclusiva, perché axe-core dispone dello sviluppo di regole più attivo.

pa11y-ci — il flusso di lavoro multi-URL

Il caso d’uso principale è pa11y-ci, un wrapper che esegue Pa11y su molti URL contemporaneamente e restituisce il codice di stato appropriato per la CI:

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

È esattamente il flusso di lavoro che la maggior parte dei programmi di accessibilità adotta per le regressioni notturne: si alimenta la sitemap del sito in pa11y-ci con una pianificazione cron, si fa fallire la build se compaiono nuove violazioni, e si invia un avviso quando il conteggio delle violazioni aumenta.

La configurazione risiede in .pa11yci (o in un file JSON) e consente esclusioni per singolo URL, soglie di severità, dimensioni del viewport, azioni personalizzate (login, click-through) e altre forme di automazione.

Pa11y vs axe-core vs Lighthouse

Un modello mentale ragionevole:

• axe-core è il motore di regole — la libreria di rilevamento sottostante. Lo si utilizza tramite un wrapper.
• Lighthouse è un wrapper, ottimizzato per audit di qualità dell’intero sito (Prestazioni + Accessibilità + Best Practice + SEO).
• Pa11y è un altro wrapper, ottimizzato per il blocco della CI focalizzato sull’accessibilità su molti URL su larga scala.
• axe-core CLI è il terzo — axe nudo, senza il wrapper Pa11y, anch’esso adatto alla CI.

Per approfondimenti su singola pagina, Lighthouse è la scelta migliore. Per i test di regressione sull’intero sito con molti URL, Pa11y è il default pratico. Per i controlli PR che bloccano la build su un singolo URL, axe-core CLI o Lighthouse-CI funzionano entrambi correttamente.

Limitazioni

Pa11y eredita tutte le limitazioni degli strumenti automatizzati:

• Dal 30 al 40% dei problemi WCAG è rilevabile automaticamente; il resto richiede il giudizio umano.
• Non è in grado di testare la navigazione da tastiera, l’ordine di focus o il comportamento degli screen reader.
• Viene eseguito in un browser headless, quindi non riesce a individuare i problemi che compaiono solo durante la reale interazione dell’utente (rage-click, abbandono del modulo, sovrapposizioni impreviste di modal).

Tuttavia, entro il tetto del rilevamento automatico, Pa11y è lo strumento operativamente più flessibile tra le principali opzioni — in particolare quando il perimetro dell’audit è «l’intero sito, ogni notte» anziché «questa specifica PR».