Test dei moduli di indirizzo nel 2026: una checklist QA in 40 punti

Inizia annotando ogni campo, il suo scopo, il limite di archiviazione e se è obbligatorio. Metà dei difetti di questa checklist sono impossibili da valutare senza quella tabella, perché "il modulo ha rifiutato il mio indirizzo" non è azionabile finché non sai quale campo l'ha rifiutato e perché.

I vincoli devono essere per paese, non globali. Una lunghezza massima unica di 10 per il codice postale funziona per la maggior parte dei paesi e si rompe per l'Irlanda a 8 caratteri con uno spazio, e una lunghezza massima globale di 30 per la città tronca parecchi nomi reali. Imposta limiti generosi e valida il pattern del paese invece di una lunghezza scelta per un solo mercato.

Cambiare il paese deve azzerare la regione, rietichettare il campo del codice postale, cambiare la tastiera e il pattern e cancellare qualsiasi stato di validazione obsoleto. Il bug classico è una provincia canadese rimasta selezionata dopo il passaggio agli Stati Uniti, che invia un modulo dall'aspetto valido con una coppia di valori impossibile.

Hong Kong e gli Emirati Arabi Uniti non hanno codici postali, quindi il campo deve diventare facoltativo e l'etichetta deve dirlo. Il Giappone inverte l'ordine dell'indirizzo, e il modulo dovrebbe presentare i campi nell'ordine locale o chiarire che ci si aspetta l'ordine occidentale. Prova il cambio in entrambe le direzioni e prova un cambio di paese dopo che è già stato mostrato un errore di validazione.

Valida il formato al blur, valida i campi obbligatori all'invio e cancella un errore non appena il valore diventa valido. Validare a ogni pressione di tasto punisce un utente che è a metà della digitazione di un codice postale, e validare solo all'invio significa che l'utente scopre sei errori in una volta senza alcuna guida.

Non disabilitare mai il pulsante di invio come sostituto della validazione. Un pulsante disabilitato senza spiegazione è la lamentela di accessibilità più comune nei moduli di indirizzo, perché l'utente non riesce a capire cosa manca e uno screen reader potrebbe non annunciare il cambiamento. Mantieni il pulsante abilitato, invia e mostra un riepilogo con link a ciascun campo.

Un messaggio di errore deve dire quale campo è sbagliato, qual è il formato accettato e come correggerlo. "Indirizzo non valido" fallisce tutti e tre. "Il codice postale deve essere di 5 cifre, ad esempio 97205" li supera tutti. Per i paesi il cui formato è insolito, includi un esempio invece di un pattern, perché gli utenti non leggono le regex.

Posiziona l'errore accanto al campo e anche in un riepilogo in cima al modulo quando il modulo è lungo. Associalo con aria-describedby e imposta aria-invalid sull'input. Sposta il focus sul primo campo non valido all'invio, o sul riepilogo se il riepilogo è interattivo. Prova con uno screen reader, non solo visivamente.

L'incolla è dove emergono i bug di formattazione. Un utente incolla "K1A 0B1" con uno spazio unificatore, o un indirizzo completo nella riga 1. Il modulo deve fare il trim, normalizzare i separatori noti e preservare gli spazi interni. Non deve rimuovere i trattini da uno ZIP+4 o da un codice olandese, e non deve convertire in maiuscolo il nome di una città che è legittimamente in maiuscole e minuscole miste.

La compilazione automatica dipende dai nomi corretti dei token. Usa address-line1, address-line2, address-level2 per la città, address-level1 per la regione, postal-code e country, e non riutilizzare street-address su un campo a riga singola a meno che non sia davvero un blocco stradale multilinea. Su mobile, le tastiere numeriche di solito non hanno il trattino, quindi uno ZIP+4 o un codice olandese inserito con inputmode="numeric" diventa impossibile da completare. Usa inputmode="text" dove il pattern consente separatori.

Prova il limite e un carattere oltre per ogni campo. Il troncamento è peggio del rifiuto, perché l'utente vede un invio riuscito e il valore archiviato è sbagliato. Se la colonna del database è di 50 caratteri e il modulo ne consente 100, il difetto appare solo su input lunghi, che è esattamente ciò che i fixture scritti a mano non contengono mai.

Prova i caratteri non ASCII: lettere accentate, l'apostrofo in O Connell, il trattino in un nome di via francese, la esse dura in una via tedesca e le scritture da destra a sinistra. Verifica che il valore faccia il round-trip attraverso l'API, il database, l'esportazione CSV e l'etichetta stampata. I bug di codifica spesso appaiono solo al passaggio di esportazione, che è il passaggio che nessuno testa.

Ogni campo ha bisogno di un'etichetta visibile associata programmaticamente all'input. Il testo segnaposto non è un'etichetta: scompare all'input e viene annunciato in modo incoerente. Raggruppa i campi dell'indirizzo in un fieldset con una legend e rendi le select di paese e regione utilizzabili da tastiera con il type-ahead.

Per le localizzazioni da destra a sinistra, imposta dir sul contenitore e non sui singoli input, così la punteggiatura e l'icona di errore restano al posto giusto. Verifica che le etichette tradotte non trabocchino al 200 percento di zoom e che il riepilogo degli errori venga annunciato quando appare. Sono controlli economici che intercettano i difetti per cui gli audit di accessibilità fanno pagare.

Trasforma la checklist in un piccolo pacchetto automatizzato che viene eseguito a ogni modifica. Venti casi coprono l'insieme dei guasti: un caso valido e uno non valido per il mercato principale, un caso ciascuno per Canada, Regno Unito, Germania, Giappone, Brasile, Hong Kong e UAE, più lunghezze limite, una città non ASCII, un valore incollato con uno spazio unificatore e un cambio di paese dopo un errore.

Mantieni ogni caso indipendente e con seed. Verifica la forma del risultato invece di una stringa letterale e verifica il testo visibile dell'errore per i casi non validi, perché le regressioni dei testi di errore sono regressioni reali. Un pacchetto di queste dimensioni viene eseguito in pochi secondi e intercetta la maggior parte dei difetti descritti sopra.