Un assistente genera un sito e dichiara di averlo reso accessibile. Chi usa VoiceOver o un altro lettore di schermo può cominciare verificando un compito: trovare un contenuto, compilare un modulo, ricevere la conferma. Il risultato di questa prova dice quali passaggi funzionano nella propria configurazione. Per valutare il sito occorre affiancare a questa prova controlli sul codice e verifiche che coprano anche le esigenze delle persone ipovedenti.
Chiedere un risultato verificabile
Le WCAG 2.2 del W3C, pubblicate per la prima volta il 5 ottobre 2023 e aggiornate il 12 dicembre 2024, forniscono criteri verificabili per i contenuti web. Una richiesta all’assistente può indicare questa versione e il livello AA come obiettivo tecnico. La conformità AA richiede il rispetto dei criteri applicabili di livello A e AA: citare lo standard nel prompt avvia il lavoro, mentre l’esito dipende dalle verifiche sul prodotto.
Suggeriamo di descrivere anche il comportamento desiderato. Per un modulo di contatto, per esempio: ogni campo deve avere un nome comprensibile al lettore di schermo; i comandi devono essere raggiungibili da tastiera; un errore deve permettere di identificare il campo da correggere. Queste richieste trasformano una promessa generica in attività da eseguire e documentare.
Che cosa dimostra un controllo automatico
Nella guida alla scelta degli strumenti di valutazione, il W3C spiega che i controlli automatici aiutano a individuare problemi e possono affiancare la revisione manuale. Alcune valutazioni richiedono giudizio umano; gli strumenti possono anche produrre risultati inesatti. Un rapporto senza errori rilevati riguarda quindi i controlli eseguiti sulle pagine analizzate.
Quando un assistente afferma di aver verificato il sito, chiediamo il nome dello strumento, le pagine esaminate e i risultati. Facciamo distinguere le prove effettivamente eseguite dai suggerimenti ancora da applicare. Se è stata controllata soltanto la pagina iniziale, rimangono da esaminare gli altri percorsi: un modulo con dati errati, una finestra aperta o una schermata dopo l’accesso possono comportarsi diversamente.
Tastiera e lettore di schermo sul percorso completo
Le Easy Checks del W3C propongono un primo esame di titoli, intestazioni, immagini, contrasto, tastiera e moduli. Sono verifiche preliminari: il loro superamento lascia ancora possibili ostacoli da cercare con un esame più approfondito.
Per la prova da tastiera suggeriamo di attraversare i comandi con Tab e Maiusc-Tab, controllare l’ordine e provare sia l’apertura sia la chiusura dei componenti. Con il lettore di schermo si ascoltano i nomi dei campi e dei pulsanti e si percorrono le intestazioni. Per un modulo, proviamo anche un invio incompleto: bisogna capire quale dato manca e riuscire a raggiungere il campo interessato.
Un esempio di segnalazione utile è: «Nel modulo Contatti, dopo l’invio con il campo email vuoto, il messaggio di errore compare ma VoiceOver non lo annuncia». Aggiungiamo browser, sistema operativo e versioni. L’assistente o lo sviluppatore avranno un passaggio preciso da ripetere dopo la correzione.
Ingrandimento e focus per chi è ipovedente
Il criterio WCAG 1.4.10, Reflow, riguarda la disposizione dei contenuti quando lo spazio si riduce. Per una pagina a scorrimento verticale, il riferimento è una larghezza equivalente a 320 pixel CSS: testi e funzioni devono rimanere disponibili senza imporre anche lo scorrimento orizzontale, salvo contenuti che richiedono una disposizione bidimensionale. Mappe e tabelle possono rientrare nelle eccezioni; una normale colonna di testo no.
Nella prova si aumenta lo zoom e si osservano menu, campi e pulsanti, anche quando compaiono messaggi di errore. Chi usa soltanto la sintesi vocale può documentare i problemi incontrati personalmente; per valutare anche la leggibilità visiva è utile coinvolgere chi utilizza ingrandimento e adattamenti dei colori.
Il criterio 2.4.11, Focus non oscurato, livello minimo, richiede che il componente su cui si sposta il focus da tastiera rimanga almeno parzialmente visibile rispetto ai contenuti creati dall’autore. Una barra fissa o un banner possono coprire proprio il pulsante raggiunto. Il controllo va ripetuto mentre ci si sposta nella pagina, senza fermarsi a una schermata immobile.
Annotare le prove e ripeterle dopo le correzioni
Il W3C raccomanda di combinare la valutazione con utenti e gli standard. Persone con esperienza e tecnologie assistive diverse possono incontrare ostacoli diversi. Una prova individuale aiuta a individuare ostacoli, ma il suo risultato non si estende automaticamente a ogni persona o configurazione.
Per noi, un resoconto utile registra pagina, attività, strumenti impiegati, risultato atteso e comportamento osservato. Dopo una modifica si ripete lo stesso percorso e si annota l’esito. Le verifiche ancora aperte devono restare riconoscibili nel rapporto. Le guide W3C collegate permettono di preparare questo primo controllo; una valutazione completa richiede competenze di accessibilità e un insieme di pagine e attività rappresentativo del servizio.
Chiedi a Sonar su questo articolo
Sonar è l’assistente di TecnoAccess: risponde usando solo gli articoli della testata e ti dice sempre di quando è la cosa che racconta.
Iscriviti e ricevi il libro in regalo
Iscrivendoti alla newsletter ricevi subito «AI e disabilità visiva 2026», il nostro libro di 67 pagine sugli strumenti che funzionano davvero, in EPUB e in PDF accessibile.
Poi, ogni venerdì mattina, le notizie della settimana e un consiglio pratico su VoiceOver, NVDA o TalkBack che pubblichiamo solo lì. È gratis e ci si disiscrive con un clic.