Quasi la metà di tutte le homepage dei siti web presenta etichette mancanti per i campi dei moduli, uno dei problemi di accessibilità più comuni e più facili da correggere sul web. Questa guida accompagna proprietari di siti, sviluppatori e responsabili della conformità attraverso le tecniche esatte necessarie per far funzionare i moduli per tutti: etichettatura corretta, messaggi di errore significativi e schemi di convalida inclusivi.

Secondo WebAIM, il 48,6% delle homepage dei siti web presenta etichette mancanti per i campi dei moduli, rendendo i campi senza etichetta uno dei singoli errori di accessibilità più comuni sul web. Pensa a cosa significa in pratica: una persona che usa un lettore di schermo arriva sul tuo modulo di contatto, preme Tab per spostarsi tra i campi e non sente altro che “edit text” ripetuto all’infinito. I lettori di schermo annunciano le etichette dei campi dei moduli — senza di esse, le persone sentono “edit text” senza contesto e non sanno quali informazioni inserire. I moduli sono spesso la parte più critica per il business di un sito web — flussi di checkout, schermate di registrazione, pagine di contatto, richieste di supporto — e tuttavia restano tra le esperienze più costantemente difettose per chi usa tecnologie assistive.

Perché l’accessibilità dei moduli conta più di quanto pensi

Considerando che 1 adulto su 4 negli Stati Uniti vive con una disabilità, una validazione accessibile dei moduli non è opzionale; è essenziale. Questa popolazione include persone cieche o con ipovisione, persone con disabilità motorie che si affidano alla navigazione da tastiera, persone con disabilità cognitive che hanno bisogno di istruzioni chiare e persone che usano software di controllo vocale per compilare i moduli. Ogni campo senza etichetta, ogni messaggio di errore vago e ogni schema di validazione che si affida esclusivamente al colore è una porta che si chiude silenziosamente davanti a una quota significativa del tuo pubblico.

La maggior parte delle persone con disabilità incontra errori quando invia informazioni e non riceve istruzioni chiare su come correggerli — rimanendo con due opzioni: abbandonare il tentativo e cercare un modulo più accessibile, oppure chiedere l’aiuto di qualcun altro, nessuna delle quali rappresenta un’esperienza ideale. Da una prospettiva di business, moduli accessibili migliorano l’esperienza utente, riducono i tassi di abbandono e soddisfano i requisiti legali. Da una prospettiva di conformità, WCAG 1.3.1 (Info and Relationships) e 4.1.2 (Name, Role, Value) sono requisiti di Livello A esistenti sin dal lancio di WCAG 2.0 nel 2008. Non si tratta di casi limite o tecniche avanzate — sono le aspettative fondamentali dello standard.

Secondo il rapporto WebAIM Million, le etichette mancanti nei moduli si collocano costantemente tra i principali errori di accessibilità sul web, e la ricerca sui fallimenti di implementazione spiega il perché: le organizzazioni si concentrano su soluzioni complesse ignorando schemi di base che permetterebbero alle persone con disabilità di usare effettivamente i loro servizi. La buona notizia è che correggere la maggior parte di questi problemi non richiede nulla di esotico — solo HTML deliberato e informato.

I criteri di successo WCAG che regolano i moduli

Prima di entrare nell’implementazione, è utile sapere quali specifici criteri di successo WCAG si applicano ai moduli. Le Web Content Accessibility Guidelines (WCAG) delineano quattro principi chiave — Perceivable (Percepibile), Operable (Utilizzabile), Understandable (Comprensibile) e Robust (Robusto) (POUR) — che fungono da spina dorsale per sistemi di validazione inclusivi. All’interno di questo framework, diversi criteri di successo si riferiscono direttamente alla progettazione dei moduli.

I criteri più rilevanti includono: 1.3.1 Info and Relationships (Livello A), che richiede che informazioni, struttura e relazioni trasmesse tramite la presentazione possano essere determinate in modo programmato; 2.4.6 Headings and Labels (Livello AA), che stabilisce che intestazioni ed etichette descrivano argomento o scopo; 3.3.2 Labels or Instructions (Livello A), che richiede che siano fornite etichette o istruzioni quando il contenuto richiede l’input dell’utente; e 4.1.2 Name, Role, Value (Livello A), che richiede che per tutti i componenti dell’interfaccia utente, nome e ruolo possano essere determinati in modo programmato.

Aderendo alle linee guida WCAG 3.3.1–3.3.4, che coprono identificazione degli errori, istruzioni, suggerimenti e prevenzione, crei moduli più facili e intuitivi per tutte le persone. Non sono ostacoli arbitrari — ogni criterio riflette un’esigenza reale dell’utente. Comprendere il “perché” dietro ogni regola rende molto più semplice implementarla correttamente e prendere decisioni sensate nei casi limite.

Impostare correttamente le etichette: le fondamenta dei moduli accessibili

Un’etichetta non è solo un suggerimento visivo. È il collegamento programmato tra una descrizione testuale e un controllo di modulo, ed è il meccanismo principale con cui le tecnologie assistive identificano a cosa serve un campo. Il modo più robusto per creare questo collegamento è con l’elemento HTML <label> e il suo attributo for, che punta all’id dell’input corrispondente.

<!-- Sbagliato: il solo placeholder non è un’etichetta accessibile -->
<input type='email' placeholder='Email address'>

<!-- Corretto: etichetta esplicita associata tramite for/id -->
<label for='email'>Email address</label>
<input type='email' id='email' name='email'>

Le etichette dovrebbero essere sempre visibili — non solo placeholder. I placeholder scompaiono quando le persone digitano, lasciando il campo senza contesto. Questa è una distinzione estremamente importante. Il testo del placeholder non è mai stato progettato per fungere da etichetta; scompare nel momento in cui una persona inizia a digitare, spesso ha un contrasto di colore insufficiente e molti lettori di schermo non lo espongono in modo affidabile come nome accessibile del campo. Affidarsi solo ai placeholder danneggia tutte le persone — non solo chi usa tecnologie assistive.

Quando hai gruppi di campi correlati — come un insieme di pulsanti di opzione (radio button) o un blocco di caselle di controllo (checkbox) — lo schema corretto è <fieldset> e <legend>. Raggruppa le opzioni correlate come checkbox e radio button con fieldset e legend per rendere più facili da comprendere i moduli complessi.

<fieldset>
  <legend>Preferred contact method</legend>

  <input type='radio' id='contact-email' name='contact' value='email'>
  <label for='contact-email'>Email</label>

  <input type='radio' id='contact-phone' name='contact' value='phone'>
  <label for='contact-phone'>Phone</label>
</fieldset>

In situazioni in cui un’etichetta visibile sarebbe visivamente ridondante — per esempio, un singolo campo di ricerca accanto a un pulsante Search chiaramente etichettato — puoi usare aria-label o aria-labelledby per fornire un nome accessibile senza mostrare testo visibile. Tuttavia, usali con parsimonia. Le persone che usano lettori di schermo possono identificare e comprendere i controlli dei moduli più facilmente perché sono associati a etichette, fieldset e altri elementi strutturali — e le etichette visibili avvantaggiano tutti, incluse le persone vedenti con disabilità cognitive, chi è ingrandito al 400% e chiunque abbia momentaneamente perso il filo in un modulo lungo.

Inoltre, i campi obbligatori devono essere indicati visivamente e in modo programmato, usando l’attributo required o aria-required. Un semplice asterisco rosso non è sufficiente — includi una breve nota come “I campi contrassegnati con * sono obbligatori” in cima al modulo e assicurati che l’attributo required sia presente nel markup, così le tecnologie assistive possono annunciare il campo come obbligatorio quando una persona vi porta il focus.

Scrivere messaggi di errore che aiutano davvero

I messaggi di errore sono il punto in cui la maggior parte dei moduli fallisce in un secondo modo, aggravando il problema. Dopo che una persona invia un modulo che genera errori di validazione, ha bisogno di sapere tre cose: che si è verificato un errore, quale campo lo ha causato e cosa deve fare per correggerlo. La maggior parte degli errori nei moduli risponde solo alla prima di queste domande — e anche in quel caso, male.

Messaggi di errore vaghi come “Input non valido” o “Errore” non dicono alle persone cosa è andato storto o come correggerlo. Ogni messaggio di errore dovrebbe identificare il problema specifico e suggerire un rimedio concreto.

Per garantire la compatibilità con i lettori di schermo, i messaggi di errore dovrebbero essere integrati nel DOM usando attributi ARIA come aria-invalid="true" e aria-describedby, che collegano i messaggi di errore direttamente ai rispettivi campi del modulo. Ecco come appare uno stato di errore marcato correttamente:

<label for='email'>Email address</label>
<input
  type='email'
  id='email'
  name='email'
  aria-invalid='true'
  aria-describedby='email-error'
>
<span id='email-error' role='alert'>
  Please enter a valid email address, for example: [email protected]
</span>

L’attributo aria-invalid="true" indica al lettore di schermo che il campo contiene attualmente un valore non valido. L’attributo aria-describedby punta all’elemento che contiene il messaggio di errore, che il lettore di schermo leggerà quando la persona porterà il focus su quell’input. Il role="alert" sullo span dell’errore fa sì che venga annunciato immediatamente quando viene inserito nel DOM, senza che la persona debba navigare fino ad esso.

In un design minimalista, è allettante usare solo un colore rosso per indicare che un campo non è valido — ma usare solo il colore non è sufficiente, come stabilito da WCAG 1.4.1 Use of Color, perché le persone percepiscono i colori in modi diversi e quel rosso non verrà notato da tutti. La soluzione è integrare lo stato di errore colorato con un elemento visivo aggiuntivo — potrebbe essere un’icona, ma anche questo potrebbe non bastare per capire perché il campo non è valido, quindi la soluzione più inclusiva è mostrare esplicitamente un messaggio testuale.

Messaggi di errore specifici sono particolarmente utili per persone con difficoltà cognitive, ridotta attenzione o che usano lettori di schermo — perché un feedback scritto male può portare a frustrazione e persino spingere le persone ad abbandonare del tutto il modulo. Scrivi i messaggi di errore dalla prospettiva dell’utente: cosa doveva inserire e come può correggerlo subito?

Tempistica della validazione e gestione del focus

Quando validi è importante quanto come validi. Se attivi gli errori troppo presto — per esempio mentre la persona sta ancora digitando — rischi di interrompere il suo flusso con lamentele premature. Se attivi gli errori solo all’invio, potresti costringerla a scorrere un modulo lungo alla ricerca dei campi che richiedono attenzione. La risposta giusta è un approccio stratificato.

Combina feedback in tempo reale per i campi critici, controlli on-blur per gli input con formato specifico e validazione on-submit per una revisione completa degli errori. In pratica, questo significa: valida formati complessi come password o indirizzi email quando la persona lascia il campo (on blur); evita di interrompere con una validazione in linea che si attiva a ogni pressione di tasto; e al momento dell’invio del modulo, esegui un controllo completo e comunica chiaramente tutti gli errori in una volta.

Dopo l’invio, indirizza automaticamente il focus sul primo errore per guidare le persone in modo efficiente. Se ci sono più errori, lo schema più accessibile è spostare il focus su un riepilogo in cima al modulo che elenca tutti gli errori come link che portano ai campi pertinenti. In questo modo la persona sente il riepilogo degli errori non appena invia, può capire l’ampiezza di ciò che deve correggere e può navigare direttamente a ciascun problema.

<!-- Riepilogo degli errori posizionato in cima al modulo, messo a fuoco via script -->
<div id='error-summary' role='alert' tabindex='-1'>
  <h2>2 errors found. Please correct the following:</h2>
  <ul>
    <li><a href='#email'>Email address: Please enter a valid email</a></li>
    <li><a href='#phone'>Phone number: Please use the format (555) 555-5555</a></li>
  </ul>
</div>

Assicurati che le persone possano navigare nei moduli senza mouse, con un ordine di tabulazione logico e indicatori di focus visibili. L’anello di focus predefinito del browser è una base legale e funzionale — ma molti team di design lo sopprimono con outline: none nel CSS senza fornire un sostituto. Questo rende il modulo di fatto inutilizzabile per chi usa solo la tastiera. Un indicatore di focus chiaro e ad alto contrasto è richiesto da WCAG 2.4.7 (Livello AA) e dal più rigoroso 2.4.11 in WCAG 2.2. Se le linee guida del tuo brand sono in conflitto con l’anello di focus predefinito, sostituiscilo — non rimuoverlo.

Fornire istruzioni e suggerimenti prima che si verifichino errori

Il miglior errore di un modulo è quello che non deve mai comparire. Istruzioni e suggerimenti ben posizionati prevengono gli errori fin dall’inizio, il che è meglio per tutte le persone. I campi obbligatori o quelli che richiedono un formato, un valore o una lunghezza specifici dovrebbero fornire queste informazioni all’interno dell’etichetta dell’elemento o delle sue istruzioni associate in modo programmato.

L’etichetta del campo è la prima istruzione visiva su cosa compilare, seguita da una descrizione quando necessario. Allo stesso modo in cui le persone vedenti possono vedere una descrizione, chi usa lettori di schermo deve esserne consapevole — e puoi collegare la descrizione all’input usando l’attributo aria-describedby, che accetta un id che punta all’elemento descrittivo, facendo sì che il lettore di schermo legga automaticamente la descrizione quando la persona porta il focus sul campo.

<label for='phone'>Phone number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-describedby='phone-hint'
>
<span id='phone-hint'>Format: (555) 555-5555</span>

Quando possibile, fornisci esempi per chiarire le aspettative — per esempio, se un campo data richiede il formato MM/DD/YYYY, includi un esempio come “Enter date as 12/25/2024”. Per i campi password, indica i requisiti in anticipo invece di rivelarli uno alla volta man mano che la persona viola ogni regola. Se possibile, i moduli non dovrebbero essere soggetti a un limite di tempo, così che le persone possano completarli al proprio ritmo — e se è necessario un limite di tempo, la persona dovrebbe avere la possibilità di disattivarlo o estenderlo.

L’attributo autocomplete è un altro meccanismo di accessibilità spesso trascurato. Impostare valori come autocomplete="email", autocomplete="given-name" o autocomplete="street-address" permette a browser e gestori di password di compilare automaticamente i campi in modo corretto, riducendo drasticamente il carico per persone con disabilità motorie, disabilità cognitive o chiunque trovi difficile digitare in modo ripetitivo. WCAG 1.3.5 (Identify Input Purpose, Livello AA) lo richiede per i campi che raccolgono informazioni personali.

Testare i tuoi moduli per l’accessibilità

Conoscere le regole è una cosa; sapere se i tuoi moduli le rispettano davvero è un’altra. Una strategia di test combinata è l’approccio più affidabile. Sebbene strumenti come Lighthouse e WAVE possano aiutare a rilevare automaticamente i problemi, i test manuali usando solo la tastiera e i lettori di schermo sono essenziali per individuare problemi di usabilità nel mondo reale.

Per i test da tastiera, scollega semplicemente il mouse e prova a completare il modulo. Dovresti poter raggiungere ogni campo, attivare ogni pulsante e ricevere ogni messaggio di errore usando solo Tab, Shift+Tab, tasti freccia ed Enter/Space. Se rimani bloccato, è un fallimento. Per i test con lettore di schermo, usa NVDA con Firefox su Windows o VoiceOver con Safari su macOS. I lettori di schermo si comportano in modo leggermente diverso tra loro — scorciatoie diverse, annunci semantici diversi e supporto di funzionalità diverso; per esempio, NVDA funziona meglio con Firefox, mentre VoiceOver funziona meglio con Safari. Testare almeno due combinazioni permetterà di intercettare la più ampia gamma di problemi.

Strumenti come WAVE e Axe sono ottimi per analizzare i moduli alla ricerca di etichette mancanti, attributi ARIA errati e scarso contrasto di colore. Questi strumenti automatici possono essere integrati direttamente nella tua pipeline CI/CD per intercettare regressioni prima che raggiungano la produzione. Poiché le linee guida di accessibilità sono complesse, tuttavia, gli strumenti automatici possono rilevare solo circa il 30% dei problemi WCAG — motivo per cui il livello automatico deve essere integrato con una revisione manuale e, idealmente, con test condotti da persone che si affidano alle tecnologie assistive.

Quando esamini manualmente il tuo markup, poni le seguenti domande per ciascun campo del modulo: ha un’etichetta visibile? Quell’etichetta è associata in modo programmato tramite for/id o ARIA? Eventuali testi di aiuto sono collegati con aria-describedby? Ogni stato di errore imposta aria-invalid="true" e fa riferimento al messaggio di errore tramite aria-describedby? L’attributo required è presente sui campi obbligatori? Puoi raggiungere e usare ogni elemento interattivo solo con la tastiera?

Concetti chiave

Ogni input ha bisogno di un’etichetta programmata. Usa <label for='...'> per tutti i campi del modulo — non affidarti mai solo al testo del placeholder. Ogni campo del modulo ha bisogno di un’etichetta programmata, senza eccezioni — il testo del placeholder non è un’etichetta.
I messaggi di errore devono nominare il problema e suggerire una correzione. I messaggi di errore devono identificare il problema e suggerire come risolverlo, e dovrebbero essere associati ai rispettivi campi usando aria-describedby.
Non affidarti mai solo al colore. Non affidarti solo al colore per indicare uno stato — usa testo, icone e altri indicatori non basati sul colore insieme ai segnali cromatici.
Gestisci il focus dopo l’invio. L’errore dovrebbe essere chiaramente identificato, dovrebbe essere fornito un accesso rapido all’elemento problematico e la persona dovrebbe poter correggere facilmente l’errore e inviare di nuovo il modulo. Spostare il focus su un riepilogo degli errori dopo un invio non riuscito è lo standard di riferimento.
Testa con strumenti reali, non solo con supposizioni. Mantenere i moduli accessibili non è un’attività da fare una volta sola — richiede test regolari e aggiornamenti per garantire che restino conformi e facili da usare. Combina analisi automatizzate con navigazione solo da tastiera e test con lettori di schermo a ogni aggiornamento significativo del modulo.

Come rendere accessibili i tuoi moduli: etichette, errori e convalida