WCAG 3.3.2: Etichette o istruzioni

Cosa Significa Questa Regola

Il Criterio di Successo WCAG 3.3.2 — Etichette o Istruzioni (Livello A) afferma: «Vengono fornite etichette o istruzioni quando il contenuto richiede l’immissione di dati da parte dell’utente.» In termini pratici, ogni campo di un modulo, controllo di input, area di testo e elemento select che chiede all’utente di inserire o selezionare informazioni deve avere un’etichetta visibile e significativa o un insieme di istruzioni che renda chiaro lo scopo del campo prima che l’utente interagisca con esso.

Il criterio è deliberatamente ampio. Copre qualsiasi meccanismo attraverso il quale un utente fornisce dati: elementi <input> di tutti i tipi (text, email, password, number, date, checkbox, radio, file upload), elementi <textarea> per testo su più righe e menu a discesa <select>. Si applica anche a controlli interattivi personalizzati costruiti con ruoli ARIA come role='combobox' o role='listbox'.

Un’etichetta può essere fornita in diversi modi che soddisfano questo criterio. Il metodo più robusto è un elemento <label> associato in modo programmatico, visivamente presente e collegato al controllo tramite una coppia corrispondente for/id. In alternativa, un testo di etichetta visibile può essere associato usando aria-labelledby che punta a un elemento esistente, oppure istruzioni supplementari possono essere collegate con aria-describedby. Il requisito chiave è che l’etichetta o l’istruzione sia fornita — deve esistere in una forma percepibile dall’utente. Il solo testo del placeholder non soddisfa questo criterio perché scompare non appena l’utente inizia a digitare e non è trasmesso in modo affidabile da tutte le tecnologie assistive come etichetta persistente.

Un superamento richiede che ogni input abbia un’etichetta visibile (o almeno determinabile in modo programmatico), presente prima che l’utente si impegni a compilare il campo, e sufficientemente descrittiva da comunicare quali dati sono attesi. Un fallimento si verifica quando un campo non ha alcuna etichetta, quando l’unica etichetta è un attributo placeholder, quando l’etichetta è visivamente presente ma non associata in modo programmatico, o quando le istruzioni sul formato richiesto (ad es. «Inserisci la data come DD/MM/YYYY») sono completamente assenti.

WCAG prevede una stretta eccezione: quando un modulo contiene un singolo campo ovvio — come una barra di ricerca a livello di sito con un pulsante di invio chiaramente etichettato direttamente adiacente — il contesto stesso può fornire istruzioni sufficienti. Tuttavia, questa eccezione è limitata e non dovrebbe essere usata come giustificazione generale per omettere le etichette nei moduli con più campi.

Perché È Importante

Le etichette dei moduli sono la singola funzionalità di accessibilità più incisiva per un’ampia gamma di utenti. La loro assenza crea barriere che possono rendere impossibile per molte persone completare transazioni, registrarsi a servizi o contattare un’organizzazione.

Per gli utenti ciechi e ipovedenti che si affidano ai lettori di schermo, un campo senza etichetta viene annunciato semplicemente come «edit text» o «blank» senza contesto. L’utente non ha modo di sapere se deve inserire il proprio nome, l’indirizzo email o il numero di carta di credito. Secondo l’Organizzazione Mondiale della Sanità, circa 2,2 miliardi di persone nel mondo hanno una qualche forma di disabilità visiva, e milioni di loro usano i lettori di schermo come principale mezzo di interazione con il web.

Per gli utenti con disabilità cognitive e dell’apprendimento — inclusa dislessia, ADHD e condizioni legate alla memoria — il testo del placeholder è particolarmente dannoso. Poiché i placeholder scompaiono al focus o all’immissione, un utente che si ferma a metà modulo non ha più un riferimento su ciò che era richiesto in un campo che ha già iniziato a compilare. Questo li costringe a cancellare il campo per rileggere l’istruzione, introducendo confusione e frustrazione. Etichette persistenti e visibili eliminano completamente questo carico cognitivo.

Per gli utenti con disabilità motorie che navigano tramite tastiera, dispositivi a interruttore o controllo vocale, le etichette svolgono una funzione aggiuntiva: forniscono le parole pronunciate usate per attivare un campo tramite software di controllo vocale come Dragon NaturallySpeaking. Se il testo dell’etichetta visibile non corrisponde al nome accessibile programmatico, il comando vocale fallisce silenziosamente.

Consideriamo uno scenario concreto reale: un utente ipovedente sta facendo domanda per un sussidio governativo sul portale di un’istituzione pubblica turca. Il modulo usa il testo del placeholder invece delle etichette. Quando l’utente effettua lo zoom al 200% per leggere lo schermo, i placeholder scompaiono prima che possano essere letti. L’utente compila i campi a tentativi e invia un modulo con errori, ricevendo solo un messaggio di errore generico senza indicazione di quali campi siano errati. Questo scenario si traduce in esclusione da un servizio pubblico critico — ed è completamente prevenibile.

Oltre all’accessibilità, i moduli etichettati migliorano la SEO perché i crawler dei motori di ricerca possono comprendere meglio lo scopo del modulo, e migliorano la usabilità per tutti gli utenti, inclusi quelli su dispositivi mobili, dove i piccoli target tattili traggono beneficio da aree di etichetta cliccabili che ampliano la zona di attivazione dell’input associato.

Regole Axe-core Correlate

• label — Questa regola verifica che ogni elemento <input> (tranne quelli con type='hidden', type='image', type='button', type='submit' e type='reset'), ogni <textarea> e ogni <select> abbia un nome accessibile. La regola segnala gli elementi privi di un <label> associato, di un attributo aria-label, di un riferimento aria-labelledby o di un attributo title. Questo è il principale segnale automatizzato per le violazioni del 3.3.2 sui controlli di modulo standard.
• select-name — Questa regola prende di mira specificamente gli elementi a discesa <select> e verifica che abbiano un nome accessibile non vuoto. Gli sviluppatori a volte presumono che le opzioni di un menu a discesa rendano autoevidente il suo scopo, ma senza un’etichetta gli utenti di lettori di schermo sentono solo il valore dell’opzione attualmente selezionata — che può essere un valore predefinito generico come «Select one» — senza alcuna indicazione della categoria da cui stanno scegliendo. Axe segnala gli elementi <select> privi di uno qualsiasi dei meccanismi standard di etichettatura.
• textarea-label — Questa regola verifica che gli elementi <textarea> abbiano un nome accessibile. Le aree di testo su più righe sono spesso usate per commenti, messaggi o input dettagliati, ma vengono spesso lasciate senza etichetta per l’errata convinzione che il contesto circostante sia sufficiente. Axe segnala qualsiasi <textarea> che non possa essere associata in modo programmatico a un’etichetta tramite <label for>, aria-label, aria-labelledby o title.

È importante comprendere i limiti dei test automatizzati per questo criterio. Axe-core può rilevare l’assenza di un’etichetta programmatica, ma non può determinare se un’etichetta presente sia effettivamente significativa o accurata. Un campo etichettato «Field 1» o un’etichetta che contiene solo «*» supererà i controlli automatizzati pur fallendo completamente per gli utenti. È sempre necessaria una revisione manuale per confermare che le etichette descrivano chiaramente l’input atteso, che le istruzioni di formato siano presenti dove necessario (ad es. formati di data, requisiti per le password) e che i campi obbligatori siano identificati — idealmente sia visivamente sia in modo programmatico.

Come Eseguire i Test

1. Scansione automatizzata con axe DevTools o Lighthouse: Apri la pagina che contiene il modulo in Chrome o Firefox. Esegui l’estensione del browser axe DevTools e filtra i risultati per le regole label, select-name e textarea-label. Prendi nota di ogni elemento segnalato. Esegui Google Lighthouse (audit Accessibilità) come controllo secondario. Esporta o acquisisci screenshot di tutte le violazioni. Ricorda che un report automatizzato pulito non garantisce la conformità — prosegui con i passaggi manuali.
2. Ispezione visiva: Senza usare alcuna tecnologia assistiva, esamina ogni campo del modulo sulla pagina. Conferma che ogni campo abbia un’etichetta visibile e statica — non solo un placeholder — posizionata chiaramente vicino al campo (tipicamente sopra o a sinistra). Conferma che i requisiti di formato (ad es. «La password deve contenere almeno 8 caratteri») siano mostrati prima o al momento dell’immissione, non solo dopo un invio non riuscito. Conferma che i campi obbligatori siano identificati con più del solo colore.
3. Test di navigazione da tastiera: Usa il tasto Tab per scorrere ogni campo del modulo. Assicurati che, quando ogni campo riceve il focus, il suo scopo sia immediatamente chiaro dall’etichetta visibile. Nessun campo dovrebbe essere raggiungibile da tastiera senza che un’etichetta adiacente e persistente sia visibile in quel momento.
4. Test con lettore di schermo usando NVDA e Firefox: Apri il modulo con NVDA in esecuzione. Premi Tab per spostarti tra ogni controllo interattivo. NVDA dovrebbe annunciare l’etichetta, il ruolo (ad es. «edit», «combo box») e qualsiasi stato (ad es. «required»). Se NVDA annuncia solo il ruolo e lo stato senza etichetta, il campo fallisce. Usa la modalità modulo di NVDA (attivata automaticamente sugli elementi interattivi) per simulare una navigazione realistica dell’utente.
5. Test con lettore di schermo usando VoiceOver e Safari (macOS/iOS): Abilita VoiceOver (Command + F5 su Mac). Usa Tab o i gesti di scorrimento per navigare verso ogni campo del modulo. VoiceOver dovrebbe annunciare l’etichetta prima del ruolo. Su iOS, tocca ogni campo e conferma che l’etichetta venga letta ad alta voce prima che appaia la tastiera. I campi con solo placeholder verranno in genere letti come placeholder al primo focus ma diventeranno silenziosi una volta inserito il testo.
6. Test con lettore di schermo usando JAWS e Chrome: Apri JAWS e naviga nel modulo usando Tab. Usa la Forms Mode di JAWS. Conferma che il nome annunciato di ogni campo corrisponda esattamente alla sua etichetta visibile. Usa Insert + F1 (aiuto sul campo) di JAWS per verificare eventuali descrizioni aggiuntive tramite aria-describedby.
7. Test di controllo vocale con Dragon NaturallySpeaking: Attiva Dragon e prova a interagire con ogni campo pronunciandone l’etichetta visibile. Se l’etichetta pronunciata non corrisponde al nome accessibile programmatico, il campo non risponderà al comando vocale, indicando una mancata corrispondenza che viola sia il 3.3.2 sia criteri correlati.

Come Correggere

Etichetta mancante su un input di testo — Non corretto

<!-- No label provided; placeholder is the only hint -->
<input type='text' name='email' placeholder='Email address' />

Etichetta mancante su un input di testo — Corretto

<!-- Visible <label> associated via matching for/id attributes.
     Placeholder may still be used as supplementary hint,
     but the label is the primary, persistent identifier. -->
<label for='email'>Email address</label>
<input type='text' id='email' name='email' placeholder='[email protected]' />

Menu a discesa select senza etichetta — Non corretto

<!-- No label; screen readers will only announce the selected option value -->
<select name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

Menu a discesa select senza etichetta — Corretto

<!-- Programmatically associated label makes the field's purpose clear
     before the user opens the dropdown. -->
<label for='city'>City</label>
<select id='city' name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

Textarea senza etichetta — Non corretto

<!-- The textarea has no label; surrounding paragraph text is not
     programmatically associated and will not be read by screen readers
     as the field's label. -->
<p>Please describe your issue:</p>
<textarea name='message' rows='5'></textarea>

Textarea senza etichetta — Corretto

<!-- Using aria-labelledby to associate the existing visible heading
     with the textarea, or alternatively wrapping with a <label> element. -->
<label for='message'>Please describe your issue</label>
<textarea id='message' name='message' rows='5'></textarea>

Istruzioni di formato assenti per un campo data — Non corretto

<!-- Label present but no instruction about expected date format;
     users must guess whether to enter 01/06/2025 or 2025-06-01. -->
<label for='dob'>Date of birth</label>
<input type='text' id='dob' name='dob' />

Istruzioni di formato presenti per un campo data — Corretto

<!-- Format instruction is visible and linked via aria-describedby
     so screen readers announce it when the field receives focus. -->
<label for='dob'>Date of birth</label>
<span id='dob-hint'>Enter as DD/MM/YYYY, e.g. 15/06/1990</span>
<input type='text' id='dob' name='dob' aria-describedby='dob-hint' />

Errori Comuni

• Usare il placeholder come unica etichetta: Il testo del placeholder scompare all’immissione, non è annunciato in modo affidabile come etichetta da tutti i lettori di schermo e non aiuta gli utenti con disabilità cognitive che hanno bisogno di un testo di riferimento persistente. Fornisci sempre un <label> visibile oltre a qualsiasi placeholder.
• Posizionare visivamente un’etichetta vicino a un campo senza associazione programmatica: Un <p> o <span> posizionato visivamente sopra un input sembra un’etichetta per gli utenti vedenti ma viene ignorato dai lettori di schermo. Usa <label for='id'>, aria-labelledby o racchiudi l’input all’interno di un elemento <label>.
• Usare aria-label con testo che non corrisponde all’etichetta visibile: Quando il nome accessibile programmatico differisce dal testo visibile, gli utenti di controllo vocale non possono attivare il campo pronunciando ciò che leggono sullo schermo, violando il criterio SC 2.5.3 (Label in Name) e creando confusione per gli utenti di lettori di schermo.
• Etichettare un gruppo di pulsanti di opzione ma omettere la legenda del gruppo: I singoli pulsanti di opzione possono essere etichettati con il loro testo di opzione, ma se la domanda generale (ad es. «Metodo di pagamento») non è fornita tramite un <fieldset> e un <legend>, gli utenti che navigano da tastiera sentono ogni opzione isolatamente senza capire tra cosa stanno scegliendo.
• Identificare i campi obbligatori solo con il colore o con un asterisco: Un asterisco (*) accanto a un’etichetta non comunica nulla agli utenti di lettori di schermo a meno che il suo significato non sia spiegato (ad es. una nota in cima al modulo che afferma «I campi contrassegnati con * sono obbligatori») e i campi obbligatori non abbiano anche l’attributo required o aria-required='true'.
• Omettere le istruzioni di formato fino a dopo un invio non riuscito: Mostrare le regole per la password o i requisiti di formato della data solo nei messaggi di errore post-invio costringe gli utenti a commettere un errore prima di poter apprendere ciò che è richiesto. Le istruzioni devono essere presenti prima o al momento in cui l’utente interagisce con il campo.
• Nascondere le etichette usando display:none o visibility:hidden: Queste proprietà CSS rimuovono le etichette dall’albero di accessibilità. Se un’etichetta deve essere nascosta visivamente (ad es. per un design minimale), usa una classe CSS per il testo solo visivamente nascosto che mantenga l’elemento nell’albero di accessibilità spostandolo fuori dallo schermo.
• Usare l’attributo title come unica etichetta presumendo che sia sufficiente: Sebbene axe-core possa non segnalare un’etichetta basata solo su title, l’attributo title appare solo come tooltip al passaggio del mouse ed è inaccessibile agli utenti che usano solo la tastiera e agli utenti mobili. Dovrebbe essere usato come descrizione supplementare, non come etichetta principale.
• Applicare un singolo aria-label a un contenitore <div> aspettandosi che etichetti gli input figli: Le etichette ARIA sugli elementi contenitore non vengono ereditate dai controlli di modulo figli. Ogni controllo interattivo deve essere etichettato individualmente.
• Non riassociare le etichette dopo aggiornamenti dinamici del contenuto: Quando i campi del modulo vengono inseriti dinamicamente tramite JavaScript (ad es. aggiungendo una riga di indirizzo), gli input appena inseriti spesso non hanno etichette associate perché lo sviluppatore ha aggiunto solo il testo dell’etichetta visibile come elemento fratello senza il corretto collegamento for/id.

Relazione con le Normative di Accessibilità della Turchia

La Circolare Presidenziale 2025/10 della Turchia, pubblicata nella Gazzetta Ufficiale n. 32933 il 21 giugno 2025, stabilisce requisiti obbligatori di accessibilità web allineati a WCAG 2.2. Il Criterio di Successo WCAG 3.3.2 — Etichette o Istruzioni è un requisito di Livello A, il che significa che si colloca alla base della conformità ed è tra le disposizioni più rigorosamente applicate dalla circolare.

La circolare copre un’ampia gamma di tipologie di enti e le tempistiche di conformità differiscono per settore. Le istituzioni pubbliche — incluse i ministeri, i comuni, le agenzie statali e le organizzazioni finanziate con fondi pubblici — devono raggiungere la piena conformità al Livello A entro un anno dalla pubblicazione della circolare. Le entità del settore privato incluse nel campo di applicazione devono conformarsi entro due anni. Le entità del settore privato esplicitamente coperte includono piattaforme di e-commerce, banche e istituzioni finanziarie, ospedali e fornitori di assistenza sanitaria privati, società di telecomunicazioni con 200.000 o più abbonati, agenzie di viaggio, società di trasporto private e scuole private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE).

Per tutte queste entità, la mancata etichettatura dei campi dei moduli non è semplicemente una carenza di usabilità — costituisce una violazione diretta della normativa. I moduli sono pervasivi in tutti i servizi digitali coperti: i cittadini presentano domande sui portali governativi, i pazienti prenotano appuntamenti sui siti web degli ospedali, i clienti completano acquisti sulle piattaforme di e-commerce e gli studenti si iscrivono tramite i portali scolastici. Ognuno di questi percorsi si basa sui moduli, e ogni campo senza etichetta in tali moduli è una violazione dimostrabile del WCAG 3.3.2 che gli auditor possono documentare e riportare.

Le organizzazioni soggette alla circolare dovrebbero trattare la conformità al SC 3.3.2 come prerequisito per qualsiasi processo di audit o certificazione di accessibilità. Poiché si tratta di un criterio di Livello A, non può essere derogato o rinviato — le dichiarazioni di conformità parziale che escludono elementi di Livello A non sono riconosciute. Le entità che non possono dimostrare la presenza di input etichettati in tutti i loro moduli rivolti al pubblico rischiano rilievi regolatori, segnalazioni pubbliche di non conformità e danni reputazionali in un mercato in cui la fiducia digitale è sempre più legata al design inclusivo.

Da un punto di vista pratico, raggiungere la conformità al 3.3.2 è tra i passi a minor sforzo e maggior impatto che un’organizzazione possa intraprendere. Associare etichette ai controlli di modulo esistenti richiede in genere solo modifiche HTML minori e non ha alcun effetto sul design visivo se implementato correttamente. Per le organizzazioni che utilizzano l’SDK overlay di Accsible, il rilevamento automatico delle etichette mancanti può far emergere queste violazioni durante le scansioni di routine, fornendo ai team di sviluppo indicazioni di correzione attuabili prima delle scadenze regolatorie.