Sito che si rompe con lo zoom: il test di trenta secondi per capire se una pagina regge davvero

A prima vista l’immagine sembra una slide aziendale: fondo color carta, quattro quadratini blu come logo, un titolo nero e grosso che chiede se il tuo layout sopravvive allo zoom. Se la guardi meglio, però, è una lezione di progettazione chiusa in un rettangolo. In alto c’è una fascia con tre numeri collegati da frecce: 1280 pixel CSS, zoom al 400%, 320 pixel CSS. Sotto ci sono due finestre di browser disegnate. Nella prima, al 100%, il titolo Read At Your Pace sta a sinistra, il pulsante blu è compatto e a destra c’è un riquadro grigio-lilla. Nella seconda, al 400%, la stessa pagina si è ricomposta in una sola colonna: il testo va a capo, il pulsante occupa tutta la larghezza, il riquadro è sceso sotto e una barra di scorrimento verticale dice che si legge scendendo. Accanto ci sono tre spunte: il testo va a capo, i comandi restano disponibili, si scorre in basso e non di lato. In fondo, in piccolo, c’è il riferimento: W3C, WCAG 1.4.10.

Mi piace soprattutto per due dettagli che di solito mancano. Il primo è la nota che avverte che le finestre sono illustrative e non in scala. Il secondo è la frase in blu che chiude tutto: un controllo di accessibilità, non un audit WCAG completo. È un’onestà rara, e la uso come punto di partenza.

Il gesto più comune del web, quello che nessuno progetta

Premere Ctrl e più, oppure allargare due dita sullo schermo. Lo fa chi ha superato i quarant’anni e ha lasciato gli occhiali in cucina, chi legge sul tablet a letto, chi lavora con un portatile da 13 pollici, chi ha un’ipovisione vera e propria. Secondo l’Organizzazione Mondiale della Sanità la presbiopia è la prima causa di deficit della visione da vicino nel mondo, con circa 826 milioni di persone coinvolte. Non stiamo parlando di una minoranza.

Quando faccio revisioni di siti per enti e aziende, lo zoom è la prima cosa che provo, prima ancora di aprire il codice. In meno di un minuto vedo quasi sempre gli stessi problemi: il menu a tendina che copre metà dello schermo, l’intestazione fissa che si mangia lo spazio di lettura, il banner dei cookie che non si riesce più a chiudere perché il pulsante è finito fuori dallo schermo, le righe di testo che escono a destra e obbligano a scorrere avanti e indietro. Il sito non si è rotto per colpa dell’utente. Semplicemente nessuno l’aveva mai provato così.

Da dove viene lo zoom di oggi: prima il testo, poi la pagina intera

Chi ha cominciato a fare siti nei primi anni Duemila ricorda il menu Visualizza, Dimensione testo. Il browser allora ingrandiva solo i caratteri: le immagini e i box restavano com’erano. Su Internet Explorer, che era il browser dominante, i testi dichiarati in pixel spesso non si ingrandivano affatto. Per questo una generazione di progettisti, me compreso, ha imparato a scrivere le dimensioni in em, cioè in proporzione alla dimensione del carattere. Il W3C ha poi formalizzato questa pratica nella tecnica C28, che consiglia di dimensionare anche i contenitori del testo in em, così crescono insieme al testo invece di tagliarlo.

Il passo successivo è stato lo zoom dell’intera pagina, che ingrandisce tutto in proporzione: testo, immagini, margini. Internet Explorer 7 lo introdusse nel 2006, e c’è un aneddoto che a distanza di vent’anni trovo ancora istruttivo. Sul blog ufficiale del team di sviluppo, gli stessi ingegneri scrivevano che la richiesta più frequente degli utenti era che la pagina si ricomponesse quando veniva ingrandita, così da non vedere le barre di scorrimento orizzontali. Ammettevano anche che, per ragioni di calendario, quella funzione non sarebbe entrata in IE7. Nel frattempo offrirono lo scorrimento laterale con la rotellina del mouse. Il problema che l’infografica affronta oggi, insomma, era già chiaro a tutti nel 2006: ingrandire non basta, il contenuto deve anche riadattarsi.

Le due regole: 200% per il testo, 400% per il layout

Le Linee guida per l’accessibilità dei contenuti web (WCAG) fissano due soglie diverse, e conviene non confonderle.

Criterio 1.4.4, ridimensionamento del testo

È nato con WCAG 2.0 ed è di livello AA. Chiede che il testo, esclusi sottotitoli e immagini di testo, si possa ingrandire fino al 200% senza tecnologie assistive e senza perdere contenuti o funzioni. In pratica, raddoppiando la dimensione nulla deve sparire, sovrapporsi o restare tagliato in una casella troppo stretta.

Criterio 1.4.10, reflow

È arrivato con WCAG 2.1 ed è quello illustrato nella foto. Chiede che i contenuti a scorrimento verticale si possano usare a una larghezza equivalente a 320 pixel CSS senza perdere informazioni o funzioni e senza scorrere in due direzioni. Per i contenuti a scorrimento orizzontale la soglia è un’altezza di 256 pixel CSS. La matematica della fascia in alto è proprio questa: una finestra larga 1280 pixel, ingrandita al 400%, si comporta come uno schermo largo 320. Il W3C spiega bene il perché: se le righe escono dal bordo, chi legge deve andare avanti e indietro per ogni riga, perde il segno e fa molta più fatica, sia fisica sia mentale.

L’asterisco in fondo all’immagine richiama l’eccezione prevista dalla norma: restano escluse le parti che richiedono una disposizione bidimensionale per avere senso, come mappe, tabelle di dati complesse, diagrammi o editor. Una tabella con dodici colonne può scorrere di lato. Un paragrafo di testo no.

Perché il sito si rompe ingrandendo: i due colpevoli abituali

Nei progetti che controllo le cause sono quasi sempre due.

Il primo colpevole sono i font fissati in pixel. Lo zoom moderno ingrandisce anche i pixel, quindi il problema non si vede subito. Molte persone però non usano lo zoom: cambiano la dimensione predefinita del carattere nelle impostazioni del browser, che di solito è 16 pixel. Un testo scritto in px ignora questa preferenza, mentre uno in rem la rispetta, perché rem significa proprio multiplo della dimensione di base. Lo stesso vale per i contenitori: un box alto 60 pixel fissi, con dentro un testo che raddoppia, taglia il contenuto. Ed è esattamente il tipo di errore descritto dal criterio 1.4.4. La mia regola è semplice: rem per i caratteri, em o rem per spaziature e larghezze massime dei blocchi di testo, altezze lasciate libere quando c’è del testo dentro.

Il secondo colpevole è l’intestazione fissa in cima allo schermo. Su un portatile con una finestra di circa 1280 per 720, al 400% lo spazio utile diventa più o meno 320 per 180 pixel CSS. Un header fisso alto 80 pixel, che a dimensione normale sembra sottile, a quel punto occupa quasi metà dello schermo. Se poi ci si aggiunge una barra promozionale e il banner dei cookie, per il contenuto resta una fessura. La soluzione che adotto è far diventare l’intestazione non fissa sotto una certa altezza dello schermo, con una media query sull’altezza oltre che sulla larghezza. È una riga di CSS che quasi nessuno scrive.

Ci sono poi gli errori minori ma frequenti: larghezze minime imposte ai contenitori, che costringono a scorrere di lato; menu orizzontali che non diventano un menu compatto; finestre modali più alte dello schermo con il pulsante di chiusura irraggiungibile; e, sul telefono, pagine che bloccano del tutto l’ingrandimento con le due dita.

Il test di trenta secondi da fare stasera

Non serve essere progettisti. Apri dal computer il sito della tua banca, del tuo Comune o del negozio online dove compri più spesso, con la finestra del browser a schermo intero, e fai così:

Premi Ctrl e più (Cmd e più su Mac) finché arrivi al 400%.
Guarda se compare una barra di scorrimento in basso: se per leggere un paragrafo devi scorrere di lato, il reflow non funziona.
Prova ad aprire il menu e a chiuderlo: deve restare usabile e non coprire per sempre la pagina.
Cerca il pulsante principale, quello che conta davvero, come Accedi, Paga o Prenota: deve essere visibile e cliccabile.
Leggi un paragrafo intero: niente parole tagliate, niente testo sovrapposto ad altri elementi.
Sul telefono allarga due dita su un testo: se la pagina non si ingrandisce, qualcuno l’ha bloccata.

Ricordati però la frase in blu dell’infografica: superare questo test non vuol dire che il sito sia accessibile. Vuol dire solo che non fallisce su uno dei punti più evidenti.

Per chi gestisce un sito: la lista di controllo e l’European Accessibility Act

Dal 28 giugno 2025 si applica l’European Accessibility Act, la direttiva UE 2019/882, che in Italia è stata recepita con il decreto legislativo 82/2022. Riguarda anche molti soggetti privati: commercio elettronico, servizi bancari per i consumatori, trasporti, comunicazioni elettroniche, libri digitali. Le microimprese che forniscono servizi sono escluse. L’AgID ha pubblicato le linee guida definitive per l’applicazione italiana, e il riferimento tecnico pratico è la norma armonizzata EN 301 549, che per il web riprende i criteri WCAG, compresi i due di cui parliamo. Questa è la lista che consegno ai clienti come primo passo:

Tutte le dimensioni dei caratteri sono in rem e rispettano la preferenza dell’utente.
Nessun contenitore di testo ha un’altezza fissa in pixel.
La pagina si legge a 320 pixel CSS di larghezza senza scorrimento orizzontale, tabelle e mappe escluse.
Header, barre promozionali e banner non sono fissi quando lo schermo è basso.
Finestre modali e banner dei cookie si chiudono anche al 400%.
Il meta viewport non blocca l’ingrandimento sul mobile.
Il test viene ripetuto a ogni modifica importante del tema o del template, non solo al lancio.
Il risultato viene documentato nella dichiarazione di accessibilità, insieme alle altre verifiche WCAG.

Cosa insegna davvero quest’immagine

Quello che mi piace di questa grafica è che non mostra un sito bello: mostra un sito che si deforma bene. Il pulsante che si allarga, la colonna che scende sotto, il testo che va a capo non sono un ripiego, ma il progetto stesso. Ho visto team spendere settimane sulla versione desktop a 1440 pixel e dieci minuti sulla prova di zoom. Conviene fare il contrario: partire dalla colonna stretta e ingrandita, e poi allargare. Un layout che regge al 400% di solito regge anche tutto il resto. E le persone che lo usano non sanno nemmeno di essere state prese in considerazione: semplicemente, leggono.

Fonti

Tag:Interfacce digitali