Migliori dialog blocks 2026: 9 sezioni verificate

Un blocco dialog è una finestra sopra la pagina, e il suo costo è quasi tutto invisibile. Il catalogo ne conta 9 da 3 registry, misurati il 1 novembre 2026 su /api/blocks/category/dialog: tre file di base, e un solo blocco con la variante annidata.

I quattro guasti che nessuno prova in preview

Il primo è il fuoco. Quando la finestra si apre, il fuoco deve entrare nel primo elemento utile; quando si chiude, deve tornare al pulsante che l'ha aperta. Un blocco che non lo fa lascia l'utente da tastiera sulla pagina sotto, e il dialogo diventa un ostacolo invece di un passaggio. Il secondo è lo scorrimento: se la pagina sotto continua a scorrere, su mobile il dito muove il contenuto sbagliato.

Il terzo è il contenuto che si perde. Una finestra con un modulo dentro che si chiude con Esc o con un clic sullo sfondo butta via quello che l'utente ha scritto, senza chiedere. Il quarto è l'annidamento: aprire un secondo dialogo dal primo funziona solo se il blocco gestisce lo stack dei fuochi, e la maggior parte non lo fa.

Le verifiche prima di adottarlo

• Se la finestra dichiara un titolo con identificativo e lo collega con aria-labelledby.
• Se chiude con Esc, con il clic sullo sfondo e con un pulsante visibile, e se il fuoco torna al punto di partenza.
• Se blocca lo scorrimento della pagina sotto, e se lo ripristina quando si chiude.
• Se il modulo interno è un componente separato, così puoi annullare la chiusura quando ci sono modifiche non salvate.
• La licenza del publisher, che sui blocchi con form allegato è quella da leggere per prima.

Il numero di file racconta il caso d'uso. Due file significano finestra e modulo già separati, che è la forma giusta quando dentro c'è una richiesta da inviare. Un file significa una finestra di conferma o di contenuto: va bene per un avviso, non per un modulo, perché il contenuto e la cornice non si possono testare separatamente.

Il limite da dichiarare all'utente

Nessuno dei 9 blocchi custodisce il contenuto non salvato. Non c'è una guardia che chieda conferma prima di chiudere con modifiche in sospeso, e non c'è memoria dello stato quando la finestra si riapre. Il secondo limite è la licenza del publisher, che copre il componente e non il comportamento: quello lo verifichi tu, con la tastiera, in trenta secondi.

La regola che evita la finestra sbagliata

Se dentro c'è un modulo, prendi il blocco a due file con il contenuto separato e aggiungi la conferma di chiusura. Se è una conferma secca, non serve un blocco: la primitiva più trenta righe bastano e ti lascia il controllo sul testo del pulsante. E se il contenuto supera l'altezza dello schermo, valuta un pannello laterale, che su mobile è più facile da chiudere e non nasconde il contesto.

L'alternativa è una pagina dedicata. Costa una navigazione in più e non ha nessuno dei problemi di fuoco, scorrimento e stack, perché il contesto è uno solo. La finestra conviene quando l'azione è breve e non deve far perdere il punto in cui l'utente si trova; la pagina conviene quando l'azione ha più passaggi o richiede un ritorno indietro dal browser.

Il contenuto lungo merita una prova a parte. Una finestra con venti righe di testo su uno schermo da 640 pixel deve scorrere al proprio interno, con l'intestazione e i pulsanti fermi. Se il blocco fa scorrere tutta la finestra, il pulsante di chiusura esce dallo schermo e l'utente resta senza via d'uscita visibile. Prova la preview riducendo l'altezza della finestra del browser: è il test più rapido e il più trascurato.

curl "https://ui.eneawork.it/api/blocks/category/dialog?limit=10"

Le finestre sono in /blocks/category/dialog, i componenti di base in /components/cat/dialog e le icone di chiusura in /icons. Il caso completo è in dialog accessibile con shadcn, il test manuale in test di accessibilità con axe; il confronto tra finestra e pannello laterale è in portal e modali in React.