Capitolo 10
Anatomia di un toast
Un toast è la cosa più difficile da fare bene: dare un'informazione senza rubare l'attenzione, restare il giusto e andarsene quando ha finito. Sbagliare il tono, la durata o la voce lo trasforma da cortesia in interruzione.
Il capitolo scorso parlava di un oggetto che si tocca; questo parla di un messaggio che arriva. Il toast è la notifica più piccola dell’interfaccia — una striscia che compare in un angolo, dice una cosa, e se ne va — e proprio perché è piccola viene quasi sempre sottovalutata. Ma sotto quella semplicità si nasconde la domanda più difficile del feedback: come si dà un’informazione senza interrompere? Perché un toast vive su una lama: troppo discreto e nessuno lo legge, troppo invadente e diventa l’ennesima cosa da chiudere. La differenza fra una cortesia e un fastidio sta tutta in quattro decisioni — il tono, la durata, la posizione e la voce — che quasi nessuno prende di proposito.
La tentazione, col toast, è trattarlo come un canale unico: una scatola grigia che mostra qualsiasi cosa, sempre uguale, sempre per tre secondi, sempre nello stesso angolo. Ma un toast non è un contenitore neutro: è una scelta su quanto quel messaggio merita l’attenzione dell’utente. Una conferma e un errore non sono la stessa informazione, e fingere che lo siano è il primo modo per renderli entrambi inutili. Un «salvato» che resta finché non lo chiudi è attrito gratuito; un «pagamento rifiutato» che svanisce dopo due secondi è una piccola crudeltà. Il peso del messaggio decide tutto il resto.
Cinque dimostrazioni, una per ciascuna decisione: la priorità che convive in uno stack, l’annulla che sostituisce il «sei sicuro?», la persistenza contro l’auto-dismiss, la posizione che è informazione, e la voce che spiega contro quella che urla. E come sempre niente librerie: una live region nativa, un countdown onesto, un po’ di CSS. Il difficile non è il codice — è la disciplina di chiedersi, ogni volta, quanto pesa davvero ciò che stai per dire.
La priorità che convive
Il primo problema è la convivenza. I toast non arrivano mai uno alla volta in fila ordinata: prima o poi due informazioni si sovrappongono, e bisogna decidere come si accatastano e con che peso ciascuna si presenta.
Stack di priorità · info, success, warning, error
Premi «Lancia un toast» più volte: ne compare uno a caso fra i quattro livelli, e si accatastano in uno stack che si ricompone quando uno scade. Ogni livello ha un segno oltre al colore — la spunta per success, il triangolo per warning, l’ottagono per error, la «i» per info — perché chi non distingue i colori deve poter leggere il tipo dall’icona e dall’etichetta. Il colore è il terzo canale, mai l’unico: è la regola di accessibilità che torna in ogni capitolo. I toast più gravi restano in vita più a lungo (l’errore sette secondi, la conferma tre e mezzo): la durata stessa è un segnale di priorità.
L’onestà qui sta nel non confondere i livelli per fare scena: un’informazione di sistema non si traveste da errore per farsi notare, e una conferma non urla. Lo stack annuncia via aria-live=“polite”, la voce giusta per ciò che non è un’emergenza: lo screen reader li legge quando può, senza strappare il focus. E con prefers-reduced-motion i toast non scivolano né dissolvono — compaiono e spariscono già in posizione, stesso stato finale, nessun viaggio. Il riflusso dello stack, quando uno se ne va, resta lieve: i superstiti colmano il vuoto, non sobbalzano.
L’annulla che sostituisce la domanda
Il secondo è il toast più sottovalutato di tutti: quello che ti permette di tornare indietro. È la risposta onesta a un’intera categoria di dialog — il «sei sicuro?» che interrompe prima ancora che tu abbia sbagliato.
Annulla con countdown · agire prima, pentirsi dopo
Archivia la conversazione: l’azione si compie subito, e compare un toast con una barra che si svuota in circa cinque secondi. Finché la barra non è vuota, un clic su «Annulla» (o Esc) riporta tutto com’era. È il pattern più rispettoso per le azioni reversibili: non chiedere conferma prima — un dialog che blocca il flusso per qualcosa che forse l’utente voleva davvero — ma agire e offrire una via di ritorno. La finestra di cinque secondi non è casuale: meno di tre e chi legge piano non fa in tempo, più di otto e il toast diventa rumore che non se ne va.
Qui l’onestà è doppia. La prima: il countdown mostra esattamente quanto tempo resta — la barra non finge urgenza per spingerti a non annullare, dice la verità sulla finestra. La seconda: l’azione dev’essere davvero reversibile, altrimenti l’annulla è una bugia. Promettere «puoi tornare indietro» e poi non poterlo mantenere è un dark pattern. La barra è progresso funzionale, non decorazione: per questo con prefers-reduced-motion non sparisce, ma salta a step di un secondo invece di scorrere — continua a dire «quanto manca», senza il movimento continuo.
La scelta fra restare e andarsene
Terza decisione, e la più frequente da sbagliare: quanto deve durare un toast? La risposta non è un numero, è una domanda — l’utente deve leggerlo per agire? Da lì discendono due comportamenti opposti.
Persistente · per gli errori
Resta finché non lo chiudi. Per ciò che blocca.
Auto-dismiss · per le conferme
Sparisce dopo qualche secondo. Per ciò che rassicura.
Persistente vs auto-dismiss · l'errore resta, la conferma passa
A sinistra un toast persistente: simula un errore di pagamento e resta lì, immobile, finché non lo chiudi con la sua X. A destra uno auto-dismiss: simula un salvataggio e sparisce da solo dopo tre secondi e mezzo. La regola che li separa è una sola: la persistenza è per ciò che l’utente non può permettersi di perdere — un errore che blocca, una decisione da prendere; l’auto-dismiss è per ciò che può tranquillamente ignorare — una conferma che rassicura e basta. Costringere a chiudere un «salvato» è attrito inutile; far svanire un errore prima che venga letto lascia l’utente col problema ma senza il messaggio.
Il dettaglio che li distingue anche sotto la pelle è l’ARIA: il persistente è un role=“alert” con una X reale e il suo aria-label, perché chiede un’azione; l’auto è un role=“status” che annuncia e basta, perché non la chiede. Sbagliare l’abbinamento — un errore che svanisce, una conferma che intrappola — è il modo più comune di tradire la fiducia su un canale che dovrebbe essere il più innocuo dell’interfaccia. Con prefers-reduced-motion entrambi appaiono e scompaiono senza scorrimento: lo stato finale è identico, cambia solo il fatto che non viaggiano.
La posizione che è informazione
Quarta decisione, quasi sempre presa per inerzia: dove compare il toast. Non è una scelta estetica. Il posto dice qualcosa sul tipo di messaggio, e metterlo nel punto sbagliato confonde tanto quanto sbagliare le parole.
- Conferma · in alto a destra, vicino all’azione
- Stato globale · in basso al centro, fuori dal flusso
Posizione per tipo · vicino alla causa, o stabile e condivisa
Dentro un finto viewport, «Pubblica» fa comparire la conferma in alto a destra, vicino all’azione che l’ha generata e lontano dal contenuto su cui si lavora; «Vai offline» mostra lo stato di sistema in basso al centro, dove convenzionalmente vivono le barre di stato. La logica è questa: posiziona vicino alla causa quando il toast risponde a un gesto locale e periferico, e in un punto stabile e condiviso quando riguarda l’intera app. Mai sopra il contenuto attivo, mai dove copre il prossimo gesto dell’utente. Le linee grigie nel viewport servono proprio a mostrare che i toast non le coprono.
L’onestà del posizionamento è discreta ma reale: un toast che salta ogni volta in un punto diverso costringe l’occhio a cercarlo, e cercare è attrito. La coerenza — questo tipo sempre lì, quell’altro sempre là — è ciò che rende un toast leggibile senza pensarci. Visivamente i due toast sono aria-hidden e l’annuncio per gli screen reader passa da una live region separata, così la posizione resta un fatto puramente visivo che non si traduce in due letture diverse. Con prefers-reduced-motion compaiono già al loro posto, senza scivolare da fuori campo.
La voce che spiega e quella che urla
L’ultima decisione vive interamente nell’invisibile: che voce dà il toast a chi non lo vede? È la distinzione più trascurata dell’accessibilità, ed è anche quella che separa il rispetto dall’aggressione.
role="status" · aria-live="polite" Aspetta una pausa. Non interrompe la lettura.
role="alert" · aria-live="assertive" Interrompe subito. Solo per ciò che blocca.
status/polite vs alert/assertive · spiegare o interrompere
I due bottoni mostrano lo stesso toast con due voci diverse. «Annuncia con calma» usa role=“status” e aria-live=“polite”: lo screen reader aspetta una pausa nell’attività dell’utente e poi legge, senza interrompere. «Annuncia con urgenza» usa role=“alert” e aria-live=“assertive”: interrompe immediatamente e annuncia subito. È la differenza fra spiegare e urlare. Polite è per le conferme e le informazioni; assertive è per ciò che richiede attenzione adesso — una sessione scaduta, un errore che blocca.
La regola di onestà è la stessa del capitolo sul vuoto: assertive è un’interruzione, e interrompere è un costo che si paga ogni volta. Usarlo per un «salvato» è gridare al nulla e abituare l’utente a ignorare anche gli avvisi veri; non usarlo per un errore che blocca è lasciare al buio chi naviga col solo audio. Si alza la voce solo quando ne vale la pena. E la differenza non vive solo nell’ARIA: i due toast restano distinti anche all’occhio, per colore, icona ed etichetta — il canale sonoro è per chi non vede, ma il segno resta per tutti.
Cinque decisioni, un’unica disciplina: un toast non è una scatola neutra in cui versare qualsiasi messaggio, ma una serie di scelte sul peso di ciò che si dice. La priorità che convive senza confondersi, l’annulla che rende reversibile invece di chiedere conferma, la persistenza riservata a ciò che blocca, la posizione coerente che non costringe a cercare, la voce che si alza solo quando serve — ognuna risponde alla stessa domanda di fondo, quanto merita davvero l’attenzione dell’utente? Dare un’informazione senza interrompere non è una questione di grafica gentile: è il rispetto per un’attenzione che non è nostra, e che possiamo chiedere in prestito solo per il tempo e col tono che il messaggio merita.
Il prossimo capitolo resta tra i componenti ma cambia gesto ancora: dal messaggio che arriva alla scelta che si offre. Anatomia di un menu — come si offre una scelta senza nascondere il contesto, e come si tiene leggibile un elenco di azioni senza trasformarlo in un labirinto.