Come testare l’accessibilità web: strumenti automatici, test manuali e screen reader

I numeri sono difficili da ignorare. Secondo il report WebAIM Million 2026, le scansioni automatizzate su un milione di home page hanno rilevato oltre 56 milioni di errori di accessibilità distinti — una media di 56,1 errori per pagina, in aumento di oltre il 10% rispetto all’anno precedente. E poiché gli strumenti automatizzati possono individuare solo circa il 30–40% delle potenziali violazioni WCAG, la reale portata del problema è significativamente più ampia. Se la tua strategia di test di accessibilità inizia e finisce con una singola scansione tramite estensione del browser, stai vedendo solo una frazione delle barriere che i tuoi utenti affrontano ogni giorno.

Perché una strategia di test multilivello è imprescindibile

Il test di accessibilità web non è un singolo evento — è una disciplina che abbraccia strumenti, giudizio umano ed esperienza vissuta. Le Web Content Accessibility Guidelines (WCAG) si basano su quattro principi fondamentali, comunemente chiamati POUR: i contenuti devono essere Perceivable (Percepibili), Operable (Utilizzabili), Understandable (Comprensibili) e Robust (Robusti). Gli strumenti automatizzati possono verificare che un’immagine abbia un attributo alt, ma non possono giudicare se quel testo alternativo descriva davvero l’immagine in modo significativo. Uno script può confermare che un pulsante abbia un’etichetta, ma non può dirti se una persona che usa uno screen reader capirebbe cosa succede premendolo nel contesto.

Per questo ogni programma di accessibilità serio stratifica tre approcci distinti: scansione automatizzata per individuare violazioni sistemiche e ripetibili su larga scala; test manuali per valutare i criteri dipendenti dal giudizio che richiedono un cervello umano; e test con tecnologie assistive — in particolare gli screen reader — per validare l’esperienza reale delle persone che dipendono da questi strumenti ogni giorno. Ogni livello compensa i punti ciechi degli altri. Saltarne anche solo uno lascia lacune che prima o poi emergeranno sotto forma di reclami degli utenti, fallimenti di audit o esposizione legale.

WCAG 2.2, lo standard W3C attuale a fine 2023, pone maggiore enfasi sulla usabilità per la navigazione da tastiera, le interazioni touch e l’accessibilità cognitiva, mantenendo al contempo tutti i requisiti esistenti di WCAG 2.1. Testare rispetto a questo standard non è facoltativo per la maggior parte delle organizzazioni — è sempre più imposto dalla normativa, dall’ADA negli Stati Uniti all’European Accessibility Act, entrato in vigore a giugno 2025. Capire come testare è il fondamento pratico che rende raggiungibile la conformità.

Test automatizzati: la tua prima linea di difesa

Gli strumenti automatizzati accelerano il processo di test e si integrano senza attriti nelle pipeline CI/CD, aiutando i team a individuare e correggere gli errori di accessibilità in modo precoce e frequente. È meglio considerarli come un filtro — non rileveranno tutto, ma individueranno in modo affidabile le violazioni più comuni e più misurabili, a una velocità che nessun revisore umano può eguagliare. Pensali come un correttore ortografico: essenziale, ma non un sostituto di un editor esperto.

Le categorie di problemi più comuni che gli strumenti automatizzati rilevano in modo affidabile includono testo alternativo mancante o vuoto sulle immagini, rapporti di contrasto cromatico insufficienti, campi di modulo senza etichette associate, testo di link o pulsanti vuoto, dichiarazioni della lingua della pagina mancanti e strutture di intestazione duplicate o mancanti. Secondo i dati del WebAIM Million, il 96,4% degli errori rilevati rientra in sole sei categorie — il che significa che gli strumenti automatizzati, applicati in modo coerente, possono ridurre in modo sostanziale il numero di violazioni prima che qualsiasi revisore umano tocchi l’interfaccia.

Principali strumenti di test automatizzati

axe-core / axe DevTools (Deque Systems) è probabilmente il motore di test di accessibilità più adottato nel settore. Il suo core open source è integrato in decine di altri strumenti e framework di test. L’estensione del browser funziona in Chrome, Firefox ed Edge, offrendo agli sviluppatori un feedback immediato sul DOM renderizzato. Per i team di ingegneria, axe-core si integra con Cypress, Playwright, Selenium e Jest, rendendo semplice incorporare i controlli di accessibilità direttamente nella suite di test esistente.

WAVE (WebAIM) è un’estensione del browser e uno strumento di valutazione online che fornisce un feedback visivo, in pagina, usando icone colorate sovrapposte direttamente ai contenuti. È particolarmente adatto a chi si occupa di contenuti e alle parti interessate non tecniche che devono comprendere i problemi di accessibilità senza leggere il codice. WAVE evidenzia errori, avvisi, elementi strutturali e ruoli ARIA in un modo che rende immediatamente visibile la relazione tra markup ed esperienza utente.

Google Lighthouse è integrato direttamente in Chrome DevTools ed esegue audit di accessibilità insieme a controlli su prestazioni, SEO e best practice. È eccellente per rapidi audit del front-end durante lo sviluppo e può essere eseguito da riga di comando per l’integrazione in CI. Il suo punteggio di accessibilità è alimentato da axe-core sotto il cofano, quindi copre ambiti sovrapposti ma non identici.

Pa11y è uno strumento da riga di comando e una libreria Node.js progettata per l’integrazione in pipeline. Supporta sia axe che il motore HTML_CodeSniffer, può testare più URL da un file di configurazione e produce report leggibili dalle macchine, adatti a dashboard o sistemi di ticketing. È particolarmente utile per monitorare siti di grandi dimensioni o per le organizzazioni che devono sottoporre a audit URL in blocco su base programmata.

Integrare axe nella pipeline CI/CD

Il modo più efficace per prevenire regressioni di accessibilità è trattarle come qualsiasi altro bug — intercettarle prima che raggiungano la produzione. Integrare axe-core nella pipeline CI significa che ogni pull request viene scansionata automaticamente e le build possono essere configurate per fallire quando le violazioni superano le soglie accettabili. Ecco un esempio minimo che utilizza Playwright e il pacchetto @axe-core/playwright:

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test.describe('Homepage accessibility', () => {
  test('should have no automatically detectable WCAG violations', async ({ page }) => {
    await page.goto('https://your-site.com/');
    const results = await new AxeBuilder({ page })
      .withTags(['wcag2a', 'wcag2aa', 'wcag21aa'])
      .analyze();
    expect(results.violations).toEqual([]);
  });
});

Questo test naviga nella tua applicazione, esegue axe-core sulla pagina renderizzata limitandosi alle regole WCAG 2.x di livello A e AA, e fallisce se vengono restituite violazioni. Puoi collegarlo a un workflow di GitHub Actions in modo che venga eseguito a ogni push su main o su ogni pull request. Tieni presente che quando aggiungi per la prima volta test di accessibilità automatizzati a un progetto maturo, potresti scoprire decine di problemi preesistenti. Invece di bloccare immediatamente tutti i deploy, configura un numero di violazioni di base e stringi la soglia in modo incrementale man mano che effettui la correzione.

Limitazione importante: Gli strumenti automatizzati rilevano circa il 30–40% delle violazioni WCAG. Sono necessari ma non sufficienti. I test manuali sono imprescindibili per scoprire l’intera portata delle barriere di accessibilità.

Test manuali: ciò che le macchine non possono giudicare

I test manuali colmano le lacune che gli strumenti automatizzati non possono strutturalmente coprire. Richiedono che un tester — idealmente qualcuno formato su WCAG e familiare con le tecnologie assistive — analizzi pagine e interazioni seguendo una metodologia definita. L’obiettivo non è riverificare ciò che lo scanner automatizzato ha già trovato, ma valutare i criteri che richiedono giudizio umano: l’ordine di lettura è logico? La gestione del focus ha senso dopo l’apertura di una modale? Il messaggio di errore è davvero utile o si limita a dire “input non valido”?

Una sessione pratica di test manuali copre diverse aree distinte. La prima è la navigazione solo da tastiera. Scollega il mouse e naviga l’intera interfaccia usando solo Tab, Shift+Tab, Invio, Spazio e i tasti freccia. Ogni elemento interattivo — link, pulsanti, campi di modulo, menu a discesa, selettori di data, modali, tab — deve essere raggiungibile e utilizzabile senza mouse. Il focus non deve mai rimanere intrappolato (a meno che non sia intenzionale, come in una modale che deve trattenere il focus). L’indicatore di focus visibile deve essere abbastanza chiaro da poter essere seguito. WCAG 2.2 ha aggiunto il criterio di successo 2.4.11 Focus Appearance, che stabilisce requisiti minimi di dimensione e contrasto per gli indicatori di focus — questo è quasi sempre un controllo manuale.

La seconda area è la revisione di contenuti e struttura. Leggi la pagina con occhio critico rispetto alla gerarchia delle intestazioni. Le intestazioni dovrebbero rappresentare la struttura della pagina — <h1> per il titolo della pagina, <h2> per le sezioni principali, <h3> per le sottosezioni — senza saltare livelli. Verifica che il testo dei link sia descrittivo anche isolato (“Scarica il Bilancio Annuale 2025” va bene; “clicca qui” no). Controlla che le immagini con contenuto significativo abbiano un testo alternativo accurato e che le immagini decorative abbiano un attributo alt vuoto (alt=''). Rivedi le etichette dei moduli: ogni input dovrebbe avere un’etichetta associata a livello di codice, non solo un placeholder.

La terza area è costituita da interazioni dinamiche e ARIA. Le interfacce pesantemente basate su JavaScript — single-page application, modali, risultati di ricerca in tempo reale, caroselli, accordion — creano sfide di accessibilità che gli scanner statici non rilevano regolarmente. Quando si apre una modale, il focus si sposta al suo interno? Quando si chiude, il focus torna all’elemento che l’ha attivata? Quando una live region si aggiorna (un conteggio dei risultati di ricerca, un messaggio di validazione di un modulo), l’aggiornamento viene annunciato alle tecnologie assistive? Un uso scorretto di ARIA è una delle fonti più comuni di regressioni di accessibilità. I dati del WebAIM Million mostrano costantemente che le pagine che utilizzano attributi ARIA presentano in media molti più errori di quelle che non li usano — non perché ARIA sia negativa, ma perché viene spesso implementata in modo errato.

Una checklist pratica per i test manuali

• Navigazione da tastiera: Usa Tab per attraversare ogni elemento interattivo; conferma l’ordine logico, l’assenza di trappole di focus e indicatori di focus visibili che soddisfino WCAG 2.2 SC 2.4.11.
• Struttura delle intestazioni: Verifica una gerarchia logica, senza salti, usando un’estensione del browser come HeadingsMap o la toolbar WAVE.
• Testo di link e pulsanti: Conferma che tutti gli elementi interattivi abbiano nomi accessibili descrittivi e univoci — non “clicca qui” o “scopri di più” ripetuti decine di volte.
• Accessibilità dei moduli: Controlla che ogni campo abbia un’etichetta esplicita, che i messaggi di errore siano specifici e associati a livello di codice e che i campi obbligatori siano indicati in modo che le tecnologie assistive possano comunicarlo.
• Colore e contrasto: Verifica manualmente qualsiasi testo o componente UI che gli strumenti automatizzati hanno segnalato come incerto. Testo a basso contrasto è stato riscontrato nell’83,9% delle home page nel report WebAIM Million 2026 — è il singolo fallimento di accessibilità più comune.
• Dimensione dei target touch: WCAG 2.2 SC 2.5.8 richiede che i target interattivi siano almeno 24×24 pixel CSS (con una best practice raccomandata di 44×44 pixel). Ispeziona pulsanti piccoli, link solo icona e elementi di navigazione mobile.
• Zoom e riflusso: Testa con zoom del browser al 200% e al 400%. I contenuti dovrebbero rifluire senza scorrimento orizzontale al 400% (WCAG SC 1.4.10).

Test con screen reader: il proxy più vicino all’esperienza reale

Il test con screen reader è la parte più impegnativa di un programma di accessibilità, e anche la più rivelatrice. Una persona che usa uno screen reader vive una pagina web come un flusso lineare di testo e informazioni semantiche — il layout visivo è irrilevante. Intestazioni, landmark, liste, tabelle, etichette dei moduli e ruoli ARIA sono lo scheletro di navigazione. Se quello scheletro è rotto o mancante, la pagina diventa inutilizzabile indipendentemente da quanto bene superi i controlli automatizzati.

Secondo il WebAIM Screen Reader User Survey condotto tra la fine del 2023 e l’inizio del 2024, JAWS rimane lo screen reader desktop primario più citato con il 40,5% dei rispondenti, con NVDA subito dietro al 37,7%. VoiceOver detiene il 9,7% del mercato desktop primario ma è di gran lunga lo screen reader dominante sui dispositivi mobili, con il 70,6% delle persone che usano screen reader su mobile che vi fanno affidamento. Ciò significa che un programma di test completo dovrebbe coprire almeno: NVDA con Chrome su Windows, JAWS con Chrome su Windows e VoiceOver con Safari su iOS.

I principali screen reader in sintesi

JAWS (Job Access With Speech), sviluppato da Freedom Scientific, è stato per decenni il gold standard negli ambienti enterprise. Offre una profonda integrazione con Microsoft Office, scripting avanzato per applicazioni non standard e descrizione delle immagini basata su AI. JAWS richiede una licenza a pagamento (circa 1.000 $ per una licenza standard, o 95 $/anno per un abbonamento domestico), il che lo rende meno accessibile per test occasionali ma essenziale per validare che i flussi di lavoro di livello enterprise funzionino per le persone che usano screen reader professionalmente.

NVDA (NonVisual Desktop Access) è gratuito, open source e considerato affidabile da milioni di persone. Il suo set di funzionalità è cresciuto fino a eguagliare JAWS per la grande maggioranza delle attività web quotidiane, e la sua portabilità — può essere eseguito da una chiavetta USB su qualsiasi macchina Windows — lo rende la scelta pratica per la maggior parte dei team di sviluppo che iniziano a fare test con screen reader. NVDA con Chrome è la seconda combinazione screen reader–browser più comune nell’uso reale.

VoiceOver è integrato in ogni dispositivo macOS e iOS, senza necessità di installazione. Su desktop, si abbina al meglio con Safari. Su iPhone e iPad, è lo screen reader dominante con un ampio margine. Se il tuo sito ha un traffico mobile significativo — e la maggior parte lo ha — VoiceOver su iOS è una parte obbligatoria della tua matrice di test. Il suo modello di navigazione basato su gesture sui touchscreen è significativamente diverso dalla navigazione da tastiera su desktop, il che significa che i problemi di accessibilità specifici del mobile possono essere individuati solo testando su un vero dispositivo iOS.

TalkBack è lo screen reader di Google per Android ed è utilizzato da circa il 35% delle persone che usano screen reader su mobile. Se il tuo pubblico include utenti Android, i test con TalkBack dovrebbero far parte del tuo programma di accessibilità mobile.

Come condurre un test efficace con screen reader

Inizia spegnendo il monitor o chiudendo gli occhi. L’obiettivo è simulare l’esperienza di chi non può vedere lo schermo. Naviga la pagina usando solo i comandi dello screen reader. Per NVDA e JAWS, i pattern di navigazione più importanti da esercitare sono: lettura lineare della pagina con i tasti freccia o il comando di lettura continua; salto tra le intestazioni usando H; navigazione per landmark usando D (NVDA) o ; (JAWS) per spostarsi tra le regioni main, navigation e footer; navigazione con Tab solo tra gli elementi interattivi; e uso della modalità moduli per interagire con i campi di input.

Durante la navigazione, chiediti: l’ordine di lettura è logico? Il titolo della pagina ha senso quando viene annunciato? Le immagini sono descritte in modo significativo o lo screen reader annuncia “immagine” senza contesto? I campi del modulo annunciano la loro etichetta, il tipo e il valore corrente? Quando invii un modulo con errori, i messaggi di errore vengono annunciati e sono facili da individuare? Quando i contenuti dinamici si aggiornano — un banner di notifica, uno stato di caricamento, un conteggio dei risultati di ricerca — l’aggiornamento viene annunciato senza che la persona debba tornare indietro per trovarlo?

Gli screen reader consentono di interagire in modalità diverse — modalità lettura, modalità moduli e modalità applicazione — e possono produrre risultati molto diversi in ciascuna. Un elemento che funziona correttamente in una modalità può fallire silenziosamente in un’altra. Verifica sempre la stessa interazione in più modalità di navigazione.

Una delle mancanze più comuni e più dannose nelle applicazioni web moderne è la gestione del focus difettosa. Quando si apre una finestra di dialogo modale, il focus deve spostarsi al suo interno; quando si chiude, il focus deve tornare all’elemento che l’ha attivata. Quando una single-page application passa a una nuova vista, il titolo della pagina e l’intestazione principale devono essere annunciati. Quando si verifica un errore durante l’invio di un modulo, il focus dovrebbe spostarsi al riepilogo degli errori o al primo campo non valido. Questi pattern non possono essere validati da alcuno strumento automatizzato — richiedono un tester con uno screen reader aperto.

Costruire un programma di test di accessibilità duraturo

L’errore più comune che le organizzazioni commettono è trattare i test di accessibilità come un audit una tantum. Un sito che oggi supera i controlli svilupperà nuove violazioni domani, man mano che vengono pubblicati contenuti, rilasciate funzionalità e aggiornati script di terze parti. L’accessibilità deve essere integrata nel ciclo di sviluppo come pratica continua, non come spunta periodica.

Un programma sostenibile ha tre livelli che funzionano in parallelo. Il livello automatizzato viene eseguito a ogni commit di codice, intercettando le regressioni prima che raggiungano la produzione. Il livello manuale viene eseguito a ogni sprint man mano che vengono sviluppate nuove funzionalità — non come gate finale, ma come controllo durante lo sviluppo. Il livello delle tecnologie assistive viene eseguito come parte dei test di accettazione per qualsiasi funzionalità che comporti pattern di interazione significativi: moduli, cambi di navigazione, modali, contenuti dinamici e flussi utente. Per la maggior parte dei team, ciò significa almeno NVDA con Chrome e VoiceOver su iOS.

La prioritizzazione è importante. Se il tuo audit fa emergere cinquanta problemi, non tutti hanno lo stesso peso. Le violazioni WCAG sono categorizzate per impatto — i problemi critici che rendono i contenuti completamente inaccessibili ad alcune persone dovrebbero essere risolti prima dei problemi seri, che a loro volta hanno la precedenza su quelli moderati e minori. Concentrati prima sui pattern che interessano interi tipi di pagina: se la navigazione è rotta per chi usa la tastiera, correggi il template di navigazione e la correggi ovunque in una volta sola. Se la gestione degli errori dei moduli è inaccessibile, correggere il pattern significa correggere ogni modulo.

La documentazione non è facoltativa per i responsabili della conformità. Mantieni un registro dei test di accessibilità che riporti quali pagine sono state testate, quali strumenti e tecnologie assistive sono stati utilizzati, quali violazioni sono state trovate e quali interventi di correzione sono stati applicati e quando. Questa documentazione diventa preziosa durante audit di accessibilità o procedimenti legali, dimostrando un impegno continuo e in buona fede a raggiungere e mantenere la conformità.

Il ruolo dei widget overlay nella tua strategia di test

I widget di accessibilità overlay, come l’SDK Accsible, svolgono un ruolo significativo in una strategia di accessibilità multilivello — in particolare per le organizzazioni che devono fornire miglioramenti immediati ai contenuti esistenti mentre sono in corso interventi di correzione più profondi. Un overlay ben implementato può mettere a disposizione delle persone strumenti assistivi, come ridimensionamento del testo, regolazione del contrasto e miglioramenti alla navigazione da tastiera, che affrontano barriere comuni senza richiedere una ricostruzione completa del sito.

Tuttavia, gli overlay non sono un sostituto dei test. Integrano un programma di test, non lo rimpiazzano. L’approccio più efficace è usare un overlay per affrontare i problemi superficiali, a livello di presentazione, che possono essere gestiti in modo programmatico, mentre si utilizzano scansioni automatizzate, test manuali e validazione con screen reader per identificare e correggere i problemi strutturali — semantica rotta, ruoli ARIA mancanti, widget personalizzati inaccessibili — che richiedono interventi a livello di codice. Gli overlay funzionano al meglio quando la base di codice sottostante è stata testata e le lacune rimanenti riguardano le preferenze dell’utente piuttosto che barriere fondamentali di interazione.

Quando valuti qualsiasi strumento di accessibilità, overlay o altro, chiediti se è stato testato con screen reader reali. Un widget che crea una toolbar di accessibilità visibile ma introduce trappole di focus o conflitti ARIA nella pagina ha peggiorato la situazione, non migliorata. Le metodologie di test descritte in questa guida si applicano anche agli strumenti di accessibilità stessi, non solo ai siti su cui vengono eseguiti.

Punti chiave

• Nessuno strumento singolo è sufficiente. Gli scanner automatizzati rilevano solo il 30–40% delle violazioni WCAG. Un programma completo richiede test automatizzati, revisione manuale e test reali con tecnologie assistive che lavorino insieme come livelli complementari.
• Sposta l’accessibilità a monte. Integrare axe-core o Pa11y nella pipeline CI/CD significa che le violazioni vengono individuate prima che raggiungano la produzione, dove correggerle costa esponenzialmente di più in termini di tempo, reputazione e rischio legale.
• Testa con gli screen reader che le persone usano davvero. NVDA con Chrome e JAWS con Chrome dominano l’uso su desktop; VoiceOver su iOS domina il mobile. Copri almeno queste combinazioni e testa le interazioni dinamiche — modali, errori dei moduli, cambi di route nelle SPA — che gli strumenti automatizzati non rileveranno mai.
• Correggi i pattern, non solo le singole istanze. Se la struttura delle intestazioni è rotta, correggi il template. Se la gestione degli errori dei moduli è inaccessibile, correggi il componente. Le correzioni sistematiche offrono un valore esponenzialmente maggiore rispetto alle patch isolate.
• Rendi i test di accessibilità continui, non periodici. Un sito che oggi supera un audit tenderà a degradarsi. Integra i test nel ciclo di sviluppo — automatizzati a ogni commit, manuali a ogni sprint, test con tecnologie assistive per ogni funzionalità significativa — e l’accessibilità diventa una proprietà mantenuta del tuo prodotto, non un progetto di correzione straordinaria.