Accessibilità web: test automatici, tastiera e verifica umana nello stesso processo

I test di accessibilità web non si esauriscono con un punteggio generato da un’estensione. Un controllo efficace combina automazione, navigazione da tastiera, tecnologie assistive e valutazione umana. Ogni livello intercetta problemi diversi e produce evidenze che il team può correggere e verificare.

Il punto non è dichiarare un sito “accessibile” dopo una scansione, ma costruire un processo ripetibile durante progettazione, sviluppo e manutenzione. Questo approccio è ancora più importante dopo l’entrata in applicazione, il 28 giugno 2025, dell’European Accessibility Act per i prodotti e servizi che rientrano nel suo ambito.

Perché un solo strumento non basta

I test automatici sono rapidi e possono essere eseguiti su molte pagine. Individuano, per esempio, attributi mancanti, relazioni semantiche errate, alcuni problemi di contrasto e usi non validi di ARIA. Non possono però stabilire sempre se un testo alternativo descrive davvero l’immagine, se l’ordine di lettura è comprensibile o se un messaggio di errore aiuta una persona a completare un’attività.

L’automazione trova segnali; la verifica umana interpreta l’esperienza. Trattare i due livelli come alternativi crea una falsa sicurezza. Devono invece alimentare lo stesso registro delle anomalie.

1. Definire perimetro e percorsi critici

Prima di avviare qualsiasi tool, elencare pagine, componenti e attività che hanno maggiore impatto: navigazione, ricerca, autenticazione, acquisto, prenotazione, form di contatto, download e gestione degli errori. Un campione composto soltanto dalla homepage è quasi sempre insufficiente.

Per ogni percorso è utile annotare:

• punto di partenza e risultato atteso;
• stati intermedi, modali e messaggi di errore;
• componenti riutilizzati in più pagine;
• browser, viewport e tecnologia assistiva impiegati;
• criteri WCAG collegati e livello di priorità.

2. Inserire i test automatici nella pipeline

Un controllo automatico dovrebbe essere disponibile sia durante lo sviluppo sia nella pipeline CI/CD. In locale aiuta chi costruisce il componente; in integrazione continua impedisce che alcuni errori già risolti rientrino nelle versioni successive.

È meglio definire una baseline esplicita e ridurre progressivamente le violazioni esistenti, evitando che il team ignori centinaia di avvisi indistinti. Le regole bloccanti devono concentrarsi sui difetti più affidabili e gravi. Il resto può diventare un report da revisionare, non rumore da accantonare.

Come per una pipeline CI/CD sicura, responsabilità, soglie ed eccezioni devono essere documentate.

3. Eseguire un test completo da tastiera

La WCAG 2.2 richiede che la funzionalità sia utilizzabile tramite interfaccia da tastiera e che non si creino trappole. Il test parte senza mouse: si usano Tab, Shift+Tab, Invio, Spazio, frecce ed Esc secondo il comportamento atteso del componente.

Durante la prova bisogna verificare che:

• tutti i controlli interattivi ricevano il focus;
• l’ordine del focus segua una sequenza comprensibile;
• l’indicatore sia sempre visibile e non coperto da header, banner o modali;
• menu, finestre di dialogo e selettori possano essere aperti e chiusi;
• il focus ritorni nel punto corretto dopo la chiusura di un overlay;
• nessun componente intrappoli la navigazione.

Questo controllo completa il lavoro progettuale descritto nell’articolo su WCAG 2.2 per designer: il focus non deve soltanto esistere nel layout, deve funzionare nel prodotto reale.

4. Verificare struttura e contenuti con uno screen reader

Non serve trasformare ogni revisione in un audit specialistico completo, ma il team deve saper percorrere almeno le funzioni essenziali con uno screen reader diffuso. Si controllano titolo della pagina, gerarchia delle intestazioni, landmark, nomi accessibili dei controlli, annunci dinamici, errori dei form e cambi di stato.

La domanda utile non è “lo screen reader legge qualcosa?”, ma “la persona comprende dove si trova, cosa può fare e cosa è appena successo?”. Un pulsante annunciato soltanto come “button” è tecnicamente presente ma operativamente ambiguo.

5. Controllare contrasto, ingrandimento e reflow

Il controllo cromatico deve includere testo, icone funzionali, bordi indispensabili e stati di focus. Occorre poi aumentare lo zoom e verificare il reflow: informazioni e funzioni non dovrebbero scomparire, sovrapporsi o richiedere uno scorrimento scomodo quando la pagina si restringe.

La leggibilità dipende anche da dimensione, interlinea, lunghezza delle righe e distinzione tra livelli. La guida sui font per siti web leggibili approfondisce le decisioni tipografiche che accompagnano i requisiti tecnici.

6. Valutare testi alternativi, etichette ed errori

Qui la valutazione umana è decisiva. Un testo alternativo deve comunicare la funzione dell’immagine nel contesto, non ripetere meccanicamente il nome del file. Le etichette dei campi devono rimanere disponibili anche dopo la digitazione. Le istruzioni non possono dipendere soltanto da colore, posizione o forma.

Quando un invio fallisce, l’errore deve indicare quale campo richiede attenzione, spiegare come correggerlo e conservare i dati validi già inseriti. Un messaggio generico come “si è verificato un errore” non sostiene la persona e rende più difficile anche l’assistenza.

7. Registrare le anomalie in modo utile

Un problema di accessibilità diventa lavorabile quando contiene contesto sufficiente. Il ticket dovrebbe riportare URL o componente, passaggi per riprodurlo, comportamento osservato, risultato atteso, criterio di riferimento, impatto sull’utente, ambiente di test e una prova visiva o testuale.

La priorità non dovrebbe dipendere soltanto dal numero del criterio. Un ostacolo che impedisce l’acquisto o l’autenticazione ha un impatto diverso da un’imperfezione presente in un contenuto secondario. È utile distinguere almeno tra blocco, difficoltà grave, difficoltà moderata e miglioramento.

8. Ripetere il test dopo ogni correzione

La chiusura del ticket non coincide con la modifica del codice. Serve un retest nello stesso ambiente, seguito da un controllo di regressione sui componenti collegati. Quando la correzione riguarda un elemento riutilizzato, il team deve verificarne le principali varianti.

Lo stesso principio vale per prestazioni e stabilità: un intervento accessibile non deve introdurre un peggioramento evitabile. Un performance budget basato sui dati reali aiuta a mantenere insieme qualità tecniche diverse.

Protocollo minimo prima del rilascio

1. Eseguire la scansione automatica sulle pagine campione.
2. Completare i percorsi critici usando soltanto la tastiera.
3. Controllare struttura, nomi e messaggi con uno screen reader.
4. Verificare contrasto, zoom, reflow e orientamento.
5. Revisionare testi alternativi, etichette e istruzioni.
6. Registrare i difetti con impatto e criterio di accettazione.
7. Correggere, ripetere il test e controllare le regressioni.

Domande frequenti

Un punteggio automatico alto dimostra la conformità?

No. Dimostra soltanto che le regole eseguibili dallo strumento non hanno rilevato determinate violazioni. Molti requisiti richiedono contesto e giudizio umano.

Bisogna testare ogni pagina?

Un audit formale dipende dal perimetro e dalla metodologia adottata. Nel lavoro continuo conviene coprire template, componenti e percorsi rappresentativi, aumentando il campione dove esistono rischi o variazioni.

Chi è responsabile dell’accessibilità?

È una responsabilità condivisa: design, contenuti, sviluppo, qualità e product ownership prendono decisioni che possono creare o rimuovere barriere. Una persona competente deve però coordinare criteri e verifiche.

Fonti e data di verifica

• W3C – Web Content Accessibility Guidelines (WCAG) 2.2
• W3C WAI – Novità introdotte dalle WCAG 2.2
• AgID – Linee guida sui requisiti di accessibilità dei servizi
• Commissione europea – Applicazione dell’European Accessibility Act

Fonti verificate il 4 dicembre 2025. Le indicazioni operative non sostituiscono una valutazione legale del servizio o un audit di conformità svolto sul caso concreto.