1. Scegli il compito della pagina prima del layout
Inizia con le pagine che trasportano un compito cliente o di business: pagine di servizio, schede prodotto, form per lead, prenotazioni, accesso account, carrello e help. Scrivi una dichiarazione di completamento per ciascuna, ad esempio: “Un visitatore alla prima visita può comprendere questo servizio, vedere prove rilevanti e richiedere una chiamata.” Se la pagina ha più di un compito, decidi quale apparirà per primo.
Elenca il suo contenuto come essenziale, di supporto o opzionale. Essenziale non significa breve; un visitatore può avere bisogno del contesto dei prezzi, dei requisiti di eleggibilità, dei dettagli di consegna o delle informazioni di confronto. Fornisci quel materiale con una via chiara nel layout stretto. Google consiglia contenuti primari equivalenti su mobile e desktop, consentendo però una presentazione diversa come schede o accordion.
A una larghezza stretta, un collega dovrebbe essere in grado di dire cosa offre la pagina, chi aiuta e la prossima azione significativa.
2. Rendi completo il baseline stretto
Inizia con un percorso a colonna singola funzionante anziché rimpicciolire un layout desktop. Usa contenitori flessibili, lascia che il testo vada a capo e includi un'impostazione viewport che permetta al browser di adattare il layout alla larghezza del dispositivo. Non impedire lo zoom. Verifica che menu, avvisi, immagini, embed e errori dei form rimangano dentro la viewport; lo scorrimento orizzontale involontario dell'intera pagina è normalmente un difetto.
Usa 320 CSS pixels come check impegnativo di reflow per la lettura e i contenuti di task ordinari. WCAG 2.2 descrive la presentazione di contenuti verticali a quella larghezza senza perdita di informazioni o funzionalità o scorrimento bidimensionale. Una mappa, un grafico o una tabella dati possono richiedere la propria area di scorrimento, ma questo non giustifica rendere la pagina circostante scorrevole lateralmente.
Adatta le immagini al loro contenitore e fornisci le dimensioni in modo che il browser possa riservare lo spazio prima che si carichino.
3. Aggiungi potenziamenti senza rendere fragile il percorso di base
Il progressive enhancement significa che contenuti e funzionalità essenziali funzionano come baseline, mentre browser capaci e schermi più ampi ricevono extra. L'indirizzo, i dettagli del prodotto, le etichette del modulo, la spiegazione del prezzo e il percorso di invio non dovrebbero dipendere da animazioni, hover o script caricati tardivamente. Un layout più largo può aggiungere un pannello di confronto, una navigazione persistente o filtri più ricchi senza rendere incompleto il baseline.
Chiedi all'implementatore di aggiungere un breakpoint quando il contenuto diventa compresso o inefficiente, non perché appare un nome di dispositivo in una lista. Un breakpoint è semplicemente il punto in cui cambia una regola di layout. Non usare layout stretti per rimuovere silenziosamente testo di aiuto, termini di policy, recensioni, metadata o dettagli strutturati importanti.
Mostra prima un'immagine di galleria di base e la descrizione, poi aggiungi zoom o controlli di swipe quando i loro script sono disponibili.
4. Progetta i controlli per il tocco, la chiarezza e il recupero
L'ergonomia del tocco significa progettare per le mani piuttosto che per un puntatore preciso del mouse. Dai a pulsanti, checkbox, icone di chiusura, selettori di quantità e scelte di modulo dimensioni e separazione sufficienti per ridurre i tocchi errati. Etichetta le icone quando il loro significato non è ovvio. Non rendere l'hover l'unico modo per rivelare un prezzo, un sottomenu, una spiegazione o un'azione.
WCAG 2.2 include un criterio di livello AA sul target-size di almeno 24 by 24 CSS pixels per gli obiettivi pointer, con eccezioni indicate che includono spaziatura e link inline. Trattalo come riferimento minimo, non come garanzia di comfort. Le azioni critiche meritano etichette chiare, spazi generosi e un passo di conferma reversibile. Cerca una revisione qualificata per l'accessibilità nei percorsi ad alto rischio o per rivendicazioni formali di conformità.
Mantieni le etichette visibili, mostra feedback di validazione utilizzabili e conserva i valori inseriti dopo un errore.
5. Tratta media e embed come parte del percorso del visitatore
Decidi se ogni immagine è informativa, persuasiva o decorativa. Un'immagine informativa richiede un'alternativa testuale appropriata e un ritaglio per layout stretto che preservi il dettaglio necessario. Le opzioni responsive per le immagini permettono ai browser di scegliere una risorsa adatta invece di costringere ogni visitatore a scaricare l'asset desktop più grande. Non lasciare che un'immagine hero o un video oscurino lo scopo della pagina e l'azione principale.
Fai l'inventario di mappe, chat, video, pagamenti, scheduling, widget di consenso e recensioni. Su uno schermo stretto, verifica il loro stato di caricamento, le dimensioni dei controlli, il layout delimitato e una rotta di fallback pratica. Per flussi di pagamento, identità o dati regolamentati, coinvolgi revisori qualificati per sicurezza, privacy e conformità; il testing visivo non è una valutazione di sicurezza.
Registra ogni componente esterno, il suo owner, la sua funzione di business e il fallback approvato se è lento o guasto.
6. Testa i percorsi di task prima del rilascio e pianifica la rimedio
Usa la modalità responsive del browser presto per ispezionare larghezze strette, medie e ampie. Chrome Device Mode può approssimare viewport, tocco, orientamento, rete e condizioni CPU, ma Chrome lo documenta come un'approssimazione e non come esecuzione su dispositivo reale. Completa i percorsi critici su telefoni reali e browser rilevanti quando possibile.
Testa un task, non solo uno screenshot: cold load, navigazione, invio del modulo invalido e valido, cambio di orientamento, zoom e ritorno da uno schermo di terze parti. Registra l'URL, il browser o dispositivo, il task, il risultato atteso, il responsabile e la decisione di rollback. Per cambiamenti importanti di template, checkout, CMS o dipendenze, stagia il rilascio e preparati a ripristinare il percorso precedente invece di improvvisare sotto pressione.
Approva solo dopo che il task critico funziona, i controlli sono utilizzabili, lo scorrimento orizzontale a livello di pagina è assente e le dipendenze chiave hanno un fallback.