1 adulto americano su 4 vive con una qualche forma di disabilità. Se il tuo modulo non è accessibile, tagli fuori un quarto del tuo pubblico potenziale prima ancora che arrivi al pulsante di invio.
Un modulo accessibile funziona per tutti. Significa utenti che usano solo la tastiera. Persone che ascoltano tramite screen reader. Utenti con scarsa vista. Persone con tremori che hanno bisogno di più tempo per compilare i campi. Nessun design speciale, nessuna complessità in più. Solo un modulo costruito in modo che tutte queste persone possano usarlo davvero.
Etichette chiare. Navigazione da tastiera. Messaggi di errore che uno screen reader può annunciare. Contrasto sufficiente perché chi ha poca vista possa leggere il testo. Non sono funzioni extra. Sono la base richiesta da WCAG 2.1 AA e dall'Americans with Disabilities Act a partire da aprile 2026.
Cosa rende diversi i moduli accessibili
Prendi un modulo di contatto qualsiasi e troverai sempre gli stessi errori. Un campo di testo con un segnaposto ma senza etichetta visibile. Una casella di controllo senza spiegazione di cosa fa. Un messaggio di errore in testo rosso che uno screen reader non può annunciare.
La maggior parte dei moduli è costruita per chi usa il mouse, e l'accessibilità viene aggiunta dopo, come ripensamento. Un modulo accessibile funziona al contrario. Parte dal presupposto che le persone lo useranno in modi diversi. Alcune con il mouse, altre solo con la tastiera. Alcune leggendolo, altre ascoltando uno screen reader.
Questo cambia il modo in cui costruisci il modulo. I segnaposto diventano inutili senza etichette. Gli asterischi rossi diventano inutili senza testo. Un layout visivo che funziona per chi usa il mouse può intrappolare chi usa la tastiera. Un modulo accessibile non è più difficile da costruire. Richiede solo di pensare a modi di interagire che vanno oltre il mouse.
Perché è importante
Scadenza legale. Il Titolo II dell'ADA richiede WCAG 2.1 AA entro il 24 aprile 2026. Non rispettarlo non è più un rischio. È una responsabilità attuale.
Impatto sul business. I visitatori con disabilità spendono soldi veri. Un modulo accessibile aumenta i tassi di completamento per tutti, perché etichette chiare aiutano tutti gli utenti, non solo le persone con disabilità. Utenti di fretta che scorrono da mobile alle 6 del mattino. Utenti esperti che navigano con la tastiera. Tutti.
Vantaggio SEO. I motori di ricerca preferiscono le pagine in cui gli elementi interattivi hanno etichette e si possono usare da tastiera. I moduli accessibili si posizionano meglio.
Di cosa hanno davvero bisogno i moduli accessibili
Etichette visibili su ogni campo
Ogni campo di inserimento ha bisogno di un'etichetta. Non di un segnaposto che sparisce. Non di un attributo title. Di una vera etichetta, ben presente nella pagina.
Uno screen reader legge prima l'etichetta, poi annuncia il tipo di campo. "Nome, campo di testo." L'utente sa cosa fare. Senza etichetta si sente "campo di testo" e nient'altro. L'utente non ha idea di cosa inserire.
Per chi vede, le etichette funzionano come su carta. Dicono cosa va in ogni spazio vuoto. Allargano anche l'area cliccabile. Collega l'etichetta al campo con l'attributo for e gli utenti possono cliccare sull'etichetta o sul campo per attivarlo. Su mobile questa area di clic più grande conta.
Funzionare solo con la tastiera
Molte persone non toccano mai un mouse. Disabilità motorie, scarsa vista, screen reader. Questi utenti navigano interamente con la tastiera. Se il tuo modulo richiede un mouse, non è accessibile.
Provalo. Scollega il mouse. Scorri il modulo usando solo il tasto Tab, i tasti freccia e Invio. Dovresti riuscire a raggiungere ogni campo, selezionare ogni opzione e premere invia senza muovere le mani.
Il contorno del focus deve essere visibile a ogni passaggio. Niente stati di focus invisibili. Gli utenti devono sapere dove si trovano nel modulo. E l'ordine del tab conta. I campi devono scorrere da sinistra a destra e dall'alto in basso, come si legge il modulo. Se il tuo layout salta di qua e di là o nasconde campi, l'ordine del tab si rompe e gli utenti da tastiera restano intrappolati.
Messaggi di errore che si annunciano davvero
Un testo rosso in cima al modulo non significa nulla per chi usa uno screen reader. Invia, sente silenzio e riprova. Poi si arrende.
Collega l'errore al campo specifico in cui si è verificato. Quando chi usa uno screen reader arriva a quel campo con il tab, l'errore viene annunciato. E fai in modo che il messaggio dica cosa correggere, non solo "Non valido." Invece di "Inserimento non valido", scrivi "L'email deve includere il simbolo @."
Usa attributi ARIA come aria-describedby per collegare il messaggio di errore al campo. Quando il focus arriva sul campo, lo screen reader annuncia l'errore in automatico. Senza indovinare.
Rendi il testo leggibile per chi ha poca vista
Etichette grigio chiaro su sfondo bianco sono invisibili per chi ha poca vista. WCAG 2.1 AA richiede un rapporto di contrasto di 4,5:1 per il testo normale. Testo scuro su sfondo chiaro, o testo chiaro su sfondo scuro. Il contrasto deve essere evidente.
Il testo più grande (18 punti o più) può usare un contrasto di 3:1. Tutto il resto richiede 4,5:1. Uno strumento per controllare il contrasto richiede 5 secondi. Fai passare ogni etichetta, pulsante e messaggio di errore da uno di questi prima del lancio.
Non usare mai solo il colore per indicare i campi obbligatori. Un asterisco rosso non significa nulla per chi non distingue i colori. Aggiungi la parola "obbligatorio" accanto al campo. Gli screen reader la annunciano. Chi vede la legge. Tutti capiscono il testo.
Indicazioni campo per campo per i moduli accessibili
Campi di testo e aree di testo
Nome, email, telefono: tutti hanno bisogno di un'etichetta direttamente sopra o accanto. Usa l'elemento HTML <label> con un attributo for che corrisponda all'id del campo.
Se il campo si aspetta un formato specifico, dillo. "Formato: 555-123-4567" aiuta tutti, soprattutto chi lavora meglio con istruzioni esplicite.
Le aree di testo devono sembrare capaci di accogliere risposte più lunghe. Una casella di una riga con l'etichetta "Messaggio" fa pensare a una risposta veloce. Una casella più alta dice "scrivimi di più". La dimensione conta.
Menu a tendina e pulsanti di scelta
Ogni menu a tendina ha bisogno di un'etichetta. "Seleziona un'opzione" e "Sì/No" senza contesto sono inutili. Chi usa uno screen reader non ha idea di quale domanda gli stai facendo. Rendi chiaro nell'etichetta del menu quale scelta è.
I pulsanti di scelta (radio) devono stare in un fieldset con una legenda. La legenda pone la domanda. Le opzioni rispondono. "Quale descrive meglio il tuo caso d'uso?" con opzioni come "E-commerce", "Media", "SaaS". Uno screen reader annuncia la legenda, poi ogni opzione. L'utente capisce che sta scegliendo da un gruppo e a cosa serve il gruppo.
Caselle di controllo
L'etichetta di una casella di controllo deve leggersi in modo naturale. "Accetto i termini di servizio" come etichetta, con la casella accanto. Non una casella nuda senza testo, che costringe gli utenti a indovinare cosa fa.
Se ci sono informazioni di supporto, come un link ai termini completi, mettile subito accanto alla casella. Non nasconderle. Gli utenti devono sapere cosa stanno accettando prima di spuntare la casella.
I gruppi di caselle funzionano come i gruppi di pulsanti di scelta. Una legenda dà il nome al gruppo e ogni opzione ha la sua etichetta.
Pulsanti
Il testo del pulsante deve dire cosa succede. "Invia." "Manda." "OK" va bene per le conferme. "Vai" no. Niente etichette generiche.
Se hai più pulsanti, rendili distinti. "Annulla" e "Invia" sono chiari. Due pulsanti che dicono entrambi "Avanti" no: chi usa uno screen reader sente "pulsante avanti, pulsante avanti" e non sa quale sia quale.
Dove stanno i moduli nel tuo sito
Moduli di contatto nei popup. Iscrizioni alla newsletter nei footer. Moduli di donazione nelle pagine della missione. Moduli di sondaggio nel checkout. Qualsiasi modulo, ovunque, deve essere accessibile.
I moduli nei popup creano una trappola del focus se non li gestisci. Quando si apre una finestra modale, il focus ci salta dentro. Quando si chiude, il focus torna al pulsante che l'ha aperta. Senza questo, gli utenti da tastiera restano bloccati a scorrere la pagina sullo sfondo.
Per le pagine lunghe con moduli in basso, aggiungi un link per saltare i contenuti. Gli utenti da tastiera non dovrebbero dover scorrere 50 voci di navigazione per arrivare al tuo modulo.
Errori comuni
Affidarsi ai segnaposto invece che alle etichette
Un segnaposto che dice "Inserisci la tua email" sparisce nel momento in cui qualcuno inizia a scrivere. Ora l'utente non ha idea di a cosa servisse il campo. Gli screen reader non lo vedono affatto.
Usa una vera etichetta. Se vuoi un segnaposto per suggerire il formato, va bene. Ma non usarlo mai al posto dell'etichetta.
Usare solo il colore per i campi obbligatori
Un asterisco rosso è invisibile per chi non distingue i colori. Un'icona è invisibile per gli screen reader. Usa la parola "obbligatorio" nel testo. Tutti capiscono il testo.
Saltare i test manuali
La struttura HTML giusta sulla carta non significa che il tuo modulo funzioni nella realtà. Le etichette potrebbero essere troppo lontane dai campi. I contorni del focus potrebbero essere invisibili. I messaggi di errore potrebbero essere annunciati ma senza spostare il focus sul campo.
Prova con la tastiera. Prova con uno screen reader. Ce ne sono di gratuiti, di molto diffusi nel lavoro e uno già integrato nei telefoni se provi su iOS. I controlli automatici trovano i problemi evidenti. I test reali trovano il resto.
Aggiungere limiti di tempo
Un utente con un tremore scrive lentamente. Chi usa uno screen reader ha bisogno di tempo per ascoltare tutte le etichette e le istruzioni. Un limite di 5 minuti intrappola chi ne ha bisogno di 10.
Togli i limiti di tempo se puoi. Se devi averli, lascia che gli utenti estendano il tempo due volte prima della fine della sessione.
Come WEMASY crea moduli accessibili
I moduli WEMASY sono accessibili fin dall'inizio, non come ripensamento. Ogni modello include etichette corrette. Il focus è gestito in automatico. Gli errori vengono annunciati agli screen reader. Il contrasto dei colori rispetta WCAG 2.1 AA di default.
Personalizza senza rompere l'accessibilità. Aggiungi campi, cambia le etichette, riorganizza il layout. La struttura di base resta accessibile. La validazione integrata annuncia gli errori agli screen reader.
Scopri di più nella nostra guida completa ai moduli, oppure guarda cosa è incluso in ogni piano WEMASY.