WCAG 1.4.10: Riflusso

Cosa Significa Questa Regola

WCAG 1.4.10 Reflow è un criterio di successo di livello AA introdotto in WCAG 2.1 e mantenuto in WCAG 2.2. Specifica che i contenuti web devono essere in grado di rifluire — cioè riorganizzarsi e ridimensionarsi — in modo da rimanere pienamente utilizzabili con una larghezza del viewport equivalente a 320 pixel CSS, senza richiedere all’utente di scorrere orizzontalmente per leggere o interagire con i contenuti. Il riferimento di 320 pixel CSS corrisponde a ciò che un utente vede quando imposta lo zoom del browser al 400% su uno schermo standard largo 1280px.

Il requisito fondamentale è che non ci sia alcuna perdita di informazioni o funzionalità a questa larghezza limitata. Tutto il testo deve rimanere leggibile, tutti i controlli interattivi devono rimanere utilizzabili e tutti i contenuti significativi devono rimanere visibili senza attivare lo scorrimento bidimensionale. Lo scorrimento verticale è consentito — il criterio vieta solo lo scorrimento orizzontale per contenuti che scorrono verticalmente (e lo scorrimento verticale per contenuti che scorrono orizzontalmente, anche se questo è raro). Un layout che costringe le persone a scorrere contemporaneamente in alto-in-basso e a sinistra-destra per leggere un paragrafo di testo non soddisferebbe questo criterio.

Il W3C definisce eccezioni esplicite in cui lo scorrimento bidimensionale è accettabile. Queste includono contenuti in cui il layout bidimensionale è essenziale per l’uso e il significato: grandi tabelle di dati con molte colonne, mappe complesse e diagrammi geografici, lettori video e i relativi controlli di riproduzione, barre degli strumenti con più pulsanti di azione affiancati, e giochi o diagrammi interattivi che richiedono una relazione spaziale precisa tra gli elementi. Queste eccezioni devono essere interpretate in modo restrittivo — l’esenzione si applica al contenuto stesso (per esempio, le celle di una tabella di dati), non alla navigazione circostante, alle intestazioni o al testo esplicativo che lo accompagna.

Una pagina supera questo criterio se: quando il browser è zoomato al 400% (o il viewport è impostato a 320px di larghezza), i contenuti rifluiscono in una singola colonna, la navigazione si comprime o si dispone in pila in modo appropriato, le immagini si ridimensionano proporzionalmente e l’utente può fare tutto ciò che poteva al livello di zoom predefinito usando solo lo scorrimento verticale. Una pagina non supera il criterio se è necessario lo scorrimento orizzontale per leggere le frasi, raggiungere i pulsanti o accedere a qualsiasi contenuto non esente.

Perché È Importante

Secondo l’Organizzazione Mondiale della Sanità, circa 2,2 miliardi di persone nel mondo vivono con qualche forma di disabilità visiva. Una parte significativa di queste persone si affida allo zoom del browser, all’ingrandimento del sistema operativo o a software dedicati di ingrandimento dello schermo (come ZoomText o Lente di ingrandimento di Windows) per rendere il testo e gli elementi dell’interfaccia abbastanza grandi da essere percepiti comodamente. Quando un layout si rompe a livelli di zoom elevati — spingendo i contenuti fuori dallo schermo o richiedendo lo scorrimento orizzontale — queste persone si trovano di fronte a un’esperienza di lettura frammentata in cui ogni frase richiede un movimento di panoramica avanti e indietro. Questo non è solo scomodo; può rendere i contenuti complessi di fatto inaccessibili.

Si consideri un utente di 65 anni con degenerazione maculare legata all’età che naviga nel portale di prenotazione appuntamenti di un ospedale turco con il browser impostato al 300% di zoom. Se il modulo di prenotazione viene reso con colonne a larghezza fissa, il pulsante “Invia” può essere spinto completamente oltre il margine destro dell’area visibile. L’utente non ha modo di sapere che il pulsante esiste, tanto meno di interagirvi. Non può prenotare il proprio appuntamento in modo autonomo. Questo è un danno diretto e concreto causato dal mancato rispetto di Reflow.

Oltre alle persone con ipovisione, Reflow avvantaggia un’ampia gamma di persone. Le persone con disabilità motorie che usano accesso a scansione o dispositivi di tracciamento del capo trovano lo scorrimento orizzontale estremamente difficile o impossibile da eseguire in modo affidabile. La disabilità cognitiva riguarda una parte significativa della popolazione, e la ricerca mostra costantemente che layout stretti a colonna singola — tipici di un Reflow ben implementato — riducono il carico cognitivo e migliorano la comprensione della lettura. Anche le persone che usano dispositivi con schermo piccolo o che leggono in modalità schermo diviso ne traggono beneficio diretto, anche senza alcuna disabilità.

Da una prospettiva tecnica e di business, implementare correttamente Reflow coincide quasi completamente con la realizzazione di un design responsive ben strutturato. Ciò significa che la conformità al criterio 1.4.10 migliora naturalmente l’usabilità mobile, riduce i tassi di abbandono e contribuisce positivamente alle metriche Core Web Vitals che influenzano il posizionamento nei motori di ricerca. In particolare per le piattaforme di e-commerce turche, dove il traffico mobile domina, la conformità a Reflow e l’ottimizzazione commerciale per il mobile sono essenzialmente lo stesso obiettivo.

Regole Axe-core Correlate

WCAG 1.4.10 Reflow richiede test manuali piuttosto che scansioni automatiche. Nessuna regola di axe-core può automatizzare completamente il rilevamento dei fallimenti di Reflow perché il criterio dipende dal comportamento visivo e funzionale dell’intero layout renderizzato a una dimensione specifica del viewport — qualcosa che richiede un vero ambiente browser, un giudizio umano sulla scorrevolezza e la verifica che non sia andata persa alcuna informazione. Gli strumenti automatici non possono distinguere in modo affidabile tra scorrimento bidimensionale intenzionale (per una mappa o tabella esente) e un overflow di layout non intenzionale causato da un contenitore a larghezza fissa.

• Test manuale — larghezza viewport 320px: Ridimensionare il viewport del browser esattamente a 320 pixel CSS di larghezza (o zoomare al 400% su uno schermo largo 1280px) e scorrere verticalmente attraverso ogni template di pagina, stato di schermata e componente interattivo. Verificare che nessun contenuto sia tagliato, che non compaia alcuna barra di scorrimento orizzontale per contenuti non esenti e che tutta la funzionalità rimanga raggiungibile. Axe DevTools segnalerà questo come elemento “Needs Review” piuttosto che come violazione automatica, perché l’analisi del layout basata su strumenti non può determinare se l’overflow rappresenti un vero fallimento o rientri in un’esenzione.
• Segnale parziale automatizzato — controllo del meta tag viewport: Axe-core può rilevare se la pagina utilizza un tag meta name='viewport' con user-scalable=no o maximum-scale=1, entrambi impediscono alle persone di zoomare e quindi rendono impossibile raggiungere lo stato di zoom al 400% a cui mira Reflow. Sebbene tecnicamente si tratti di un problema separato (WCAG 1.4.4), è strettamente correlato e la sua presenza garantisce un fallimento di Reflow. Axe segnala questo sotto la regola meta-viewport. Qualsiasi pagina che blocca lo zoom blocca anche per definizione la conformità a Reflow.
• Verifica manuale dei componenti: Oltre al layout a livello di pagina, singoli componenti come caroselli, intestazioni fisse (sticky), finestre modali, widget di chat flottanti, banner sui cookie e tabelle di dati richiedono ciascuno una verifica individuale a 320px. L’intestazione di una pagina può rifluire correttamente mentre una modale promozionale viene resa con una larghezza fissa di 600px e un pulsante di chiusura irraggiungibile — un fallimento che solo una revisione manuale componente per componente rileverà.

Come Eseguire i Test

1. Pre-scansione automatizzata: Eseguire axe DevTools o Lighthouse in Chrome DevTools su ogni pagina. Cercare in particolare la violazione meta-viewport, che indica che lo zoom è bloccato e garantisce un fallimento di Reflow. Annotare anche eventuali avvisi relativi all’overflow contrassegnati come “Needs Review”. Registrare i risultati ma tenere presente che una scansione automatica pulita non conferma la conformità a Reflow — i passaggi manuali sono obbligatori.
2. Impostare il viewport a 320px: In Chrome o Firefox DevTools, aprire la barra degli strumenti per i dispositivi (Ctrl+Shift+M / Cmd+Shift+M), inserire una dimensione personalizzata del dispositivo di 320×568 pixel (o qualsiasi altezza) e impostare il device pixel ratio a 1. In alternativa, aprire una finestra del browser larga 1280px e zoomare al 400% usando Ctrl+= (Cmd+= su Mac). Entrambi i metodi simulano la condizione di 320 pixel CSS specificata da WCAG.
3. Scorrere verticalmente l’intera pagina: A partire dalla parte superiore della pagina, scorrere verso il basso usando solo la barra di scorrimento verticale o la rotellina del mouse. In nessun momento dovrebbe apparire una barra di scorrimento orizzontale per contenuti non esenti. Se appare, la pagina non supera il test. Confermare che tutto il testo sia completamente leggibile — nessuna frase è tagliata, nessun carattere è troncato dal margine del viewport.
4. Testare tutta la funzionalità interattiva: A 320px di larghezza, tentare di completare ogni attività chiave dell’utente: compilare e inviare moduli, aprire i menu di navigazione, attivare modali e finestre di dialogo, usare accordion e tab, interagire con i caroselli e attivare qualsiasi contenuto dinamico. Ogni controllo deve essere raggiungibile e utilizzabile usando solo lo scorrimento verticale e l’interazione normale.
5. Verificare tutti i template e gli stati di pagina: Testare la homepage, le pagine di contenuto interne, i moduli, i flussi di checkout, gli stati di errore e qualsiasi vista autenticata. Una navigazione responsive che si comprime correttamente sulla homepage può comunque rompersi su una pagina prodotto molto annidata con un template diverso.
6. Abbinamento con screen reader (supplementare): Usare NVDA con Firefox o VoiceOver con Safari a 320px di larghezza per confermare che l’ordine dei contenuti e il significato siano preservati dopo il reflow. A volte il reflow basato su CSS cambia l’ordine visivo senza modificare l’ordine del DOM, rendendo confuse le letture dello screen reader. Questo non è strettamente un test di Reflow, ma intercetta implementazioni di reflow che creano ulteriori problemi di accessibilità.
7. Documentare le esenzioni: Per qualsiasi contenuto che richieda effettivamente lo scorrimento orizzontale (tabelle di dati, mappe, blocchi di codice), verificare e documentare che rientri realmente in un’eccezione definita da WCAG. Confermare che il contenuto circostante della pagina (intestazioni, istruzioni, navigazione) continui a rifluire correttamente anche se il componente incorporato non lo fa.

Come Correggere

Contenitore a larghezza fissa che rompe il layout — Non corretto

<!-- Fixed pixel width forces horizontal scrolling at small viewports -->
<div style='width: 960px; margin: 0 auto;'>
  <p>This content will overflow a 320px viewport and require horizontal scrolling.</p>
  <button>Submit Application</button>
</div>

Contenitore a larghezza fissa che rompe il layout — Corretto

<!-- Use max-width with 100% so container never exceeds its parent but shrinks on small screens -->
<div class='content-wrapper'>
  <p>This content reflows naturally at any viewport width.</p>
  <button>Submit Application</button>
</div>

<!-- In your CSS (external stylesheet) -->
<!-- .content-wrapper { max-width: 960px; width: 100%; margin: 0 auto; box-sizing: border-box; padding: 0 1rem; } -->

Meta tag viewport che blocca lo zoom — Non corretto

<!-- This prevents users from zooming at all, making Reflow impossible to achieve -->
<meta name='viewport' content='width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no'>

Meta tag viewport che blocca lo zoom — Corretto

<!-- Allow zooming by removing maximum-scale and user-scalable restrictions -->
<meta name='viewport' content='width=device-width, initial-scale=1'>
<!-- Users can now zoom to 400% and content will reflow as required by WCAG 1.4.10 -->

Barra di navigazione orizzontale che va in overflow — Non corretto

<!-- Navigation items forced into a single row with no wrapping or collapse mechanism -->
<nav aria-label='Primary navigation'>
  <ul style='display: flex; flex-wrap: nowrap; white-space: nowrap;'>
    <li><a href='/home'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About Us</a></li>
    <li><a href='/contact'>Contact</a></li>
    <li><a href='/blog'>Blog</a></li>
    <li><a href='/support'>Support</a></li>
  </ul>
</nav>

Barra di navigazione orizzontale che va in overflow — Corretto

<!-- Hamburger/disclosure pattern for small viewports; full navigation accessible at all sizes -->
<nav aria-label='Primary navigation'>
  <button aria-expanded='false' aria-controls='nav-menu' id='nav-toggle'>
    Menu
  </button>
  <ul id='nav-menu'>
    <li><a href='/home'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About Us</a></li>
    <li><a href='/contact'>Contact</a></li>
    <li><a href='/blog'>Blog</a></li>
    <li><a href='/support'>Support</a></li>
  </ul>
</nav>
<!-- CSS media query hides #nav-menu by default below a breakpoint and shows it on toggle -->
<!-- The button is hidden above the breakpoint where the full nav is always visible -->

Tabella di dati senza accomodamento per il reflow — Non corretto

<!-- Wide table with no scroll container; overflows the viewport with no warning to users -->
<table>
  <caption>Quarterly Sales Data</caption>
  <thead>
    <tr>
      <th scope='col'>Region</th>
      <th scope='col'>Q1</th>
      <th scope='col'>Q2</th>
      <th scope='col'>Q3</th>
      <th scope='col'>Q4</th>
      <th scope='col'>Total</th>
    </tr>
  </thead>
</table>

Tabella di dati senza accomodamento per il reflow — Corretto

<!-- Wrap the table in a scrollable container scoped to just the table element -->
<!-- This is an explicit WCAG 1.4.10 exception for complex data tables -->
<div role='region' aria-labelledby='table-caption' tabindex='0' class='table-scroll-container'>
  <table>
    <caption id='table-caption'>Quarterly Sales Data (scroll horizontally to view all columns)</caption>
    <thead>
      <tr>
        <th scope='col'>Region</th>
        <th scope='col'>Q1</th>
        <th scope='col'>Q2</th>
        <th scope='col'>Q3</th>
        <th scope='col'>Q4</th>
        <th scope='col'>Total</th>
      </tr>
    </thead>
  </table>
</div>
<!-- CSS: .table-scroll-container { overflow-x: auto; } -->
<!-- The caption warns users, role=region + aria-labelledby makes it keyboard-focusable -->

Errori Comuni

• Usare overflow: hidden su <body> o su un wrapper di alto livello per sopprimere le barre di scorrimento orizzontali senza correggere l’overflow sottostante: Questo nasconde la barra di scorrimento ma il contenuto è comunque tagliato e inaccessibile, il che è probabilmente peggio dell’overflow visibile perché l’utente non ha alcuna indicazione che esista contenuto oltre il margine del viewport.
• Impostare max-scale=1 o user-scalable=no nel meta tag viewport per evitare che un layout mobile “appaia rotto” a zoom elevato: Questo disabilita completamente la possibilità per l’utente di zoomare, il che costituisce sia un fallimento di Reflow sia una violazione di WCAG 1.4.4 Resize Text.
• Applicare white-space: nowrap a contenitori di testo, liste di navigazione o gruppi di pulsanti senza un override specifico per breakpoint: Questo forza il testo su una singola riga indipendentemente dallo spazio disponibile ed è una delle cause più comuni di overflow orizzontale a 320px.
• Usare valori di pixel assoluti nelle definizioni CSS Grid grid-template-columns (ad esempio, grid-template-columns: 300px 600px) senza un fallback responsive: A 320px le due colonne totalizzano 900px e andranno in overflow senza reflow a meno che una media query non sostituisca la definizione con 1fr o 100%.
• Incorporare elementi <iframe> con attributi width e height fissi che puntano a contenuti di terze parti (mappe, video, moduli): Gli iframe non si ridimensionano automaticamente, quindi una mappa incorporata larga 600px andrà in overflow in un viewport di 320px. Avvolgere gli iframe in un contenitore che preservi il rapporto d’aspetto e impostare l’iframe stesso a width: 100%.
• Progettare finestre modali e pannelli off-canvas con una larghezza minima fissa superiore a 320px: Una modale con min-width: 500px andrà in overflow e probabilmente nasconderà il pulsante di chiusura fuori dallo schermo, intrappolando gli utenti da tastiera all’interno della finestra di dialogo a larghezze di viewport ridotte.
• Considerare i blocchi di codice e gli elementi <pre> come esenti da Reflow senza avvolgerli in un contenitore scorrevole orizzontalmente: I blocchi di codice grezzi non sono elencati come eccezione WCAG. Sebbene il contenuto di codice stesso possa essere complesso, la pagina circostante deve rifluire; il blocco di codice dovrebbe scorrere indipendentemente all’interno di un wrapper con overflow-x: auto, non causare lo scorrimento orizzontale dell’intera pagina.
• Dimenticare di testare stati autenticati e dinamici: Molti team testano solo la homepage per utenti non autenticati. Dashboard, pagine profilo utente, moduli multi-step e stati di errore caricati via JavaScript sono spesso costruiti con assunzioni di larghezza fissa e non rispettano Reflow anche quando le pagine di marketing lo rispettano.
• Usare CSS transform: scale() per ridurre visivamente i contenuti invece di implementare un vero layout responsive: Lo scaling riduce la dimensione apparente ma non fa rifluire i contenuti — il testo diventa minuscolo e illeggibile invece di rifluire in una colonna singola leggibile, il che non soddisfa né Reflow né Resize Text.
• Dare per scontato che un design mobile-responsive superi automaticamente Reflow: Il design responsive in genere prende di mira breakpoint a 360px, 768px e 1024px. Il riferimento WCAG di 320px è più stretto della maggior parte dei breakpoint mobile, il che significa che contenuti che appaiono corretti su un telefono piccolo standard possono comunque andare in overflow a 320px. Testare sempre esattamente a 320px, non a una generica dimensione “mobile”.

Relazione con le Normative di Accessibilità della Turchia

La Circolare Presidenziale 2025/10 della Turchia, pubblicata nella Gazzetta Ufficiale n. 32933 il 21 giugno 2025, stabilisce requisiti di accessibilità vincolanti per un’ampia gamma di fornitori di servizi digitali operanti in Turchia. La circolare impone la conformità agli standard internazionali di accessibilità web — con WCAG 2.1 Livello AA come base — per i soggetti interessati. WCAG 2.2 Livello AA, che incorpora tutti i criteri di 2.1 incluso 1.4.10 Reflow, è fortemente incoraggiato ed è lo standard richiesto per ottenere l’Erişilebilirlik Logosu (Logo di Accessibilità) rilasciato dal Ministero della Famiglia e dei Servizi Sociali (Aile ve Sosyal Hizmetler Bakanlığı).

Le tipologie di soggetti coperti dalla Circolare Presidenziale 2025/10 includono istituzioni pubbliche e organi di governo a tutti i livelli, banche e istituzioni finanziarie, ospedali e fornitori di servizi sanitari, società di telecomunicazioni con 200.000 o più abbonati, piattaforme di e-commerce, agenzie di viaggio, società di trasporto private e scuole private autorizzate dal Ministero dell’Istruzione Nazionale (Millî Eğitim Bakanlığı). Per ciascuno di questi settori, l’aspettativa è che tutte le interfacce digitali rivolte al pubblico — siti web, applicazioni web e contenuti web mobile — siano accessibili alle persone con disabilità, incluse quelle che si affidano allo zoom e alla regolazione del viewport per percepire i contenuti.

WCAG 1.4.10 Reflow è particolarmente rilevante nel contesto turco per diversi motivi. In primo luogo, la penetrazione di internet mobile in Turchia è eccezionalmente alta e una parte sostanziale degli utenti accede a servizi governativi, portali bancari e piattaforme di e-commerce tramite browser mobile a livelli di zoom variabili. Un sistema di prenotazione appuntamenti ospedalieri che non rispetta Reflow può impedire a pazienti anziani con ipovisione di prenotare autonomamente le visite — un fallimento diretto sia della legge sull’accessibilità sia della missione di servizio pubblico delle istituzioni interessate. In secondo luogo, il programma Erişilebilirlik Logosu richiede una verifica di conformità che copra tutti i criteri di successo di livello AA; il mancato rispetto del criterio 1.4.10 escluderebbe un sito altrimenti conforme dal ricevere il logo. In terzo luogo, per le società di telecomunicazioni con grandi basi di abbonati, portali self-service accessibili e interfacce di gestione dell’account sono essenziali — una dashboard dell’account a larghezza fissa che va in overflow al 400% di zoom danneggia direttamente gli abbonati con disabilità visive che altrimenti non avrebbero bisogno di recarsi in un negozio fisico o chiamare un servizio di assistenza.

Le organizzazioni che intendono dimostrare la conformità alle normative turche in materia di accessibilità dovrebbero assicurarsi che le loro implementazioni di design responsive siano specificamente validate alla soglia di 320 pixel CSS, che nessun meta tag viewport blocchi lo zoom dell’utente e che tutta la funzionalità interattiva — inclusi i flussi di autenticazione, l’invio di moduli e il download di documenti — rimanga pienamente utilizzabile senza scorrimento orizzontale. Includere i test di Reflow come parte di una traccia di audit di accessibilità documentata sarà essenziale per dimostrare la conformità agli organi di regolamentazione e per mantenere l’idoneità all’Erişilebilirlik Logosu.