Autocompilazione moduli online: perché il browser a volte indovina tutto e a volte sbaglia ogni campo

La scheda è pulita, quasi didattica. Su fondo panna, a sinistra, quattro campi di un modulo: Full name, Email, Street address, Postal code. Ognuno ha l’etichetta in grassetto sopra e un testo grigio di esempio dentro la casella. A destra, collegata da una freccia blu, c’è la riga di codice che spiega al browser che cosa contiene quel campo: name, email, shipping street-address, shipping postal-code. In basso tre regole: usare il valore giusto per ogni campo, tenere le etichette visibili, provare davvero la compilazione automatica. Sembra una cosa da sviluppatori, invece riguarda chiunque abbia comprato qualcosa dal telefono in piedi sul tram.

Il fastidio lo conosciamo tutti. Il browser mette il cognome nel campo del nome, il CAP finisce dove andava la città, oppure non propone proprio niente e tocca riscrivere l’indirizzo con il pollice. In tanti anni passati a progettare e a rivedere moduli di registrazione e checkout ho capito che quasi mai la colpa è del browser. Il più delle volte chi ha costruito il sito non ha detto al browser che cosa stava chiedendo. Questa scheda mostra il pezzo che spesso manca.

Cosa succede dietro le quinte quando il browser compila un modulo

Ogni browser moderno conserva i dati che digitiamo: nome, indirizzi, telefono, a volte le carte di pagamento. Quando incontriamo un nuovo modulo, prova ad abbinare ogni casella al dato giusto. Per farlo ha due strade.

La prima è tirare a indovinare. Il browser legge il nome tecnico del campo, l’etichetta e il testo di esempio, e da questi indizi cerca di capire se si tratta di un nome, di una via o di un codice postale. Le guide di Google per gli sviluppatori spiegano proprio questo: se due siti diversi usano un campo chiamato name, il browser può riproporre sul secondo il valore inserito sul primo. È una tecnica fragile. Basta un campo chiamato campo3, un’etichetta ambigua o due caselle per nome e cognome descritte in modo confuso, e l’abbinamento salta.

La seconda strada è quella mostrata nella foto: l’attributo autocomplete dell’HTML. Chi progetta il modulo dichiara in modo esplicito lo scopo del campo, scegliendo da un elenco standard definito nella specifica HTML del WHATWG. A quel punto il browser non deve più indovinare. È la differenza tra lasciare un pacco con scritto roba e lasciarlo con l’etichetta cucina, piatti fragili.

Il vocabolario che il browser capisce

L’elenco ufficiale è più ricco di quanto si pensi, e conoscerlo cambia il modo di disegnare un modulo. Per il nome ci sono name per il nome completo, given-name per il nome di battesimo e family-name per il cognome. Se il modulo li chiede in due caselle separate e non lo dichiara, ecco il classico cognome finito nel posto sbagliato. Per l’indirizzo ci sono street-address oppure address-line1 e address-line2, postal-code per il CAP e address-level2 per la città. Per il telefono ci sono tel, tel-country-code per il prefisso internazionale e tel-national. Per i pagamenti ci sono cc-name, cc-number, cc-exp e cc-csc.

Il dettaglio più interessante della scheda sono le parole shipping davanti all’indirizzo. La specifica permette di aggiungere un contesto: shipping per la spedizione e billing per la fatturazione. In un checkout con due indirizzi diversi è proprio questo che evita al browser di mescolarli. Se volessi spingermi oltre, farei notare che nella scheda anche il nome potrebbe essere dichiarato come nome di spedizione, perché chi riceve il pacco non è sempre chi paga. Ma come esempio introduttivo la scelta di semplificare regge.

Perché non è solo comodità: il criterio WCAG 1.3.5

Nel 2018 il W3C ha pubblicato le WCAG 2.1, le linee guida internazionali per l’accessibilità dei contenuti web. Tra i nuovi criteri c’è l’1.3.5, Identificare lo scopo degli input, di livello AA. In sostanza chiede che lo scopo di ogni campo che raccoglie dati sull’utente sia riconoscibile da una macchina, usando proprio l’elenco di valori dell’HTML.

Il documento di approfondimento del W3C spiega bene il perché. Riconosce che compilare in automatico aiuta tutti, ma pesa molto di più per chi ha disabilità cognitive, motorie o di memoria. Per chi digita con fatica, ogni campo precompilato è uno sforzo in meno. Per chi fa fatica a ricordare il proprio CAP o a capire che cosa chiede una casella, un browser o una tecnologia assistiva che conosce lo scopo del campo può proporre il dato giusto. Può anche mostrare accanto al campo un’icona familiare, per esempio una casetta per l’indirizzo.

In Italia la cosa ha anche un peso normativo. Le linee guida AgID si appoggiano alla norma europea EN 301 549, che riprende le WCAG. Con l’entrata in vigore dei requisiti dell’European Accessibility Act, dal 28 giugno 2025 l’accessibilità riguarda anche molti servizi digitali privati, e-commerce compreso. Un modulo che non dichiara lo scopo dei campi oggi non è solo scomodo: in molti casi non è conforme.

I numeri del checkout: dove si perdono i clienti

Chi gestisce un negozio online dovrebbe tenere a mente due dati. Il Baymard Institute, che da tredici anni studia l’usabilità dei checkout, stima che circa il 70% dei carrelli venga abbandonato. Tra i motivi dichiarati dagli utenti, quasi uno su cinque indica un checkout troppo lungo o complicato. L’altro dato viene da uno studio pubblicato da Chrome a fine 2024. Rispetto a chi digita tutto a mano, chi usa la compilazione automatica abbandona i moduli il 75% in meno e impiega circa il 35% di tempo in meno. Sono numeri di Google sul proprio browser, quindi li prendo con la giusta cautela, ma la direzione è chiara. Ogni campo che il browser riesce a riempire è un passaggio in meno in cui il cliente può rinunciare.

I casi italiani: codice fiscale, civico, prefisso

Qui l’esperienza diretta conta, perché i nostri moduli hanno qualche particolarità che lo standard internazionale copre solo in parte.

Codice fiscale: nell’elenco HTML non esiste un valore per i codici identificativi nazionali. Nessun browser lo compilerà in modo standard. Qualche gestore di dati personali permette di salvarlo come campo personalizzato, ma il progettista non può contarci. Meglio un campo ben etichettato, con l’indicazione del formato e un controllo che accetti anche le lettere minuscole senza protestare.
Numero civico separato: molti siti italiani chiedono via e civico in due caselle. Lo standard non prevede un valore apposito per il civico. Così il browser inserisce Via Roma 12 intero nel primo campo e lascia vuoto il secondo, oppure il controllo di validazione lo rifiuta. Dove possibile consiglio un unico campo indirizzo dichiarato come address-line1, che accetti via e civico insieme.
Prefisso: se il modulo divide prefisso internazionale e numero, i due campi vanno dichiarati come tel-country-code e tel-national. Altrimenti capita di vedere il +39 incollato due volte.
Provincia e città: la città corrisponde di solito ad address-level2. Per la provincia, spesso proposta come menu a tendina con le sigle, vale la pena verificare con prove reali come si comportano i diversi browser.

Password manager: perché a volte non scatta

Lo stesso principio vale per l’accesso ai siti. Le guide di Google per moduli di accesso e registrazione consigliano username per il nome utente o l’email di accesso, current-password per la password in uso e new-password per quella da creare. Quest’ultimo valore dice al gestore di password che deve proporre una password nuova e robusta, non incollare quella vecchia. C’è poi one-time-code per i codici via SMS, che su molti telefoni fa comparire il codice appena ricevuto sopra la tastiera.

Quando il password manager non si attiva, quasi sempre il modulo è costruito male: campi senza etichetta, campi creati dinamicamente o un autocomplete off messo ovunque per abitudine. Su questo MDN è netta: per i campi di accesso molti browser ignorano quel divieto, proprio perché impedire di salvare le password spinge le persone a sceglierne di più deboli.

La prova dei trenta secondi

Per capire se un modulo è progettato bene non serve aprire il codice. Faccio sempre così:

Tocco il primo campo, il nome. Se il browser propone subito un profilo salvato, buon segno.
Accetto il suggerimento e controllo campo per campo: nome e cognome al posto giusto, CAP nel CAP, città nella città.
Correggo a mano un campo, per esempio l’interno o la scala. Il modulo deve accettare la modifica senza ricompilare tutto o cancellare il resto. È la terza regola della scheda: verificare sia la compilazione automatica sia le correzioni manuali.
Guardo le etichette: devono restare visibili anche dopo la compilazione. Un testo grigio dentro la casella sparisce appena il campo si riempie, e a quel punto non so più che cosa ho davanti. Non a caso la scheda lo dice chiaramente: i suggerimenti non sostituiscono etichette chiare.

Se il modulo supera tutti e quattro i passaggi, dietro c’è qualcuno che ci ha pensato.

Come configurare i dati salvati senza rischi

Dal lato di chi compila, qualche accortezza fa la differenza. Nelle impostazioni del browser, alla voce indirizzi o compilazione automatica, conviene controllare i profili salvati. Spesso ci sono vecchi indirizzi o versioni con errori di battitura che continuano a uscire. Io tengo due profili ben separati, casa e lavoro, e cancello il resto. Per le carte di pagamento preferisco salvare solo numero e scadenza, mai il codice di sicurezza: molti browser e gestori lo richiedono comunque a ogni acquisto, ed è giusto così. Sui computer condivisi, lavoro o famiglia, la compilazione automatica di indirizzi e carte va disattivata, perché chiunque si siede alla tastiera vedrebbe gli stessi suggerimenti.

Un dettaglio invisibile che dice molto del progetto

Questa scheda non mostra un oggetto da mettere in salotto. Mostra però una cosa che ritrovo in tutto il buon design: la fatica tolta all’utente nasce da una scelta precisa e quasi invisibile di chi ha progettato. Quattro righe di attributi non cambiano l’aspetto di un modulo, ma cambiano il modo in cui si usa. Per qualcuno, sono la differenza tra riuscire a usarlo e rinunciare. È il genere di cura che nessuno nota quando c’è e che tutti notano quando manca.