Rendere un form accessibile secondo le WCAG 2.2 è un’attività che richiede un discreto numero di accortezze.
Non tutti i form sono uguali o hanno la stessa complessità, ma sono almeno 27 i criteri di successo a cui fare attenzione.
Questo articolo li percorre uno per uno: per ciascuno trovi cosa richiede la norma, l’errore che lo fa fallire più spesso e come si implementa correttamente.
Form accessibile in breve
Un form accessibile è un modulo che qualsiasi utente può compilare e inviare in autonomia, indipendentemente dalla tecnologia che usa per accedervi (screen reader, navigazione da sola tastiera, comando vocale, ingrandimento dello schermo).
In termini operativi significa quattro cose:
- ogni campo ha un’etichetta associata a livello di codice, non solo visivamente;
- tutto è raggiungibile e attivabile con la tastiera, e il focus è sempre visibile;
- gli errori sono descritti in testo, collegati al campo giusto, con l’indicazione di come correggerli;
- ogni feedback dinamico viene annunciato alle tecnologie assistive.
Il resto della guida è, in larga parte, l’esplosione di questi quattro punti nei criteri di successo che li formalizzano.
Una premessa di metodo: non esiste una lista ufficiale
Le WCAG non contengono un capitolo intitolato “form di contatto” con un elenco chiuso di criteri da spuntare.
Non hanno regole scritte apposta per i form, ma hanno criteri generali che valgono per qualsiasi contenuto, e sta a te capire quali si applicano all’elemento che stai valutando.
Ho individuato i 27 criteri di successo che un form semplice o classico deve rispettare e altri 3 criteri, trattati a parte, per i form più complessi.
Una checklist pratica da scaricare
I 27 criteri elencati in questo articolo per la creazione di un form accessibile semplice, più i 3 criteri per i casi più complessi, li ho raccolti per praticità in una checklist in Excel pronta da compilare: per ciascuno trovi una breve spiegazione e una colonna per segnare se il criterio è da verificare, conforme, non conforme oppure non applicabile.
Può esserti molto utile, ma ti consiglio comunque di leggere l’articolo per intero per trovare le spiegazioni estese, esempi ed errori comuni.
I 27 criteri WCAG 2.2 che deve rispettare un form accessibile
Sezione dei criteri percepibili
Criterio 1.3.1 – Informazioni e correlazioni (A)
Cosa richiede. Tutto ciò che si capisce guardando la pagina deve essere disponibile anche a chi non la guarda. Se un utente vedente capisce che quella scritta è l’etichetta di quel campo, un lettore di schermo deve poterlo capire allo stesso modo.
L’errore più frequente. L’etichetta è scritta sopra il campo ma non è un vero elemento <label> collegato a esso: visivamente sembra tutto a posto, mentre chi usa un lettore di schermo sente annunciare soltanto “casella di testo”, senza sapere cosa scriverci. È il difetto più diffuso in assoluto nei form.
Stesso problema con i gruppi di scelte: se ci sono due pulsanti “Sì” e “No” senza un <fieldset> che li raccolga e una <legend> che riporti la domanda, l’utente sente le opzioni ma non la domanda. E con l’asterisco rosso dei campi obbligatori, quando è solo un segno grafico.
Come si implementa. Ogni campo ha la sua <label>, agganciata tramite l’attributo for che richiama l’id del campo. È un’operazione standard che qualsiasi sviluppatore conosce e che i plugin per form seri gestiscono già da soli. L’obbligatorietà si dichiara con l’attributo required, così il browser la riconosce, invece di affidarla al solo asterisco rosso.
Come verificarlo senza saper leggere il codice: clicca sul testo dell’etichetta, non sul campo. Se il cursore salta dentro il campo, il collegamento c’è. Se non succede niente, manca.
Criterio 1.3.5 – Identificare lo scopo dell’input (AA)
Cosa richiede. I campi che raccolgono dati della persona, come nome, email, telefono e indirizzo, devono dichiarare al browser che tipo di dato si aspettano. Si fa con l’attributo autocomplete, che ha un valore predefinito per ciascun tipo di dato: name, email, tel e così via.
Perché conta davvero. Non è un formalismo: è quello che fa funzionare il completamento automatico. Per chi ha difficoltà motorie significa risparmiare decine di battute su ogni form. E alcune tecnologie assistive usano la stessa informazione per sostituire l’etichetta scritta con un’icona, cosa preziosa per chi ha difficoltà di lettura.
L’errore più frequente. Dimenticarsene. Oppure disattivarlo su tutto il form con autocomplete="off", scelta che quasi mai ha una giustificazione reale.
Come verificarlo: compila il form usando il salvataggio dati del tuo browser. Se nome ed email si riempiono da soli, l’informazione c’è.
Criterio 1.4.1 – Uso del colore (A)
Cosa richiede. Nessuna informazione può essere affidata al solo colore.
L’errore più frequente. Il caso da manuale è segnalare un campo sbagliato solo con un bordo rosso e un campo corretto con il bordo verde. Per chi ha una difficoltà nella percezione dei colori, i due stati sono identici.
Come si implementa. Al bordo colorato si affianca sempre un messaggio scritto sotto il campo, ed eventualmente un’icona. Il colore resta, ma come rinforzo: non è più l’unico canale.
Criterio 1.4.3 – Contrasto minimo (AA)
Cosa richiede. Il testo deve staccarsi abbastanza dallo sfondo. La norma indica un rapporto di 4,5 a 1 per il testo di dimensione normale, che non serve calcolare a mano: esistono strumenti gratuiti che lo misurano con un clic.
Gli errori più frequenti:
- Il testo grigio chiaro che compare dentro i campi vuoti, il
placeholder, quasi sempre troppo tenue. - Il contrasto fra testo digitato dall’utente e sfondo del campo di inserimento.
- I messaggi di errore: il rosso “da avviso” su fondo bianco è quasi sempre sotto soglia, e serve un rosso più scuro.
(Io uso il codice #A9141E, che su sfondo bianco passa il test di contrasto fino al livello AAA).
Una precisazione per completezza.
Il placeholder non è un’etichetta e non può sostituire la <label>.
Sparisce appena la persona inizia a scrivere: chi si distrae a metà compilazione non ha più modo di sapere cosa andava in quel campo.
Le etichette vanno scritte sopra il campo e devono restare visibili sempre e collegate via codice come da criterio 1.3.1.
Suggerimento: se cerchi un grigio non troppo scuro, adatto a sembrare un placeholder, ma che rispetta su sfondo chiaro il contrasto necessario… io utilizzo il #595959.
Un’estensione di Chrome che uso frequentemente e che puoi usare anche tu per i controlli di accessibilità è Silktide.
Criterio 1.4.4 – Ridimensionamento del testo (AA)
Cosa richiede. Il testo deve potersi ingrandire fino al doppio senza che si perda contenuto o funzionalità. È un’esigenza diffusa, non di nicchia: la usa chiunque abbia una vista un po’ affaticata, non solo chi ha una disabilità visiva riconosciuta.
L’errore più frequente. Dimensioni del testo bloccate in pixel dentro contenitori con altezza fissa.
Il testo cresce, il riquadro no, e il risultato è un’etichetta tagliata a metà o un pulsante in cui la scritta esce dai bordi. I campi affiancati su due colonne peggiorano la situazione, perché lo spazio in larghezza è già stretto in partenza.
Da non confondere con il reflow del 1.4.10 – lì è lo schermo a essere stretto, qui è la persona che ha bisogno di caratteri più grandi.
Un form può superare una prova e fallire l’altra.
Come verificarlo: ingrandisci la pagina al 200% con la scorciatoia del browser e ricompila il form dall’inizio.
Nulla deve sparire, sovrapporsi o risultare tagliato.
Criterio 1.4.10 – Reflow (AA)
Cosa richiede. Il form deve restare utilizzabile anche su uno schermo molto stretto, senza costringere a scorrere lateralmente. La soglia della norma corrisponde più o meno alla larghezza di uno smartphone tenuto in verticale.
L’errore più frequente. I form su due colonne costruiti con misure fisse: quando lo spazio si riduce le colonne non si incolonnano, e il secondo campo finisce fuori dallo schermo. Chi legge deve scorrere avanti e indietro per compilare una riga.
Come verificarlo: restringi la finestra del browser fino a renderla stretta come un telefono. Tutto deve incolonnarsi e restare leggibile, senza barra di scorrimento orizzontale.
Criterio 1.4.11 – Contrasto non testuale (AA)
Cosa richiede. Il contrasto non riguarda solo il testo. Anche i bordi dei campi, i quadratini da spuntare e l’indicatore che mostra dove ci si trova devono essere percepibili: qui la soglia è 3 a 1.
L’errore più frequente. Il bordo dei campi. Il design contemporaneo ama i contorni grigio chiarissimo, che spesso restano sotto soglia. Se quel bordo è l’unica cosa che dice “qui puoi scrivere”, deve vedersi.
Criterio 1.4.12 – Spaziatura del testo (AA)
Cosa richiede. Il form deve reggere anche quando è l’utente a modificare le spaziature del testo: distanza tra le righe, tra le parole, tra le lettere e tra i paragrafi. Sono impostazioni che usa chi ha difficoltà di lettura, in particolare chi è dislessico.
L’errore più frequente. I pulsanti e i contenitori con altezza bloccata: appena l’interlinea si allarga, il testo esce dal riquadro o viene tagliato. La causa tecnica è la stessa del criterio precedente, cioè le misure fisse, ma lo scenario è diverso: qui la larghezza dello schermo non cambia, cambia il modo in cui il testo occupa lo spazio.
Come verificarlo: esiste un segnalibro gratuito pubblicato dal W3C che applica alla pagina le spaziature previste dalla norma. Dopo averlo attivato, nessun testo deve risultare tagliato o sovrapposto.
Sezione dei criteri utilizzabili
Criterio 2.1.1 – Tastiera (A)
Cosa richiede. Tutto il form deve essere utilizzabile senza mouse.
L’errore più frequente. Non riguarda solo i campi normali, che funzionano in genere già bene di loro, ma anche tutto ciò che riguarda il form: calendari, menu a tendina, aree in cui trascinare i file.
Tutto deve essere raggiungibile dal tasto Tab e rispondere a Invio.
Come si implementa. La regola pratica è una sola: prima di far costruire un controllo su misura, verificare se esiste già quello nativo del browser.
Per le date c’è <input type="date">, per i menu a tendina c’è <select>: sono accessibili di partenza, senza lavoro aggiuntivo.
Come verificarlo: allontana il mouse e compila l’intero form usando solo Tab per spostarti, le frecce per scegliere, la barra spaziatrice per spuntare e Invio per inviare. È il test più rapido e quello che scova più problemi.
Criterio 2.1.2 – Nessuna trappola per il focus da tastiera (A)
Cosa richiede. Da qualunque elemento si deve poter uscire usando la sola tastiera. Non basta poter entrare in un componente: bisogna anche poterlo abbandonare.
L’errore più frequente. Le finestrelle che si aprono sopra la pagina, calendari e riquadri di conferma compresi: si entra e non si esce più, perché il tasto Esc non è stato previsto e il giro del Tab resta chiuso lì dentro.
Chi naviga da tastiera a quel punto deve ricaricare la pagina, perdendo quanto già scritto.
Come verificarlo: apri ogni pannello del form e prova a uscirne con Esc, poi con Tab. Se resti bloccato, hai trovato una trappola.
Criterio 2.2.1 – Regolazione dei tempi (A)
Cosa richiede. Se esiste un limite di tempo, l’utente deve poterlo disattivare, allungare o quantomeno essere avvisato prima che scada.
L’errore più frequente. Non è un criterio che verrebbe in mente pensando a un form di contatto, ma diventa rilevante ogni volta che la pagina ha una sessione che scade: dopo un quarto d’ora di inattività il sistema invalida l’invio. Chi compila lentamente, perché usa un lettore di schermo o ha una difficoltà motoria o sta cercando i dati su un documento, clicca “Invia” e perde tutto.
Come si implementa. Avvisare prima della scadenza, con la possibilità di proseguire. E, in ogni caso, conservare quanto già scritto se l’invio fallisce. Perdere dieci minuti di testo è un fastidio per tutti e una barriera per molti.
Criterio 2.4.3 – Ordine del focus (A)
Cosa richiede. L’ordine con cui il tasto Tab attraversa i campi deve essere logico e corrispondere all’ordine di lettura.
L’errore più frequente. Le colonne riordinate graficamente. Con il CSS si può spostare un campo a destra o a sinistra intervenendo solo sull’aspetto, senza cambiarne la posizione nel codice, che corrisponde all’ordine seguito dal tasto Tab.
Il risultato è che l’ordine visivo e quello di tabulazione divergono, e il cursore salta avanti e indietro senza senso apparente. Nei form su due colonne succede spesso.
Secondo responsabile: l’attributo tabindex con valori positivi, che scavalca l’ordine naturale della pagina e va evitato.
Come verificarlo: premi Tab dall’inizio alla fine e osserva il percorso. Deve seguire l’ordine in cui leggeresti la pagina.
Criterio 2.4.6 – Intestazioni ed etichette (AA)
Cosa richiede. Le etichette devono descrivere davvero cosa va scritto nel campo.
Non è la stessa cosa del criterio 1.3.1: quello chiede che l’etichetta sia collegata al campo, questo che sia scritta bene.
Un campo con l’etichetta “Campo 1” perfettamente collegata soddisfa il primo e fallisce il secondo.
L’errore più frequente. Le etichette generiche: “Altro”, “Note”, “Dati”, “Info”.
Chi vede la pagina intera le interpreta dal contesto, perché ha davanti anche il titolo della sezione e i campi vicini.
Assicurati di avere etichette comprensibili.
Nel caso di un form per prenotare un trasferimento privato, ad esempio:
“Altro” può diventare “Altre richieste sul viaggio”
“Note” può diventare “Note per l’autista”.
Vale anche per i titoli delle sezioni, se il form è diviso in parti.
Come verificarlo: leggi solo l’elenco delle etichette, coprendo il resto della pagina.
Se basta a capire cosa scrivere in ogni campo, il criterio è rispettato.
Criterio 2.4.7 – Focus visibile (AA)
Cosa richiede. Deve sempre essere visibile su quale elemento ci si trova mentre si naviga da tastiera.
L’errore più frequente. La rimozione del contorno che i browser disegnano attorno all’elemento attivo, con la riga di CSS outline: none.
Per anni è stata una pratica di “pulizia” diffusissima nei fogli di stile, ed è probabilmente la singola scelta che ha fatto più danni all’accessibilità del web. Chi naviga senza mouse resta senza alcun riferimento su dove si trova.
Come si implementa. Se il contorno predefinito non piace, si sostituisce con uno più curato usando :focus-visible, che lo mostra solo a chi naviga da tastiera e non a chi clicca: l’obiezione più comune dei designer cade da sola. Quello che non si fa è eliminarlo. Un accorgimento utile: non usare lo stesso colore per l’elemento attivo e per l’elemento in errore, altrimenti i due stati diventano indistinguibili.
Criterio 2.4.11 – Focus non oscurato, minimo (AA)
Cosa richiede. L’elemento su cui ci si trova non deve finire completamente nascosto sotto altri elementi della pagina.
Perché è interessante. È forse la novità più immediatamente riconoscibile delle 2.2, perché descrive una situazione che chiunque abbia provato a navigare da tastiera conosce: si preme Tab, la pagina scorre, e il campo attivo scompare sotto il menu fisso in alto. Si sta scrivendo alla cieca.
L’errore più frequente. Menu fissi, banner dei cookie, riquadri di chat in basso a destra, barre promozionali ancorate al fondo. Tutti elementi che convivono male con un form lungo.
Come si implementa. Lato codice si risolve con scroll-margin-top sugli elementi selezionabili, impostato all’altezza del menu fisso: la pagina scorre lasciando il campo scoperto.
Come verificarlo: naviga con Tab a pagina già scorsa, tenendo aperto il banner dei cookie. Il campo attivo deve restare sempre visibile.
Criterio 2.5.3 – Etichetta nel nome (A)
Cosa richiede. Il nome con cui un pulsante è registrato internamente deve contenere il testo che si legge sopra.
Perché conta. Riguarda chi usa i comandi vocali. Se la persona dice “clicca Invia richiesta” ma il pulsante internamente si chiama diversamente, il comando non trova corrispondenza e non succede nulla.
L’errore più frequente. Un aria-label aggiunto “per sicurezza”, che non affianca il testo visibile ma lo sostituisce, spesso restando in inglese nei plugin non tradotti. Se il pulsante ha già un testo leggibile, quell’attributo non serve.
Criterio 2.5.7 – Trascinamento (AA)
Cosa richiede. Ogni funzione che si attiva trascinando deve avere un’alternativa che funzioni con un semplice clic.
L’errore più frequente. L’area “trascina qui i tuoi file”.
Se trascinare è l’unico modo per allegare un documento, il criterio non è rispettato: chi ha un tremore alle mani, chi usa un dispositivo di puntamento alternativo o chi naviga da tastiera resta tagliato fuori.
Come si implementa. Accanto all’area di trascinamento serve sempre un <input type="file"> con un pulsante “Sfoglia”.
Nella maggior parte dei casi esiste già ma è stato nascosto con display: none, che lo rende irraggiungibile anche da tastiera: va nascosto in altro modo, o semplicemente mostrato.
Criterio 2.5.8 – Dimensione del target, minimo (AA)
Cosa richiede. Gli elementi da cliccare devono misurare almeno 24 per 24 pixel, oppure avere attorno abbastanza spazio libero da non rischiare di colpire quello sbagliato.
L’errore più frequente. Il quadratino di accettazione della privacy lasciato alla dimensione predefinita del browser, che è di circa 13 pixel: spesso è l’unico elemento del form rimasto senza personalizzazione, mentre tutto il resto è stato curato.
Una buona notizia. Se l’etichetta è collegata correttamente al quadratino, cioè se è rispettato il criterio 1.3.1, l’area cliccabile si estende a tutto il testo, e la soglia è ampiamente superata.
(Ingrandire il quadratino resta comunque consigliabile: su telefono, un bersaglio di 13 pixel è difficile da centrare per chiunque, e spesso ha il link alla privacy proprio accanto).
Sezione dei criteri comprensibili
Criterio 3.2.1 – Al focus (A)
Cosa richiede. Il semplice arrivare su un campo non deve provocare cambiamenti automatici della pagina.
L’errore più frequente. La finestrella che si apre da sola quando un campo riceve il cursore, tipicamente un calendario.
Chi attraversa il form con il Tab si trova davanti pannelli che compaiono senza averli chiesti, e che coprono i campi successivi.
Come verificarlo: attraversa tutti i campi con il Tab senza digitare nulla. Non deve succedere niente che tu non abbia chiesto.
Criterio 3.2.2 – All’input (A)
Cosa richiede. Modificare il contenuto di un campo non deve provocare invii, ricaricamenti o spostamenti del cursore decisi dal sistema.
L’errore più frequente. Due casi classici:
- Il menu a tendina che invia il form o ricarica la pagina appena si cambia opzione: chi lo scorre con le frecce fa partire l’azione alla prima voce incontrata, senza aver scelto niente.
- Il cursore che salta da solo al campo successivo quando quello corrente è pieno, tipico dei codici di verifica: chi vuole correggere una cifra si ritrova altrove.
Come si implementa. Ogni cambiamento deve seguire un’azione voluta: un pulsante da premere, una conferma da dare. Mai come effetto collaterale del semplice compilare il form.
Criterio 3.3.1 – Identificazione degli errori (A)
Cosa richiede. Quando il sistema rileva un errore, deve dire a parole qual è e indicare chiaramente quale campo lo contiene.
L’errore più frequente. Il messaggio generico in cima al form, “Si sono verificati degli errori”, che non dice dove.
Oppure, molto più spesso, la sola colorazione del bordo: nessun testo, nessun collegamento tra campo e problema.
In questo caso chi usa un lettore di schermo attraversa il campo senza che venga mai annunciato alcun errore, e il form diventa impossibile da completare.
Come si implementa. Il messaggio va scritto sotto il campo interessato e collegato a esso con aria-describedby, mentre il campo si marca come non valido con aria-invalid.
Così chi ci arriva con il Tab sente subito qual è il problema.
Se il form è lungo, conviene aggiungere in cima un riepilogo degli errori con i collegamenti ai campi da correggere.
Criterio 3.3.2 – Etichette o istruzioni (A)
Cosa richiede. Quando serve un formato particolare o ci sono vincoli da rispettare, vanno dichiarati.
Il punto chiave è il momento. Le istruzioni servono prima dell’invio, non dopo. Se il campo telefono accetta solo cifre senza spazi, va scritto sotto il campo: non si aspetta che la persona sbagli per dirglielo. Anche questa indicazione va collegata al campo con aria-describedby, lo stesso attributo usato per gli errori, e può contenerli entrambi.
Gli errori più frequenti. Due varianti. La prima: il formato non è indicato da nessuna parte, e si scopre solo sbagliando. La seconda, più insidiosa: l’indicazione c’è, ma è scritta in grigio dentro il campo vuoto, quindi sparisce nel momento esatto in cui si inizia a scrivere, cioè quando servirebbe.
C’è poi una convenzione che quasi tutti usano e quasi nessuno spiega: l’asterisco sui campi obbligatori. Se da nessuna parte compare la frase “I campi contrassegnati con l’asterisco sono obbligatori”, si sta dando per scontata una convenzione che universale non è.
Criterio 3.3.3 – Suggerimenti per gli errori (AA)
Cosa richiede. Il messaggio di errore deve dire come correggere, non limitarsi a segnalare che qualcosa non va.
Gli errori più frequenti. “Campo non valido”. “Errore”. “Formato errato”. Messaggi che comunicano il fallimento senza indicare la via d’uscita. È il criterio che si risolve scrivendo meglio, non programmando meglio: spesso basta rivedere i testi predefiniti del plugin.
| Messaggio che non basta | Messaggio che funziona |
|---|---|
| Email non valida | L’indirizzo deve contenere una chiocciola e un dominio. Esempio: nome@dominio.it |
| Data non valida | Inserisci la data nel formato giorno/mese/anno, ad esempio 15/03/2026 |
| Valore non valido | Inserisci solo cifre, senza testo. Esempio: 5 |
| Campo obbligatorio | Inserisci il tuo indirizzo email |
Criterio 3.3.7 – Inserimento ridondante (A)
Cosa richiede. In un percorso a più passaggi, i dati già forniti non vanno richiesti una seconda volta.
Fanno eccezione i casi in cui la ripetizione è essenziale, es. conferma di una nuova password.
L’errore più frequente. Il campo “conferma indirizzo email”.
Costringe a riscrivere un dato lungo, e chi usa copia e incolla lo duplica identico rendendo il controllo inutile: non verifica nulla e complica tutto.
Il caso più netto è il form a più schermate che nel riepilogo finale chiede di reinserire quello che è già stato scritto prima.
Come si implementa. I dati già inseriti si mostrano precompilati, con la possibilità di modificarli. E si rinuncia al campo di conferma dell’email: se serve verificare l’indirizzo, si manda un messaggio di conferma.
Criterio 3.3.8 – Autenticazione accessibile, minimo (AA)
Cosa richiede. Nessuna prova che richieda uno sforzo di memoria o di ragionamento può essere l’unico modo per accedere: ricordare una password, risolvere un rompicapo, ricopiare caratteri deformati. Deve sempre esistere un’alternativa.
Quando si applica. Solo se il form si trova dietro un accesso riservato.
Un form di contatto pubblico non è interessato.
Attenzione però, il criterio richiede espressamente che il campo password consenta di incollare e funzioni con i gestori di password. Se il tuo accesso riservato blocca l’incolla “per motivi di sicurezza”, il criterio non è rispettato.
Sezione dei criteri robusti
Criterio 4.1.2 – Nome, ruolo, valore (A)
Cosa richiede. Ogni elemento interattivo deve dichiarare che cosa è, come si chiama e in che stato si trova. Un quadratino da spuntare deve annunciarsi come tale, e deve far sapere se è spuntato o no.
L’errore più frequente. Ancora una volta, i controlli ricostruiti su misura per ragioni grafiche: un <div> travestito da casella di spunta, senza role che ne dichiari la natura né aria-checked che ne comunichi lo stato.
Somiglia a quello vero, ma per una tecnologia assistiva è un elemento senza identità.
Come si implementa. Usando i controlli nativi tutte le volte che è possibile: un <input type="checkbox"> è già completo di nome, ruolo, stato e gestione da tastiera senza che nessuno debba scrivere una riga in più. Personalizzarne l’aspetto si può, e la proprietà accent-color ne cambia il colore senza sostituirlo. Ricostruirlo da capo quasi mai conviene.
Criterio 4.1.3 – Messaggi di stato (AA)
Cosa richiede. I messaggi che compaiono senza che l’utente cambi pagina, come “Messaggio inviato”, “3 campi da correggere” o “invio in corso”, devono essere comunicati anche a chi non guarda lo schermo, e senza spostare il cursore.
Perché è cruciale in un form. È il criterio che governa tutto ciò che accade dopo il clic su “Invia”.
Se il messaggio di conferma compare solo visivamente, per un lettore di schermo semplicemente non esiste: la persona clicca, non percepisce nulla, e riclicca. Sono le richieste doppie che a volte si trovano nella casella di posta senza spiegazione.
Come si implementa. Serve un contenitore marcato con aria-live="polite" oppure role="status", una live region, che le tecnologie assistive leggono da sole appena si riempie. Il dettaglio che fa la differenza: deve essere già presente e vuoto al caricamento della pagina, perché se viene inserito insieme al messaggio molti lettori di schermo non lo annunciano.
Come verificarlo: è l’unico criterio dell’elenco che richiede davvero un lettore di schermo. Invia il form con NVDA o VoiceOver attivo e ascolta se l’esito viene annunciato.
I criteri aggiuntivi per i form più complessi
I 27 criteri visti finora valgono per i form semplici: qualche campo, una casella da spuntare, un pulsante.
Ogni funzione in più ne aggiunge altri, e sono quelli che seguono.
Non sostituiscono i precedenti, si sommano: un form con un CAPTCHA e un invio vincolante ne deve rispettare 29, non 27.
Criterio 1.1.1 – Contenuto non testuale (A): se c’è un CAPTCHA
Il CAPTCHA non ha un criterio tutto suo, ma ricade in quello sulle alternative testuali: bisogna spiegare a cosa serve la prova e offrirne versioni che coinvolgano sensi diversi. Un CAPTCHA visivo dovrebbe quindi avere almeno un’alternativa sonora, la quale a sua volta è una barriera per chi non sente e un ostacolo per chi sta in ufficio senza cuffie.
È la barriera che genera più abbandoni reali sui form di contatto, e la direzione sensata è toglierla del tutto. Esistono soluzioni che filtrano i messaggi automatici senza chiedere niente a chi compila: campi nascosti che solo i programmi automatici riempiono, analisi del comportamento, limiti sul numero di invii, sistemi di verifica invisibile. Tutte spostano il lavoro dall’utente al server, che è dove dovrebbe stare.
Se una prova esplicita è inevitabile, una domanda semplice in linguaggio naturale è comunque preferibile ai caratteri deformati da ricopiare, pur restando una barriera per chi ha difficoltà cognitive.
Criterio 2.5.1 – Gesti puntatore (A): se ci sono slider o controlli a più dita
Ogni funzione che richiede un gesto complesso, cioè un movimento che segue un percorso o che usa più dita contemporaneamente, deve avere un’alternativa che funzioni con un semplice tocco.
Nei form di contatto compare raramente, ma c’è un caso ricorrente: il cursore scorrevole per indicare un budget, un numero di persone o una fascia di prezzo.
Se l’unico modo per impostare il valore è trascinare la maniglia, chi ha un tremore o usa un dispositivo di puntamento alternativo non ci riesce.
La soluzione è affiancare al cursore un campo numerico in cui scrivere il valore, oppure due pulsanti per aumentarlo e diminuirlo. Il criterio è vicino a 2.5.7 sul trascinamento, ma non coincide: quello riguarda lo spostare oggetti, questo i gesti in sé.
Criterio 3.3.4 – Prevenzione degli errori (AA): se l’invio ha valore legale o contrattuale
Si applica quando l’invio comporta impegni legali, pagamenti o modifiche di dati già registrati. Un form di contatto ordinario ne è escluso; una richiesta di preventivo vincolante, un’iscrizione o una revoca di consenso no.
In quei casi serve almeno una di tre cose: che l’invio sia annullabile, che i dati siano controllati con possibilità di correzione, oppure che ci sia una schermata di conferma prima dell’invio definitivo. Il riepilogo con il pulsante “Conferma” è la soluzione più comune, e va costruito mostrando i dati già inseriti, non richiedendoli di nuovo.
Come verificare che il tuo form sia accessibile
Gli strumenti automatici come Silktide, axe, WAVE e Lighthouse intercettano solo una parte dei problemi elencati qui sopra.
Trovano l’etichetta mancante o segnalano un contrasto insufficiente… non si accorgono di un messaggio d’errore inutile, di un ordine di navigazione illogico o di una conferma che nessuno annuncia.
Tre prove manuali che puoi fare:
- Metti via il mouse.
Compila tutto il form usando solo la tastiera: ogni campo, ogni controllo, l’invio, un errore, la correzione. Se in qualche momento non capisci dove ti trovi, hai trovato un problema. - Provoca gli errori.
Invia il form vuoto. Scrivi un’email senza chiocciola. Metti del testo dove va un numero. La maggior parte dei difetti vive negli stati di errore, che sono anche quelli che nessuno prova mai. - Ascoltalo.
NVDA per Windows o VoiceOver su Mac (⌘ + F5) e ottieni più informazioni di quante ne dia qualsiasi rapporto automatico.
Chiudi gli occhi e prova a inviare una richiesta.
Se il budget lo consente, il passo successivo è il test con persone con disabilità.
Nessuna simulazione sostituisce davvero chi usa quelle tecnologie ogni giorno.
Domande frequenti
Non esiste un numero fisso. I criteri di livello A e AA delle WCAG 2.2 sono 55 in totale (31 di livello A e 24 di livello AA), e un form di contatto semplice ne coinvolge 27. Il numero esatto dipende da come è fatto: CAPTCHA, cursori scorrevoli, invii con valore contrattuale e accesso riservato ne aggiungono altri.
No. Sparisce appena la persona inizia a scrivere, quindi non è un’indicazione stabile, e il suo colore è quasi sempre troppo tenue. Un form accessibile ha etichette visibili sopra i campi, sempre presenti; il testo dentro il campo, se usato, mostra al massimo un esempio di formato.
La norma europea in vigore, la EN 301 549, recepisce oggi le WCAG 2.1 di livello AA. Ma la 2.2 aggiunge criteri senza rimuoverne, quindi progettare sulla 2.2 garantisce già la conformità alla 2.1 ed evita di dover rifare il lavoro quando la norma verrà aggiornata.
Non automaticamente, ma è una delle barriere più problematiche. Servono un’alternativa testuale e modalità che coinvolgano sensi diversi. La soluzione migliore resta eliminare la prova per l’utente, usando sistemi di filtro che lavorano dietro le quinte.
No. Coprono solo una parte dei problemi reali: rilevano etichette mancanti e contrasti insufficienti, ma non valutano la qualità di un messaggio d’errore, la logica dell’ordine di navigazione o l’annuncio della conferma di invio. La prova da tastiera e con lettore di schermo resta indispensabile.
Viola