Un modulo di contatto può sembrare perfettamente funzionante e impedire comunque a una parte degli utenti di inviare una richiesta. Basta un campo privo di etichetta riconoscibile, un pulsante che non risponde alla tastiera oppure un messaggio di errore visualizzato soltanto attraverso un cambiamento di colore. Il problema emerge soprattutto quando la compilazione richiede tecnologie assistive, ma può coinvolgere anche persone con difficoltà visive temporanee, limitazioni motorie o dispositivi che rendono complicata l’interazione.
La realizzazione di siti web accessibili richiede particolare attenzione proprio ai moduli, perché rappresentano il punto in cui la consultazione delle informazioni diventa un’operazione concreta. Prenotare un appuntamento, richiedere un preventivo, acquistare un prodotto o trasmettere una domanda a un ufficio significa completare una sequenza di azioni. Se uno dei passaggi risulta inutilizzabile, l’intero servizio può diventare inaccessibile.
Le Web Content Accessibility Guidelines (WCAG), elaborate dal World Wide Web Consortium, individuano requisiti tecnici per rendere i contenuti digitali percepibili, utilizzabili, comprensibili e robusti. Nella versione 2.2, pubblicata come raccomandazione W3C nell’ottobre 2023, diversi criteri riguardano direttamente la compilazione dei moduli, la gestione degli errori e la navigazione mediante tastiera.
Etichette dei campi: perché il testo visibile non sempre è sufficiente
Uno degli errori più frequenti nella progettazione dei moduli consiste nell’utilizzare una parola all’interno del campo di compilazione come unica indicazione del dato richiesto.
La scritta “Indirizzo email”, per esempio, può comparire all’interno di una casella e scomparire quando l’utente comincia a digitare. Tecnicamente si tratta di un placeholder, un suggerimento che non dovrebbe sostituire l’etichetta del campo.
La differenza diventa rilevante quando vengono utilizzati lettori di schermo, software che interpretano gli elementi dell’interfaccia e li restituiscono attraverso una sintesi vocale o un display Braille.
Un campo privo di un nome accessibile correttamente associato può essere annunciato senza indicazioni sufficienti sulla sua funzione. L’utente riesce a raggiungerlo, ma non comprende necessariamente quale informazione debba inserire.
Le WCAG affrontano il problema attraverso diversi requisiti. Il criterio 3.3.2 richiede etichette o istruzioni quando il contenuto prevede l’inserimento di dati, mentre il criterio 1.3.1 riguarda la possibilità di determinare programmaticamente informazioni, struttura e relazioni.
Nel codice HTML, la soluzione ordinaria consiste nell’associare l’elemento label al rispettivo controllo. Questa relazione permette alle tecnologie assistive di identificare correttamente il campo e amplia, in molti casi, anche l’area selezionabile con il puntatore.
Un’etichetta graficamente visibile non garantisce da sola che il campo sia accessibile. Occorre verificare che l’associazione sia riconosciuta anche a livello tecnico.
Le istruzioni devono inoltre chiarire quali dati siano obbligatori e quali formati siano accettati. Se viene richiesta una data nel formato giorno, mese e anno, l’indicazione dovrebbe essere disponibile prima dell’inserimento, anziché comparire soltanto dopo un tentativo fallito.
Particolare attenzione meritano i gruppi di opzioni, come quelli relativi alle preferenze di contatto o alla scelta di un servizio. Le singole risposte possono essere etichettate correttamente, ma senza un’associazione alla domanda generale il significato della selezione rischia di andare perduto.
Navigazione da tastiera: quando un pulsante blocca la procedura
La tastiera rappresenta uno degli strumenti principali per verificare l’accessibilità operativa di un modulo.
Molte persone utilizzano il tasto Tab per spostarsi fra i controlli, Maiusc e Tab per tornare indietro, Invio o la barra spaziatrice per attivare determinati elementi. Questa modalità è indispensabile per alcuni utenti con disabilità motorie e viene impiegata anche insieme ai lettori di schermo.
Il criterio WCAG 2.1.1 stabilisce che le funzionalità debbano essere utilizzabili tramite un’interfaccia da tastiera, con le eccezioni previste per attività che dipendono necessariamente dal percorso del movimento.
Nei moduli online, le criticità riguardano spesso componenti realizzati con script personalizzati. Un calendario per la scelta della data, un menu a discesa o una finestra per caricare documenti possono funzionare con il mouse senza offrire un’interazione equivalente da tastiera.
Un caso particolarmente problematico si verifica quando il cursore entra in un componente e non riesce più a uscirne. Le WCAG disciplinano questa situazione con il criterio 2.1.2, dedicato all’assenza di blocchi della tastiera.
Anche l’ordine di navigazione conta. Se premendo Tab il passaggio avviene dal nome al pulsante di invio, saltando indirizzo email e messaggio, la sequenza può compromettere la comprensione e la compilazione.
Nei siti web accessibili, l’ordine del focus deve conservare una progressione coerente con il significato e il funzionamento della pagina.
Il focus è l’elemento che riceve in quel momento i comandi della tastiera. Deve essere riconoscibile visivamente, affinché chi naviga possa capire dove si trova.
Eliminare il contorno del focus attraverso le regole CSS, senza prevedere un indicatore alternativo adeguato, può rendere difficoltosa l’interazione anche quando tutti i pulsanti risultano tecnicamente raggiungibili.
Le WCAG 2.2 hanno rafforzato l’attenzione su questo aspetto introducendo, tra gli altri, il criterio 2.4.11, relativo al focus non oscurato al livello AA. L’obiettivo è evitare che l’elemento attivo venga completamente nascosto da altri contenuti, come intestazioni fisse o finestre sovrapposte.
Contrasto e indicazioni visive: i problemi che emergono durante la compilazione
Un modulo può rispettare le dimensioni previste dal progetto grafico e risultare comunque difficile da leggere.
Il contrasto insufficiente tra testo e sfondo interessa soprattutto le etichette secondarie, le indicazioni sui campi obbligatori e i messaggi di errore. Spesso questi elementi vengono rappresentati con tonalità grigie molto chiare, considerate esteticamente discrete ma poco distinguibili.
Il criterio WCAG 1.4.3, al livello AA, richiede generalmente un rapporto minimo di contrasto di 4,5:1 per il testo normale e di 3:1 per il testo grande, secondo le definizioni tecniche previste dalle linee guida. Sono contemplate eccezioni specifiche, tra cui quelle relative a determinati elementi inattivi.
Per i componenti dell’interfaccia e gli indicatori visivi necessari a identificarli o comprenderne lo stato interviene invece il criterio 1.4.11, che prevede, nei casi applicabili, un rapporto minimo di 3:1 rispetto ai colori adiacenti.
Questi valori non devono essere interpretati come una semplice verifica cromatica dell’intera pagina. Occorre distinguere testo, elementi grafici funzionali, bordi dei controlli e stati dell’interfaccia.
Una casella con un bordo poco visibile può essere difficile da individuare, anche se l’etichetta possiede un contrasto adeguato. Analogamente, un testo perfettamente leggibile non risolve il problema di un pulsante che diventa riconoscibile soltanto quando viene attraversato con il mouse.
Il colore non può nemmeno essere l’unico mezzo utilizzato per comunicare un’informazione.
Se un campo obbligatorio non compilato viene evidenziato esclusivamente con un bordo rosso, alcuni utenti potrebbero non riconoscere l’errore. È quindi opportuno accompagnare l’indicazione cromatica con un messaggio testuale e con gli attributi necessari a comunicarne lo stato alle tecnologie assistive.
Per progettare siti web accessibili, i controlli sul contrasto devono comprendere tutti gli stati dei componenti: condizioni iniziali, selezione, focus, errore e conferma dell’operazione.
Messaggi di errore: indicare cosa correggere senza costringere a ricominciare
La gestione degli errori è uno dei passaggi più delicati nella progettazione dei moduli.
Una situazione ricorrente riguarda i campi obbligatori lasciati vuoti. Dopo aver premuto il pulsante di invio, il sistema impedisce di proseguire ma mostra soltanto un avviso generico, come “Dati non validi”.
Una comunicazione simile non permette di individuare il problema.
Il criterio WCAG 3.3.1 richiede che, quando un errore di inserimento viene rilevato automaticamente, l’elemento interessato sia identificato e l’errore venga descritto attraverso un testo.
Il criterio 3.3.3, previsto al livello AA, aggiunge che devono essere fornite indicazioni per la correzione quando queste sono note, salvo che possano compromettere la sicurezza o la finalità del contenuto.
La differenza pratica è evidente. Un messaggio come “Errore nel modulo” non chiarisce cosa sia accaduto. L’indicazione “Il campo indirizzo email è obbligatorio” identifica invece il dato mancante. Se il problema riguarda un formato non valido, il sistema dovrebbe specificarlo e, quando possibile, suggerire come correggerlo.
La posizione del messaggio influisce sulla sua efficacia.
Un avviso collocato esclusivamente nella parte superiore di una pagina lunga può passare inosservato a chi si trova nella sezione finale del modulo. Una soluzione consiste nel presentare un riepilogo degli errori e associare ogni messaggio al campo corrispondente.
Quando gli errori vengono mostrati dinamicamente, senza ricaricare la pagina, devono essere comunicati anche alle tecnologie assistive. L’utilizzo appropriato di attributi e meccanismi come aria-describedby, aria-invalid e le regioni di stato può contribuire a questo risultato, purché l’implementazione sia coerente con il comportamento dell’interfaccia.
Non è sufficiente aggiungere attributi ARIA a un componente già problematico. Se il messaggio compare visivamente ma non viene annunciato, oppure se il focus si sposta in modo inatteso, l’interazione può rimanere difficoltosa.
C’è poi la questione dei dati già inseriti. La correzione di un singolo errore non dovrebbe obbligare l’utente a ricompilare l’intero modulo.
Conservare le informazioni valide riduce il lavoro necessario per completare la richiesta. Nei procedimenti articolati in più passaggi, il criterio WCAG 3.3.7 affronta anche il reinserimento ripetuto di informazioni già fornite, prevedendo specifiche eccezioni.
La verifica deve riguardare anche ciò che accade dopo l’invio. Un sistema che non comunica se la richiesta sia stata acquisita lascia l’utente nell’incertezza e può provocare trasmissioni ripetute.
Moduli complessi, documenti allegati e verifiche di sicurezza
Le difficoltà aumentano quando la compilazione comprende operazioni ulteriori, come l’allegazione di documenti, l’autenticazione o la conferma dell’identità.
Un campo per il caricamento di file deve consentire di individuare il documento richiesto, conoscere preventivamente gli eventuali limiti di formato e dimensione e comprendere se il trasferimento sia riuscito.
Se l’allegato viene rifiutato, il messaggio dovrebbe spiegare il motivo. Un generico “Caricamento fallito” non permette di distinguere un formato non accettato da un problema tecnico temporaneo.
Anche le verifiche contro gli accessi automatizzati richiedono attenzione. I sistemi che impongono di riconoscere immagini, decifrare caratteri distorti o risolvere esercizi possono rappresentare un ostacolo per determinate categorie di utenti.
Le WCAG 2.2, attraverso il criterio 3.3.8 sull’autenticazione accessibile, affrontano le prove basate su funzioni cognitive nei processi di accesso, prevedendo alternative e meccanismi di supporto nelle condizioni specificate dallo standard.
Non tutte le verifiche di sicurezza sono vietate. Devono però essere progettate considerando la possibilità di completare la procedura senza dipendere esclusivamente da capacità percettive o cognitive particolari.
Anche il tempo disponibile può compromettere l’utilizzo del servizio. Un modulo che scade senza un avviso adeguato oppure senza possibilità di estendere il tempo, nei casi in cui le WCAG lo richiedono, rischia di interrompere una procedura già avviata.
Per i siti web accessibili, la progettazione di queste funzionalità richiede un confronto tra esigenze di sicurezza, protezione dei dati e possibilità effettiva di completare le operazioni.
Quali obblighi si applicano ai siti italiani nel 2026
Il quadro normativo italiano distingue diversi ambiti di applicazione.
La legge 9 gennaio 2004, n. 4, conosciuta come Legge Stanca, costituisce uno dei principali riferimenti nazionali per l’accessibilità degli strumenti informatici. Le disposizioni interessano le pubbliche amministrazioni e gli altri soggetti individuati dalla normativa.
Alcuni obblighi sono stati estesi anche ai soggetti privati che offrono servizi al pubblico attraverso siti web o applicazioni mobili e presentano un fatturato medio, negli ultimi tre anni di attività, superiore a 500 milioni di euro.
A questo quadro si affianca il decreto legislativo 27 maggio 2022, n. 82, che recepisce la direttiva europea 2019/882, nota come European Accessibility Act.
Dal 28 giugno 2025 si applicano i requisiti di accessibilità previsti dal decreto per determinate categorie di prodotti e servizi, secondo le condizioni e le disposizioni transitorie stabilite dalla normativa.
Tra i servizi interessati rientrano il commercio elettronico, determinati servizi bancari rivolti ai consumatori, i servizi di comunicazione elettronica e specifici servizi digitali legati al trasporto passeggeri.
Non significa che qualunque sito aziendale sia automaticamente sottoposto agli stessi obblighi.
L’applicazione dipende dalla tipologia di servizio, dalle caratteristiche dell’operatore e dalle eventuali esclusioni. Per i servizi disciplinati dal decreto legislativo 82/2022 è prevista, tra l’altro, un’esenzione per le microimprese, individuate sulla base dei requisiti relativi al personale e ai parametri economici.
La normativa contempla inoltre specifiche disposizioni transitorie e condizioni riguardanti, tra gli altri aspetti, le modifiche sostanziali dei servizi e gli oneri sproporzionati.
Nel marzo 2026 l’Agenzia per l’Italia Digitale ha pubblicato le Linee guida sull’accessibilità dei servizi in attuazione dell’articolo 21 del decreto legislativo 82/2022, fornendo ulteriori indicazioni per l’applicazione del quadro normativo.
Le WCAG costituiscono un riferimento tecnico centrale, ma non bisogna confondere automaticamente l’ultima versione pubblicata dal W3C con la versione richiamata dalle norme armonizzate e dai requisiti applicabili a ogni specifico servizio. La verifica giuridica richiede di considerare anche gli standard europei pertinenti, tra cui la famiglia EN 301 549, e il loro effettivo rapporto con la legislazione di riferimento.
La distinzione conta soprattutto quando un’impresa commissiona lo sviluppo o l’adeguamento di un sito: dichiarare genericamente la conformità alle WCAG senza precisare versione, livello e perimetro delle verifiche può rendere difficile valutare il risultato.
Come verificare se una richiesta può essere completata realmente
Gli strumenti automatici consentono di individuare numerosi problemi, compresi alcuni errori nelle etichette dei campi, nei rapporti di contrasto e nella struttura del codice.
La loro capacità di analisi, però, non copre tutte le situazioni possibili.
Un software può rilevare che un campo possiede un’etichetta, ma non necessariamente stabilire se il testo utilizzato sia sufficientemente chiaro rispetto all’informazione richiesta. Allo stesso modo, la presenza di un pulsante raggiungibile tramite tastiera non garantisce che il suo comportamento sia comprensibile e coerente.
La verifica dei siti web accessibili richiede quindi prove funzionali sui percorsi effettivamente utilizzati dagli utenti.
Nel caso di un modulo per richiedere un appuntamento, il controllo dovrebbe partire dall’apertura della pagina e proseguire fino alla conferma dell’avvenuto invio. Durante il percorso occorre utilizzare soltanto la tastiera, verificare la posizione del focus, provocare volontariamente errori di compilazione e controllare che le relative comunicazioni siano disponibili anche attraverso un lettore di schermo.
La prova dovrebbe comprendere dispositivi mobili, ingrandimento del testo e differenti configurazioni di visualizzazione, senza presumere che il corretto funzionamento su un computer desktop garantisca lo stesso risultato altrove.
Particolare attenzione meritano i moduli sviluppati tramite componenti di terze parti. Un sistema di prenotazione incorporato, un servizio esterno per i pagamenti o un modulo fornito da una piattaforma possono introdurre barriere anche all’interno di un sito progettato con criteri di accessibilità.
La responsabilità tecnica degli interventi può essere ripartita tra più fornitori, ma la verifica dell’esperienza finale deve considerare l’intero percorso richiesto all’utente.
Per i siti web accessibili, la manutenzione successiva alla pubblicazione assume quindi un ruolo operativo. Gli aggiornamenti dei componenti, le modifiche ai campi e l’introduzione di nuove verifiche possono alterare funzionalità precedentemente utilizzabili.
Un controllo particolarmente significativo consiste nel ripetere periodicamente l’invio di una richiesta con dati corretti e con dati intenzionalmente errati, verificando che in entrambi i casi il sistema restituisca informazioni comprensibili e utilizzabili.
Quando viene modificato un passaggio del modulo, il collaudo dovrebbe comprendere anche la gestione del focus e degli errori, anziché limitarsi a verificare che i dati arrivino al destinatario.
È proprio durante queste prove che emergono difetti difficilmente individuabili attraverso la sola osservazione grafica: un campo compilabile ma privo di istruzioni, una conferma non annunciata dal lettore di schermo oppure un pulsante di invio che rimane irraggiungibile senza mouse. Sono anomalie circoscritte, ma sufficienti a impedire il completamento di un servizio digitale.
