Costruisci la copertura attorno ai percorsi cliente
Elenca i percorsi e i risultati che generano valore: trovare un servizio, cercare, aggiungere un articolo, prenotare, effettuare il login, chiedere assistenza o pagare. Per ciascuno, nomina i componenti che possono cambiare forma o fallire: navigazione, filtri, card, tabelle, immagini, banner, moduli, drawer e widget incorporati. Testa le larghezze in cui il tuo contenuto diventa vincolato, non solo il catalogo degli attuali modelli di telefono. Testa appena sotto, alla e appena sopra ogni breakpoint.
Includi telefoni a larghezza stretta e media, una larghezza simile a un tablet, laptop, desktop ampio e la modalità landscape quando modifica il compito.
Usa titoli lunghi, risultati vuoti, errori di validazione, badge di prezzo, indirizzi completi e etichette più lunghe quando quegli stati esistono.
Dimostra reflow, leggibilità e zoom
Conferma che la pagina abbia l'impostazione viewport appropriata, poi cerca lo scorrimento orizzontale a livello di pagina. Immagini fisse, campi larghi, margin negativi, pannelli off-canvas e banner sono cause comuni. Il criterio Reflow di WCAG 2.1 del W3C descrive contenuto con scorrimento verticale a una larghezza equivalente a 320 CSS pixel, inclusa una viewport di 1280 pixel a zoom 400%. Se quel criterio è nel perimetro, testa lo scenario di zoom reale. Una mappa, un video o una tabella dati potrebbero richiedere un layout bidimensionale, ma mantieni quello scorrimento all'interno del componente e lascia che la pagina circostante faccia il reflow.
Controlla header, contenuto principale, footer, barre sticky, dialog, e riepiloghi errori a ogni confine testato.
Riorganizza le informazioni per uno schermo stretto; non rimuovere silenziosamente un requisito, un dettaglio di prezzo o una via d'aiuto.
Stressa contenuti e form
Operazioni sui contenuti possono causare errori responsive senza una release CSS. Testa il titolo approvato più lungo, diversi badge, un'immagine mancante, un filtro selezionato, una lunga nota legale e un campo compilato dal browser. Quando le colonne si impilano, conferma che l'ordine di lettura e dell'accesso da tastiera abbia ancora senso. Completa il form reale su un dispositivo piccolo: apri controlli, correggi un errore e invia. Testa i widget di terze parti nella pagina simile alla produzione perché il loro contenitore, stato di consenso, font e stili possono alterare il risultato.
Riproduci le lunghezze e le combinazioni massime probabili, ma non includere dati cliente o di pagamento nelle prove QA.
Apri avvisi, chat, promozioni e messaggi di validazione insieme; nessuno dovrebbe coprire l'azione primaria o il campo focalizzato.
Esercita ogni percorso di input
Uno schermo ampio non garantisce un mouse, e uno schermo piccolo non garantisce solo il touch. La media feature hover verifica se un input primario può comodamente hoverare, quindi l'hover dovrebbe migliorare l'esperienza ma non essere l'unico percorso per un'azione o spiegazione. Testa l'uso da tastiera e con puntatore su desktop, tocchi e scorrimento su un dispositivo touch e dispositivi con input misti dove rilevante. Rivedi bottoni di chiusura compatti, stepper, chip, calendari e azioni a icona. WCAG 2.2 Target Size (Minimum) specifica una dimensione target di 24 per 24 CSS pixel con eccezioni definite, incluse spaziatura e link inline. È un criterio con scopo ed eccezioni, non una promessa che ogni controllo da 24 pixel sia ugualmente facile per tutti.
Naviga con Tab attraverso la pagina. Il focus dovrebbe rimanere visibile, seguire un ordine sensato ed entrare/uscire da menu e dialog in modo prevedibile.
Rendi una rivelazione essenziale da hover disponibile tramite focus, tap o un controllo visibile, e impedisci comportamenti confusi al primo tap.
Verifica asset e prestazioni sotto vincolo
Un'immagine può adattarsi al suo contenitore e comunque essere il file sbagliato per il dispositivo. Controlla che i media rimangano contenuti, riservino spazio di layout quando applicabile, preservino il crop utile e richiedano candidati appropriati. srcset e sizes forniscono al browser informazioni per scegliere tra le sorgenti immagine fornite; non garantiscono una richiesta specifica. Usa il throttling di DevTools per scoprire problemi presto, ma i suoi controlli CPU e rete simulano condizioni relative al computer di sviluppo. Riprova i percorsi chiave su un dispositivo reale e connessione reale. Ispeziona font, media hero, carousel, lavoro client-side e script di terze parti per ritardi, slittamenti o tocchi bloccati.
Cattura il percorso, il viewport, la connessione reale o simulata e cosa è diventato lento o instabile; confronta condizioni equivalenti.
Quando sicuro, ritarda embed non essenziali in una build di test per capire se il compito principale rimane utilizzabile.
Rimedia come lavoro proattivo di uptime
Per Status Is UP, la readiness responsive è ottimizzazione proattiva dell'uptime: identifica un percorso utente che blocca l'uso, correggi la causa, dimostra la riparazione e previeni il ripetersi. Non è un'affermazione che un alert di monitoraggio possa giudicare ogni difetto di layout o interazione. Prioritizza per impatto sul compito e portata. Prima del deployment, testa larghezze adiacenti e il percorso cambiato su hardware reale. Pianifica un rollback per modifiche a navigazione condivisa, stili, script, pagamenti o integrazioni. Dopo il rilascio, ripeti i passi di verifica e allega le prove al record di modifica.
Specifica percorso, dispositivo o viewport, orientamento, input, stato, risultato atteso, risultato reale e una cattura redatta.
Preferisci una correzione a livello di componente, regola layout, token o consegna immagine piuttosto che un override limitato a un singolo percorso; assegna alle eccezioni un proprietario e un piano di rimozione.