WCAG 1.3.5: Identificare lo scopo dell’input

Cosa Significa Questa Regola

WCAG 1.3.5 — Identify Input Purpose è un criterio di livello AA introdotto in WCAG 2.1 e mantenuto in WCAG 2.2. Richiede che qualsiasi elemento <input>, <select> o <textarea> che raccoglie informazioni sull’utente abbia il proprio scopo comunicato in modo programmatico, così che browser e tecnologie assistive possano identificare e agire automaticamente in base a quello scopo.

Il meccanismo per soddisfare questo criterio è l’attributo autocomplete, combinato con il corretto valore token dall’elenco ufficiale definito nella specifica HTML. Quando un campo raccoglie il nome, l’indirizzo email, il numero di telefono, l’indirizzo postale, il numero di carta di credito o dati personali simili dell’utente, l’attributo autocomplete deve avere un valore che descriva accuratamente lo scopo di quel campo — per esempio, autocomplete="given-name" per un campo del nome proprio, o autocomplete="email" per un campo email.

Il criterio si applica specificamente agli input che raccolgono informazioni sull’utente stesso. Non si applica ai campi in cui un utente inserisce dati su qualcun altro (per esempio, un modulo di prenotazione di viaggio che chiede il nome del passeggero quando l’utente prenota per conto di un’altra persona), né si applica ai campi in cui l’autocompletamento creerebbe un rischio di sicurezza — come password monouso o challenge in stile CAPTCHA, che possono legittimamente usare autocomplete="off" o autocomplete="one-time-code".

Un esito positivo richiede che: (1) ogni campo di input nel perimetro abbia un attributo autocomplete; e (2) il valore di tale attributo sia un token valido e riconosciuto dalla specifica HTML per l’autofill — non una stringa arbitraria, non un valore vuoto quando ne è richiesto uno significativo, e non un token scritto in modo errato. Si ha un esito negativo quando un input nel perimetro non ha l’attributo autocomplete, ha autocomplete="off" senza giustificazione, o ha un token non valido come autocomplete="firstname" (il token corretto è given-name) o autocomplete="phone" (il token corretto è tel).

L’elenco completo dei token autocomplete validi è mantenuto dallo standard vivo HTML del WHATWG e include valori per nomi (given-name, family-name, additional-name), indirizzi (street-address, address-line1, postal-code, country-name), informazioni di contatto (email, tel, tel-national), credenziali (username, current-password, new-password), dettagli di pagamento (cc-name, cc-number, cc-exp, cc-csc) e altro. I token possono anche essere preceduti da identificatori di sezione (ad es. section-billing) e da parole chiave per spedizione o fatturazione per gestire più gruppi di indirizzi sulla stessa pagina.

Perché È Importante

Questo criterio esiste principalmente a beneficio degli utenti con disabilità cognitive, incluse persone con dislessia, deficit di memoria, disturbi dell’attenzione e disturbi dell’apprendimento. Per questi utenti, compilare correttamente un modulo di checkout complesso — con campi separati per nome proprio, cognome, indirizzo, città, codice postale, telefono e dettagli di pagamento — può rappresentare un notevole carico cognitivo. Quando i token autocomplete sono corretti, i browser possono precompilare i campi dal profilo salvato dell’utente con una singola interazione, riducendo drasticamente gli attriti e il rischio di errori.

Gli utenti con disabilità motorie — incluse persone con funzionalità limitata delle mani che usano accesso a interruttore, software di eye-tracking o dispositivi sip-and-puff — ne traggono un beneficio equivalente. Per questi utenti, digitare è lento, faticoso e talvolta doloroso. Un autofill che funziona in modo affidabile può trasformare un compito di dieci minuti in un’attività quasi istantanea. Secondo l’Organizzazione Mondiale della Sanità, circa 1,3 miliardi di persone nel mondo vivono con una forma significativa di disabilità, e le disabilità motorie che colpiscono il controllo fine delle mani sono tra le più comuni.

Oltre all’autofill, i token autocomplete corretti consentono a browser e tecnologie assistive di presentare icone personalizzate, etichette o interfacce di input aumentate — per esempio, visualizzando automaticamente un tastierino telefonico per un campo tel su un dispositivo mobile, o mostrando un’icona di carta di credito per un campo cc-number. I gestori di password, che sono strumenti di accessibilità fondamentali per gli utenti con deficit di memoria, si basano anch’essi su questi token per identificare e compilare correttamente i campi delle credenziali.

Si consideri uno scenario reale: una persona con paralisi cerebrale sta compilando una domanda per benefici governativi. Il modulo ha dodici campi che coprono nome, indirizzo, ID nazionale e dettagli di contatto. Senza valori autocomplete corretti, ogni campo deve essere digitato manualmente. Un solo token scritto in modo errato — per esempio, autocomplete="surname" invece di autocomplete="family-name" — è sufficiente a impedire al browser di riconoscere il campo, lasciando l’utente a digitare il proprio cognome carattere per carattere. Con token corretti, l’intero modulo può essere compilato automaticamente in pochi secondi, riducendo sia lo sforzo sia il tasso di errore.

Esistono anche benefici in termini di usabilità e tasso di conversione per le organizzazioni: le ricerche mostrano costantemente che i moduli compatibili con l’autofill hanno tassi di abbandono più bassi e tassi di completamento più alti, il che significa che correggere i token autocomplete non è solo un miglioramento dell’accessibilità ma anche un miglioramento diretto per il business.

Regole Axe-core Correlate

• autocomplete-valid — Questa è la regola axe-core principale per WCAG 1.3.5. Ispeziona ogni elemento <input>, <select> e <textarea> che ha un attributo autocomplete e verifica se il valore dell’attributo è un token valido e riconosciuto dalla specifica HTML per l’autofill. La regola segnala gli elementi in cui il token è scritto in modo errato (ad es. given name con uno spazio invece di un trattino), in cui è stato usato un valore proprietario non standard (ad es. autocomplete="first-name"), o in cui l’ordine dei token in un valore multi-token è errato (ad es. posizionando il nome del campo prima di un prefisso di sezione richiesto). La regola non segnala i campi a cui manca del tutto l’attributo autocomplete — tale situazione richiede una revisione manuale — perché axe-core non può determinare in modo programmatico se un dato campo rientra nel perimetro del criterio (cioè se raccoglie informazioni sull’utente).
• Perché è necessario anche il test manuale — Strumenti automatizzati come axe-core possono solo verificare che un valore autocomplete presente sia sintatticamente corretto; non possono determinare se il token scelto descrive accuratamente lo scopo del campo. Per esempio, un campo telefono di fatturazione con autocomplete="email" supererebbe la regola automatizzata (poiché email è un token valido) ma non soddisferebbe il criterio perché il token non corrisponde allo scopo effettivo del campo. Allo stesso modo, gli strumenti automatizzati non possono identificare i campi a cui manca l’attributo autocomplete ma che dovrebbero averlo, perché determinare se un campo raccoglie informazioni personali sull’utente richiede il giudizio umano basato sul contesto. Una revisione manuale di ogni campo del modulo che raccoglie dati specifici dell’utente è quindi essenziale per una conformità completa con 1.3.5.

Come Eseguire i Test

1. Esegui una scansione automatizzata con axe DevTools o Lighthouse. Apri la pagina che contiene il modulo in Chrome o Firefox. In axe DevTools, fai clic su "Analyze" e filtra i risultati per l’ID della regola autocomplete-valid. In Lighthouse, esegui un audit di accessibilità e cerca violazioni che fanno riferimento ad autocomplete. Annota ogni elemento segnalato e registra i valori di token non validi riportati. Risolvi ogni elemento segnalato e riesegui la scansione per confermare la correzione.
2. Identifica manualmente tutti i campi di input nel perimetro. Esamina il modulo ed elenca ogni campo che raccoglie informazioni sull’utente corrente — campi nome, campi indirizzo, email, telefono, dettagli di pagamento, credenziali. Per ciascun campo, verifica che sia presente un attributo autocomplete e che il suo token corrisponda allo scopo effettivo del campo secondo l’elenco dei token HTML per l’autofill. I campi che raccolgono informazioni su altre persone sono fuori dal perimetro e possono essere esclusi.
3. Verifica il comportamento di autofill del browser. In Chrome o Firefox, assicurati che il browser abbia un profilo salvato (Impostazioni > Autofill). Vai alla pagina del modulo e fai clic nel primo campo di informazioni personali. Conferma che il browser presenti un suggerimento di autofill e che, selezionandolo, compili i campi corretti con i valori corretti. Ripeti per i campi indirizzo, i campi di pagamento e i campi delle credenziali. Se l’autofill non suggerisce valori o compila i campi sbagliati, è probabile che i token autocomplete siano errati.
4. Effettua test con una combinazione screen reader + browser. Con NVDA e Firefox, spostati su ciascun campo del modulo usando il tasto Tab. NVDA dovrebbe annunciare l’etichetta e lo scopo del campo; alcune combinazioni di screen reader e browser annunceranno anche lo scopo di autocomplete. Con VoiceOver su macOS (Safari), spostati tra i campi usando Tab e ascolta che VoiceOver annunci la disponibilità dell’autofill. Con JAWS e Chrome, passa allo stesso modo tra i campi con Tab e conferma che JAWS annunci il contesto previsto del campo. Sebbene gli screen reader non annuncino sempre esplicitamente i token autocomplete, confermare che l’autofill funzioni correttamente in combinazione con la navigazione da tastiera convalida che lo scopo programmatico è esposto.
5. Ispeziona gli attributi autocomplete negli Strumenti di sviluppo del browser. Fai clic con il tasto destro su ciascun campo del modulo e seleziona "Inspect". Nel pannello Elements, conferma che l’attributo autocomplete sia presente e che il suo valore corrisponda esattamente a un token valido. Presta particolare attenzione ai valori multi-token — per esempio, autocomplete="shipping street-address" — e conferma che l’ordine dei token segua la specifica (nome della sezione, poi "shipping" o "billing", poi il nome del campo).

Come Correggere

Campi nome — Non corretto

<!-- Invalid: uses non-standard token 'firstname' instead of 'given-name' -->
<label for='fname'>First Name</label>
<input type='text' id='fname' name='first_name' autocomplete='firstname'>

<label for='lname'>Last Name</label>
<input type='text' id='lname' name='last_name' autocomplete='surname'>

Campi nome — Corretto

<!-- Valid: uses the exact WHATWG-specified tokens 'given-name' and 'family-name' -->
<label for='fname'>First Name</label>
<input type='text' id='fname' name='first_name' autocomplete='given-name'>

<label for='lname'>Last Name</label>
<input type='text' id='lname' name='last_name' autocomplete='family-name'>

Modulo indirizzo con sezioni fatturazione e spedizione — Non corretto

<!-- Invalid: missing autocomplete attributes entirely on address fields -->
<fieldset>
  <legend>Billing Address</legend>
  <input type='text' name='bill_street' placeholder='Street Address'>
  <input type='text' name='bill_city' placeholder='City'>
  <input type='text' name='bill_postal' placeholder='Postal Code'>
</fieldset>

Modulo indirizzo con sezioni fatturazione e spedizione — Corretto

<!-- Valid: autocomplete tokens include 'billing' prefix and correct field names -->
<fieldset>
  <legend>Billing Address</legend>
  <input type='text' name='bill_street' autocomplete='billing street-address' placeholder='Street Address'>
  <input type='text' name='bill_city' autocomplete='billing address-level2' placeholder='City'>
  <input type='text' name='bill_postal' autocomplete='billing postal-code' placeholder='Postal Code'>
</fieldset>

Campo telefono — Non corretto

<!-- Invalid: uses 'phone' which is not a recognized autocomplete token -->
<label for='tel'>Phone Number</label>
<input type='text' id='tel' name='telephone' autocomplete='phone'>

Campo telefono — Corretto

<!-- Valid: 'tel' is the correct autocomplete token for a full phone number -->
<label for='tel'>Phone Number</label>
<input type='tel' id='tel' name='telephone' autocomplete='tel'>

Credenziali di accesso — Non corretto

<!-- Invalid: autocomplete='off' prevents password managers and autofill from working -->
<label for='user'>Username</label>
<input type='text' id='user' name='username' autocomplete='off'>

<label for='pass'>Password</label>
<input type='password' id='pass' name='password' autocomplete='off'>

Credenziali di accesso — Corretto

<!-- Valid: 'username' and 'current-password' allow password managers to function correctly -->
<label for='user'>Username</label>
<input type='text' id='user' name='username' autocomplete='username'>

<label for='pass'>Password</label>
<input type='password' id='pass' name='password' autocomplete='current-password'>

Errori Comuni

• Usare autocomplete="firstname" o autocomplete="first-name" invece del token corretto given-name". Questi valori non standard non sono riconosciuti dai browser o dalle tecnologie assistive anche se sembrano logici. Usa sempre i token esatti della specifica HTML per l’autofill.
• Usare autocomplete="phone" invece di autocomplete="tel". La parola "phone" non è un token valido. La specifica usa tel per un numero di telefono completo e tel-national, tel-area-code, tel-local per le sotto-parti di un numero di telefono.
• Impostare autocomplete="off" sui campi delle credenziali come misura di sicurezza mal concepita. I browser moderni e la specifica WCAG riconoscono entrambi che impedire l’autofill sui moduli di login crea barriere reali per gli utenti con disabilità e non migliora in modo significativo la sicurezza. Usa invece autocomplete="username" e autocomplete="current-password".
• Omettere completamente l’attributo autocomplete sui campi di dati personali, presumendo che il browser dedurrà lo scopo dal nome o dall’etichetta del campo. I browser usano euristiche per indovinare lo scopo del campo, ma queste sono inaffidabili e incoerenti tra i vari browser. I token espliciti sono necessari per garantire un’esperienza accessibile.
• Usare autocomplete="address" invece dei sotto-token specifici per l’indirizzo. Non esiste un token address nella specifica. Devi usare singolarmente street-address, address-line1, address-line2, address-level1 (stato/provincia), address-level2 (città) e postal-code.
• Posizionare le parole chiave shipping o billing nell’ordine sbagliato nei valori multi-token. L’ordine corretto è: prefisso di sezione opzionale (ad es. section-billing), poi parola chiave opzionale shipping/billing, poi il token del nome del campo. Scrivere autocomplete="street-address billing" è non valido; la forma corretta è autocomplete="billing street-address".
• Applicare autocomplete solo ai campi visibili e ignorare i campi nascosti o rivelati dinamicamente. I campi che sono inizialmente nascosti ma resi visibili tramite interazione dell’utente (come linee di indirizzo aggiuntive o campi opzionali) devono anch’essi avere token autocomplete corretti quando diventano attivi.
• Usare JavaScript per rimuovere o sovrascrivere dinamicamente l’attributo autocomplete dopo il caricamento della pagina. Alcune librerie di form o framework UI reimpostano gli attributi degli input quando i componenti vengono montati o ri-renderizzati, rimuovendo involontariamente i token autocomplete. Verifica sempre che l’attributo persista nel DOM live dopo l’esecuzione di tutto il JavaScript.
• Presumere che type="email" o type="tel" su un input sia sufficiente a comunicare lo scopo senza autocomplete. Sebbene type fornisca alcune informazioni, l’attributo autocomplete è un segnale separato ed esplicito richiesto da WCAG 1.3.5 e usato in modo diverso da browser e tecnologie assistive.
• Usare lo stesso token autocomplete su due campi diversi che raccolgono dati differenti. Per esempio, etichettare sia un campo email di lavoro sia un campo email personale con autocomplete="email" confonde i browser e può portare a un autofill errato. Usa prefissi di sezione (ad es. section-work email vs. section-personal email) per disambiguare.

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 di accessibilità vincolanti per un’ampia gamma di organizzazioni che operano in Turchia. La Circolare impone la conformità a WCAG 2.2 a livello AA come standard di base per i servizi digitali, il che include direttamente WCAG 1.3.5 — Identify Input Purpose.

Le tipologie di entità coperte dalla Circolare sono molto ampie. Le istituzioni pubbliche e le agenzie governative sono tenute a soddisfare questi standard per tutti i servizi digitali rivolti ai cittadini. Le organizzazioni del settore privato coperte includono piattaforme di e-commerce, banche e fornitori di servizi finanziari, ospedali e fornitori di servizi sanitari, operatori di telecomunicazioni con 200,000 o più abbonati, agenzie di viaggio autorizzate, società private di trasporto passeggeri e istituzioni educative private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE). L’implicazione pratica è che praticamente ogni principale prodotto digitale rivolto ai consumatori in Turchia — dalle app bancarie ai checkout del retail online fino ai portali per appuntamenti sanitari — deve avere token autocomplete implementati correttamente su tutti i campi di input dei dati personali.

Per WCAG 1.3.5 in particolare, ciò significa che qualsiasi modulo di checkout di e-commerce turco, modulo di apertura di conto bancario, modulo di registrazione paziente ospedaliero o modulo di sottoscrizione telecom che raccolga informazioni sull’utente come nome, indirizzo, numero di telefono o dettagli di pagamento deve includere valori di attributo autocomplete validi su ogni campo di input pertinente. Il mancato rispetto di ciò costituisce una non conformità di livello AA e può impedire a un’organizzazione di ottenere o mantenere il Logo di Accessibilità (Erişilebilirlik Logosu), il marchio ufficiale rilasciato dal Ministero della Famiglia e dei Servizi Sociali che certifica che i servizi digitali di un’organizzazione soddisfano gli standard di accessibilità.

Il Logo di Accessibilità ha un peso reputazionale e regolatorio, e le organizzazioni in mercati consumer competitivi — come l’e-commerce e il settore bancario — hanno forti incentivi a ottenerlo e mantenerlo. Poiché WCAG 1.3.5 è semplice da implementare (aggiungere o correggere i valori dell’attributo autocomplete non richiede modifiche architetturali) e offre benefici significativi agli utenti con disabilità cognitive e motorie, rappresenta uno dei miglioramenti di accessibilità a più alto valore e minore sforzo che un’organizzazione possa apportare nel perseguire la piena conformità di livello AA ai sensi della Circolare 2025/10.

Le organizzazioni dovrebbero verificare tutti i moduli presenti nelle proprie proprietà digitali — incluse le interfacce web mobile e i layout responsive — e stabilire una policy di sviluppo che richieda token autocomplete corretti come parte standard di qualsiasi implementazione di modulo. Questo dovrebbe essere applicato tramite test automatizzati nelle pipeline CI/CD usando strumenti come axe-core, in modo che le regressioni vengano intercettate prima di arrivare in produzione.