axe-core — glossario di Disability World

axe-core è il motore di test di accessibilità automatizzato open source sviluppato da Deque Systems. Alimenta un ampio ecosistema di strumenti di test — estensioni browser (axe DevTools, Accessibility Insights), script CI (axe-cli, jest-axe, cypress-axe, playwright-axe) e, in modo particolare, l’audit di accessibilità di Lighthouse.

Nell’ultimo decennio, axe-core è stato il verificatore di accessibilità automatizzato più diffuso al mondo. La maggior parte delle pipeline CI legate all’accessibilità oggi in produzione eseguono axe-core, spesso senza che il team ne sia consapevole.

Cosa fa bene axe-core

Il set di regole di axe-core è conservativo per scelta: una regola viene inclusa solo quando il suo tasso di falsi positivi è essenzialmente zero. Questo rende axe-core affidabile come gate CI — quando segnala una violazione, la violazione è reale e il team può intervenire senza preoccuparsi di rincorrere controlli instabili.

Le regole che axe-core rileva in modo affidabile includono:

Etichette mancanti o vuote sui controlli di modulo.
Attributi alt mancanti (e alt palesemente inutili come i nomi di file).
Contrasto cromatico insufficiente (testi e componenti dell’interfaccia).
ARIA non valida — ruoli inesistenti, proprietà obbligatorie mancanti, strutture figlio non consentite.
ID duplicati che interrompono i riferimenti ARIA.
Attributo lingua mancante su <html>.
Pulsanti senza nome accessibile.
Campi di modulo senza etichetta programmatica.
Link vuoti (<a href>...</a> senza testo o alt).
Salti di livello di intestazione e <h1> mancante in alcune configurazioni.

Questo elenco copre una percentuale significativa delle criticità di accessibilità più evidenti. Eseguire axe-core in CI consente di rilevarle al momento della code review anziché in fase di audit.

Il limite superiore

Gli autori di axe-core sono espliciti riguardo al tetto: gli strumenti automatizzati possono rilevare al massimo il 30–40 % dei problemi WCAG. Il resto richiede giudizio umano e test con tecnologie assistive.

In particolare, axe-core non è in grado di rilevare:

Testo alternativo errato — può segnalare un alt mancante, ma non che alt="icona hamburger" sia sbagliato per un pulsante che apre un menu.
Testo dei link fuorviante — i link «Clicca qui» sono formalmente corretti, ma inutili per gli utenti di screen reader.
Ordine di focus interrotto — un ordine di tabulazione che non corrisponde all’ordine visivo è una violazione del criterio 2.4.3 che nessun verificatore statico riesce a rilevare.
Struttura delle intestazioni errata — axe-core rileva <h1> mancante e i salti di livello, ma non può stabilire se una pagina abbia usato <h2> dove avrebbe dovuto esserci <h1>.
Contenuti che funzionano solo per certi gruppi di utenti — conformi a WCAG ma inutilizzabili per utenti con problemi di visione, disabilità cognitive, ecc.

Un sito che non registra violazioni in axe-core è una condizione necessaria per l’accessibilità, ma non sufficiente. Il lavoro rimanente — ordine di focus, qualità dei contenuti, comportamento con gli screen reader, test con utenti reali — è quello che occupa la maggior parte del tempo effettivo.

Come usare axe-core operativamente

Tre modalità di impiego funzionano bene in combinazione:

Nell’editor. axe DevTools e Accessibility Insights vengono eseguiti su richiesta contro il DOM renderizzato in una scheda del browser. Da usare durante lo sviluppo.
In CI. axe-cli, jest-axe, cypress-axe o playwright-axe fanno fallire la build in presenza di nuove violazioni. Da usare per prevenire le regressioni.
In fase di audit. I revisori esterni eseguono axe-core come punto di partenza, aggiungendo poi test manuali. Da usare per validare la baseline automatizzata.

La combinazione mantiene a zero i problemi rilevabili automaticamente, mentre un programma di accessibilità reale gestisce il resto.