Tastiera sbagliata sul telefono nei moduli online: perché succede e come capire se un modulo è progettato bene

Ha l’aria di un cartello didattico: fondo bianco, due riquadri azzurro pallido affiancati, titoli con le grazie e codice in blu. A sinistra c’è un campo Quantità con dentro un 3 grande e due pulsanti, meno e più, attaccati al bordo destro. A destra c’è un Identificativo numerico, un codice socio che si legge 00142, scritto in carattere monospaziato. Sotto ciascun campo c’è una sola riga di codice. A sinistra type=number, a destra type=text con inputmode=numeric. In fondo, in grassetto, la frase che conta più di tutte: inputmode non convalida l’input.

Sembra una questione per sviluppatori, ma riguarda un fastidio che conosciamo tutti. Devi scrivere il CAP, l’IBAN o il codice arrivato via SMS e il telefono ti apre la tastiera con le lettere. A quel punto cerchi il tasto 123, sbagli, torni indietro. Ho progettato e collaudato parecchi moduli per mobile e ti dico una cosa: quasi mai è colpa del telefono. È il sito a dirgli quale tastiera aprire, e quando sbaglia si vede subito.

Dai tasti fisici a una lastra di vetro

Con il T9 la tastiera era fatta di plastica e non cambiava mai. Dodici tasti, tre o quattro lettere ciascuno, e il telefono provava a indovinare la parola. Quando nel 2007 è arrivato il primo iPhone, quella certezza è sparita: la tastiera è diventata software, disegnata sullo schermo e quindi modificabile in ogni momento.

Da questo punto la storia si fa interessante. All’ingegnere Ken Kocienda toccò il compito di far scrivere le persone su un vetro senza riferimenti tattili. Nella sua testimonianza raccolta dal Computer History Museum racconta che il lavoro più duro non fu disegnare i tasti ma la correzione automatica, cioè il sistema che trasforma i tocchi imprecisi nelle lettere che intendevi davvero. Prima di arrivare a un tasto per lettera, il gruppo provò diverse strade, comprese tastiere con più lettere per tasto, figlie dirette dell’epoca del T9. La versione che conosciamo oggi nasce da lì: un tasto per lettera, piccolo, con un software che corregge dietro le quinte.

Una tastiera fatta di software porta con sé una conseguenza che all’inizio quasi nessuno notava: può cambiare forma a seconda di cosa devi scrivere. Se il campo chiede un numero di telefono, i tasti possono diventare grandi come quelli di un tastierino. Se chiede un’email, la chiocciola può stare in primo piano. Ma perché succeda qualcuno deve dirlo al telefono.

Chi decide quale tastiera vedi

Nei moduli web lo decide il codice HTML del campo. Le leve principali sono due, ed è proprio quello che l’immagine mette a confronto.

type dice che cosa è il dato: un testo, un numero, un’email, un indirizzo web, un telefono. Il tipo cambia il comportamento del campo, compresi i controlli e il modo in cui il browser legge il valore.
inputmode è soltanto un suggerimento sulla tastiera da mostrare. Lo standard HTML del WHATWG prevede valori come numeric (solo cifre), decimal (cifre più separatore decimale), tel (tastierino telefonico), email, url e search, più text e none.

La frase in alto nel cartello riassume tutto bene: si sceglie il tipo in base al significato del dato e si usa inputmode per suggerire la tastiera. Sono due decisioni diverse. Quando vengono confuse, nascono i moduli che ci fanno arrabbiare.

Un numero non è sempre un numero

Il riquadro di sinistra mostra il caso giusto per type=number: quanti pezzi vuoi ordinare. Qui fare calcoli ha senso, perché 3 più 1 fa 4, e i pulsanti meno e più sono una scelta naturale. Il campo si comporta da numero perché il dato è un numero.

Nel riquadro di destra c’è un codice socio, 00142. Contiene solo cifre ma non è una quantità. Nessuno lo somma, nessuno lo aumenta di uno. Se lo tratti come numero, gli zeri iniziali spariscono e 00142 diventa 142, cioè un altro codice. Per questo il cartello consiglia di tenerlo come testo e di chiedere la tastiera con le cifre attraverso inputmode.

Lo standard HTML lo dice chiaramente: il tipo number non va bene per un dato che è fatto solo di cifre ma che non è, in senso stretto, un numero. Gli esempi che porta sono proprio i numeri di carta di credito e i codici postali. Nella mia esperienza è l’errore che trovo più spesso nei moduli italiani, con il CAP, la carta di credito, il codice OTP e il numero di pratica. Gli effetti sono sempre gli stessi:

gli zeri iniziali spariscono, e i CAP che cominciano con 0, come quelli di molte province del Centro, finiscono per corrompersi;
sul computer compaiono le freccette per aumentare e diminuire il valore, che su un CAP non hanno alcun senso;
la rotella del mouse o un gesto di scorrimento possono cambiare il valore senza che tu te ne accorga;
se il numero è molto lungo, come quello di una carta, il browser può arrotondarlo o mostrarlo in notazione scientifica.

La lezione del governo britannico

Il caso più istruttivo che conosco viene dal GOV.UK Design System, il sistema di componenti che usano i servizi digitali del governo britannico. Nel 2020 il gruppo ha pubblicato le ragioni per cui ha smesso di usare type=number come scelta predefinita. I test con gli utenti avevano mostrato che con quel tipo di campo c’è il rischio di modificare per sbaglio il numero mentre si scorre la pagina. In più, se qualcuno scrive qualcosa che non è un numero, il campo non spiega cosa è andato storto. La soluzione adottata è quella del riquadro di destra: un campo di testo con inputmode=numeric, a cui si aggiunge un controllo sul formato.

Mi piace questo caso perché non nasce da una preferenza estetica. È una decisione presa dopo aver osservato persone vere che compilavano moduli veri, molte delle quali usavano tecnologie assistive. In un servizio pubblico ogni errore di quel tipo diventa una telefonata al call center o una pratica bloccata.

inputmode non controlla niente

Ed ecco la frase in grassetto con i tre quadratini 1, 2, 3. Chiedere la tastiera numerica non impedisce di inserire lettere. Chi incolla un testo, chi usa una tastiera fisica collegata al telefono o chi ha una tastiera alternativa può scrivere quello che vuole. Il controllo va fatto a parte, e i messaggi d’errore devono essere chiari: per esempio «Il CAP deve avere 5 cifre», non un generico «Valore non valido».

L’ultima riga del cartello è un ottimo promemoria anche per noi: i codici postali possono contenere lettere. Il CAP italiano è fatto di sole cifre, ma quello britannico, canadese o olandese no. Se il tuo modulo accetta indirizzi esteri, una tastiera solo numerica blocca le persone che vivono fuori dall’Italia. Lo stesso vale per l’IBAN, che comincia con due lettere (IT) e quindi non può essere numerico, e per il codice fiscale. Il suggerimento sulla tastiera deve adattarsi ai formati che accetti davvero, non a quello che ti aspetti nella maggior parte dei casi.

Il tasto invio che cambia nome

C’è un dettaglio che pochi notano. Il tasto in basso a destra della tastiera virtuale può cambiare etichetta. Con l’attributo enterkeyhint, anche questo definito nello standard HTML, il sito può chiedere che il tasto diventi Avanti, Vai, Cerca, Invia o Fine. Sembra poco, ma in un modulo lungo un tasto Avanti ti accompagna da un campo all’altro senza dover toccare lo schermo, e un tasto Invia nell’ultimo campo ti avvisa che stai per spedire tutto.

Il codice SMS che si compila da solo

Per i codici di verifica che arrivano via SMS esiste un aiuto in più. Lo standard prevede per l’attributo autocomplete il valore one-time-code, che permette al sistema di proporre il codice appena ricevuto direttamente sopra la tastiera. Se lo combini con inputmode=numeric l’esperienza diventa quasi trasparente: arriva il messaggio, tocchi il suggerimento e hai finito. Le stesse indicazioni di autocompletamento servono anche all’accessibilità. Le linee guida WCAG del W3C, al criterio 1.3.5, chiedono che lo scopo dei campi sui dati personali (nome, email, telefono, indirizzo) sia dichiarato in modo leggibile dalle macchine, così browser e tecnologie assistive possono compilarli al posto tuo.

Il test di un minuto che puoi fare su qualsiasi modulo

Quando collaudo un modulo dal telefono faccio sempre questa sequenza. Non serve sapere programmare, la puoi ripetere la prossima volta che ti iscrivi a un servizio o paghi una bolletta online.

Tocca il campo email: dovresti vedere la chiocciola in evidenza senza cercarla.
Tocca il campo telefono: dovrebbe aprirsi il tastierino grande con i numeri, come quando componi una chiamata.
Tocca CAP o codice OTP: servono solo le cifre. Se compare la tastiera con le lettere, chi ha progettato il modulo non ci ha pensato.
Scrivi un CAP che comincia con 0, poi torna sul campo: se lo zero è sparito, il campo è stato impostato come numero.
Guarda il tasto invio: se dice Avanti o Invia nel momento giusto, dietro c’è attenzione al dettaglio.
Prova a scrivere una lettera dove non va: un buon modulo ti spiega cosa correggere, uno cattivo resta in silenzio oppure cancella tutto.

Se un modulo supera tutte e sei le prove, quasi sempre è curato anche nel resto. Se ne sbaglia due o tre, mi aspetto problemi anche più avanti.

Perché un cartello così vale più di mille linee guida

Questa immagine mi piace perché riduce un tema tecnico a una scelta che chiunque capisce: questo dato si può sommare oppure no? Se sì, è un numero. Se no, è un testo che contiene cifre e gli si chiede la tastiera adatta. È lo stesso ragionamento di Kocienda quasi vent’anni fa: la tastiera giusta è quella che anticipa ciò che la persona sta per fare. Sullo schermo di un telefono, dove ogni tocco sbagliato costa tempo e pazienza, questa attenzione è la differenza tra un modulo che si compila in trenta secondi e uno che si abbandona a metà.