WCAG 1.4.10: Omflöde

Vad den här regeln innebär

WCAG 1.4.10 Reflow är ett framgångskriterium på nivå AA som introducerades i WCAG 2.1 och fördes vidare till WCAG 2.2. Det anger att webbinnehåll måste kunna omflöda – det vill säga organisera om och ändra storlek på sig självt – så att det förblir fullt användbart vid en visningsfönsterbredd motsvarande 320 CSS-pixlar, utan att användaren behöver skrolla horisontellt för att läsa eller interagera med innehållet. Referenspunkten 320 CSS-pixlar motsvarar vad en användare ser när hen ställer in webbläsarens zoomnivå på 400% på en standarddisplay med 1280px bredd.

Kärnkravet är att ingen information eller funktionalitet får gå förlorad vid denna begränsade bredd. All text måste förbli läsbar, alla interaktiva kontroller måste förbli användbara och allt meningsfullt innehåll måste förbli synligt utan att utlösa tvådimensionell skrollning. Vertikal skrollning är tillåten – kriteriet förbjuder endast horisontell skrollning för vertikalt flödande innehåll (och vertikal skrollning för horisontellt flödande innehåll, även om detta är ovanligt). En layout som tvingar användare att skrolla både upp-och-ner och vänster-och-höger samtidigt för att läsa ett stycke text skulle inte uppfylla detta kriterium.

W3C definierar uttryckliga undantag där tvådimensionell skrollning är acceptabel. Dessa inkluderar innehåll där tvådimensionell layout är väsentlig för dess användning och betydelse: stora datatabeller med många kolumner, komplexa kartor och geografiska diagram, videospelare och deras uppspelningskontroller, verktygsfält med flera åtgärdsknappar placerade sida vid sida samt spel eller interaktiva diagram som kräver en exakt rumslig relation mellan element. Dessa undantag måste tolkas snävt – undantaget gäller själva innehållet (till exempel cellerna i en datatabell), inte den omgivande navigeringen, rubrikerna eller den förklarande text som åtföljer det.

En sida klarar detta kriterium om: när webbläsaren är inzoomad till 400% (eller visningsfönstret är inställt på 320px bredd), omflödar innehållet till en enda kolumn, navigeringen fälls ihop eller staplas på ett lämpligt sätt, bilder ändrar storlek proportionerligt och användaren kan utföra allt hen kunde på standardzoomnivån med enbart vertikal skrollning. En sida misslyckas om horisontell skrollning krävs för att läsa meningar, nå knappar eller komma åt något icke-undantaget innehåll.

Varför det är viktigt

Enligt Världshälsoorganisationen lever cirka 2,2 miljarder människor världen över med någon form av synnedsättning. En betydande andel av dessa personer är beroende av webbläsarzoom, operativsystemets förstoringsfunktioner eller dedikerad skärmförstoringsprogramvara (såsom ZoomText eller Windows Förstoringsglas) för att göra text och gränssnittselement tillräckligt stora för att uppfattas bekvämt. När en layout bryts vid höga zoomnivåer – så att innehåll hamnar utanför skärmen eller kräver horisontell skrollning – möter dessa användare en fragmenterad läsupplevelse där varje mening kräver en fram-och-tillbaka-panoreringsrörelse. Detta är inte bara obekvämt; det kan göra komplext innehåll i praktiken oåtkomligt.

Föreställ dig en 65-årig användare med åldersrelaterad makuladegeneration som besöker en turkisk sjukhusportals bokningssystem med webbläsaren inställd på 300% zoom. Om bokningsformuläret renderas med kolumner i fast bredd kan knappen ”Skicka” tryckas helt utanför den synliga ytan till höger. Användaren har ingen möjlighet att veta att knappen finns, än mindre interagera med den. Hen kan inte boka sin tid självständigt. Detta är en direkt, konkret skada som orsakas av att inte uppfylla Reflow.

Utöver användare med nedsatt syn gynnar Reflow en bred grupp människor. Användare med motoriska funktionsnedsättningar som använder switch-styrning eller huvudspårningsenheter upplever horisontell skrollning som extremt svår eller omöjlig att utföra på ett tillförlitligt sätt. Kognitiva funktionsnedsättningar påverkar en betydande del av befolkningen, och forskning visar konsekvent att smala, enkolumnslayouter – typiska för väl implementerad Reflow – minskar kognitiv belastning och förbättrar läsförståelsen. Personer som använder enheter med små skärmar eller läser i delat skärmläge gynnas också direkt, även utan någon funktionsnedsättning.

Ur ett tekniskt och affärsmässigt perspektiv överlappar korrekt implementering av Reflow nästan helt med att bygga en välstrukturerad responsiv design. Detta innebär att efterlevnad av 1.4.10 naturligt förbättrar mobilanvändbarhet, minskar avvisningsfrekvensen och bidrar positivt till Core Web Vitals-mått som påverkar sökmotorrankningar. För turkiska e-handelsplattformar i synnerhet, där mobiltrafik dominerar, är Reflow-efterlevnad och kommersiell mobiloptimering i praktiken samma mål.

Relaterade Axe-core-regler

WCAG 1.4.10 Reflow kräver manuell testning snarare än automatiserad skanning. Ingen axe-core-regel kan fullt ut automatisera upptäckten av Reflow-fel eftersom kriteriet beror på det visuella och funktionella beteendet hos en hel renderad layout vid en specifik visningsfönsterstorlek – något som kräver en verklig webbläsarmiljö, mänsklig bedömning av skrollbarhet och verifiering av att ingen information har gått förlorad. Automatiserade verktyg kan inte pålitligt skilja mellan avsiktlig tvådimensionell skrollning (för en undantagen karta eller tabell) och en oavsiktlig layoutöversvämning orsakad av en behållare med fast bredd.

• Manuellt test – 320px visningsfönsterbredd: Ändra webbläsarens visningsfönster till exakt 320 CSS-pixlar brett (eller zooma till 400% på en skärm med 1280px bredd) och skrolla vertikalt genom varje sidmall, skärmtillstånd och interaktiv komponent. Verifiera att inget innehåll klipps av, att ingen horisontell skrollist visas för icke-undantaget innehåll och att all funktionalitet förblir åtkomlig. Axe DevTools markerar detta som ett ”Needs Review”-objekt snarare än en automatisk överträdelse, eftersom verktygsbaserad layoutanalys inte kan avgöra om översvämningen representerar ett verkligt fel eller faller under ett undantag.
• Automatiserad partiell signal – kontroll av viewport meta-taggen: Axe-core kan upptäcka om sidan använder en meta name='viewport'-tagg med user-scalable=no eller maximum-scale=1, vilka båda hindrar användare från att zooma över huvud taget och därmed gör det omöjligt att nå 400%-zoomtillståndet som Reflow kräver. Även om detta tekniskt sett är ett separat problem (WCAG 1.4.4), är det nära relaterat och dess förekomst garanterar ett Reflow-fel. Axe flaggar detta under regeln meta-viewport. Varje sida som blockerar zoom blockerar också Reflow-efterlevnad per definition.
• Manuell komponentgranskning: Utöver layouten för hela sidan kräver enskilda komponenter såsom karuseller, klistriga sidhuvuden, modala dialoger, flytande chattwidgetar, cookie-banners och datatabeller var och en individuell verifiering vid 320px. Ett sidhuvud kan omflöda korrekt medan en kampanjmodal renderas med en fast bredd på 600px och en oåtkomlig stängknapp – ett fel som endast en manuell komponent-för-komponent-granskning kommer att upptäcka.

Hur man testar

1. Automatiserad förskanning: Kör axe DevTools eller Lighthouse i Chrome DevTools mot varje sida. Leta specifikt efter överträdelsen meta-viewport, som indikerar att zoom är blockerad och garanterar ett Reflow-fel. Notera också eventuella översvämningsrelaterade varningar som flaggas under ”Needs Review”. Dokumentera resultaten men förstå att en ren automatiserad skanning inte bekräftar Reflow-efterlevnad – manuella steg är obligatoriska.
2. Ställ in visningsfönstret på 320px: Öppna enhetspanelen (Ctrl+Shift+M / Cmd+Shift+M) i Chrome eller Firefox DevTools, ange en anpassad enhetsstorlek på 320×568 pixlar (eller valfri höjd) och ställ in enhetspixelkvoten på 1. Alternativt kan du öppna ett webbläsarfönster med 1280px bredd och zooma till 400% med Ctrl+= (Cmd+= på Mac). Båda metoderna simulerar det tillstånd med 320 CSS-pixlar som anges av WCAG.
3. Skrolla vertikalt genom hela sidan: Börja från sidans topp och skrolla nedåt endast med den vertikala skrollisten eller mushjulet. Vid inget tillfälle ska en horisontell skrollist visas för icke-undantaget innehåll. Om det sker misslyckas sidan. Bekräfta att all text är fullt läsbar – inga meningar är avskurna, inga tecken klipps av vid visningsfönstrets kant.
4. Testa all interaktiv funktionalitet: Försök vid 320px bredd att utföra varje viktig användaruppgift: fyll i och skicka formulär, öppna navigationsmenyer, aktivera modaler och dialoger, använda dragspel och flikar, interagera med karuseller och utlösa allt dynamiskt innehåll. Varje kontroll måste vara nåbar och användbar med enbart vertikal skrollning och normal interaktion.
5. Kontrollera alla sidmallar och tillstånd: Testa startsidan, interna innehållssidor, formulär, kassaflöden, felmeddelanden och alla autentiserade vyer. En responsiv navigering som fälls ihop korrekt på startsidan kan ändå brytas på en djupt inbäddad produktsida med en annan mall.
6. Parning med skärmläsare (kompletterande): Använd NVDA med Firefox eller VoiceOver med Safari vid 320px bredd för att bekräfta att innehållsordning och betydelse bevaras efter omflöde. Ibland ändrar CSS-baserat omflöde den visuella ordningen utan att ändra DOM-ordningen, vilket gör skärmläsarens uppläsning förvirrande. Detta är inte strikt ett Reflow-test, men det fångar Reflow-implementationer som skapar separata tillgänglighetsproblem.
7. Dokumentera undantag: För allt innehåll som kräver horisontell skrollning (datatabeller, kartor, kodblock), verifiera och dokumentera att det verkligen faller under ett WCAG-definierat undantag. Bekräfta att det omgivande sidinnehållet (rubriker, instruktioner, navigering) fortfarande omflödar korrekt även om den inbäddade komponenten inte gör det.

Hur man åtgärdar

Behållare med fast bredd som bryter layouten – Felaktigt

<!-- 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>

Behållare med fast bredd som bryter layouten – Korrekt

<!-- 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; } -->

Viewport-meta-tagg som blockerar zoom – Felaktigt

<!-- 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'>

Viewport-meta-tagg som blockerar zoom – Korrekt

<!-- 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 -->

Horisontell navigationsrad som flödar över – Felaktigt

<!-- 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>

Horisontell navigationsrad som flödar över – Korrekt

<!-- 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 -->

Datatabell utan omflödesanpassning – Felaktigt

<!-- 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>

Datatabell utan omflödesanpassning – Korrekt

<!-- 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 -->

Vanliga misstag

• Att använda overflow: hidden på <body> eller en toppnivåbehållare för att dölja horisontella skrollister utan att åtgärda den underliggande översvämningen: Detta döljer skrollisten men innehållet är fortfarande avklippt och oåtkomligt, vilket är möjligen värre än synlig översvämning eftersom användaren inte har någon indikation på att innehåll finns bortom visningsfönstrets kant.
• Att sätta max-scale=1 eller user-scalable=no i viewport-meta-taggen för att förhindra att en mobillayout ”ser trasig ut” vid hög zoom: Detta inaktiverar användarens möjlighet att zooma helt, vilket både är ett Reflow-fel och ett brott mot WCAG 1.4.4 Resize Text.
• Att tillämpa white-space: nowrap på textbehållare, navigationslistor eller knappgrupper utan en brytpunktspecifik överskrivning: Detta tvingar text på en enda rad oavsett tillgängligt utrymme och är en av de vanligaste orsakerna till horisontell översvämning vid 320px.
• Att använda absoluta pixelvärden i CSS Grid-grid-template-columns-definitioner (t.ex. grid-template-columns: 300px 600px) utan en responsiv reservlösning: Vid 320px blir de två kolumnerna totalt 900px och kommer att flöda över utan omflöde om inte en media query ersätter definitionen med 1fr eller 100%.
• Att bädda in <iframe>-element med fasta attributen width och height som pekar på tredjepartsinnehåll (kartor, videor, formulär): Iframes skalas inte automatiskt, så en inbäddad karta på 600px bredd kommer att flöda över ett visningsfönster på 320px. Omslut iframes i en behållare som bevarar bildförhållandet och sätt själva iframen till width: 100%.
• Att utforma modala dialoger och off-canvas-paneler med en fast minsta bredd större än 320px: En modal med min-width: 500px kommer att flöda över och sannolikt dölja sin stängknapp utanför skärmen, vilket kan få tangentbordsanvändare att fastna i dialogen vid små visningsfönsterbredder.
• Att behandla kodblock och <pre>-element som undantagna från Reflow utan att omsluta dem i en horisontellt skrollbar behållare: Råa kodblock listas inte som ett WCAG-undantag. Även om själva kodinnehållet kan vara komplext måste den omgivande sidan omflöda; kodblocket ska skrolla oberoende inom en overflow-x: auto-behållare, inte orsaka att hela sidan skrollar horisontellt.
• Att glömma att testa autentiserade och dynamiska tillstånd: Många team testar endast den utloggade startsidan. Instrumentpaneler, användarprofilsidor, flerstegsformulär och felmeddelanden som laddas via JavaScript byggs ofta med antaganden om fast bredd och misslyckas med Reflow även när marknadssidorna klarar det.
• Att använda CSS-transform: scale() för att visuellt krympa innehåll i stället för att implementera en verkligt responsiv layout: Skalning minskar den upplevda storleken men omflödar inte innehållet – text blir liten och oläslig i stället för att omflöda till en läsbar enkolumnslayout, vilket misslyckas både med Reflow och Resize Text-kriterierna.
• Att anta att en mobilresponsiv design automatiskt klarar Reflow: Responsiv design riktar sig vanligtvis mot brytpunkter vid 360px, 768px och 1024px. WCAG:s referenspunkt på 320px är smalare än de flesta mobilbrytpunkter, vilket innebär att innehåll som ser korrekt ut på en standardtelefon med liten skärm ändå kan flöda över vid 320px. Testa alltid exakt vid 320px, inte vid en generell ”mobil”-storlek.

Relation till Turkiets tillgänglighetsreglering

Turkiets Presidential Circular 2025/10, publicerad i den officiella tidningen med nummer 32933 den 21 juni 2025, fastställer bindande tillgänglighetskrav för ett brett spektrum av digitala tjänsteleverantörer som är verksamma i Turkiet. Cirkuläret kräver efterlevnad av internationella standarder för webbtillgänglighet – med WCAG 2.1 nivå AA som baslinje – för berörda aktörer. WCAG 2.2 nivå AA, som inkluderar alla 2.1-kriterier inklusive 1.4.10 Reflow, uppmuntras starkt och är standarden som krävs för att erhålla Erişilebilirlik Logosu (Tillgänglighetslogotypen) som utfärdas av Familje- och socialministeriet (Aile ve Sosyal Hizmetler Bakanlığı).

De aktörstyper som omfattas av Presidential Circular 2025/10 inkluderar offentliga institutioner och statliga organ på alla nivåer, banker och finansiella institutioner, sjukhus och vårdgivare, telekommunikationsföretag med 200 000 eller fler abonnenter, e-handelsplattformar, resebyråer, privata transportföretag och privatskolor som auktoriserats av utbildningsministeriet (Millî Eğitim Bakanlığı). För var och en av dessa sektorer är förväntningen att alla publika digitala gränssnitt – webbplatser, webbapplikationer och mobilt webbinnehåll – ska vara tillgängliga för personer med funktionsnedsättning, inklusive dem som är beroende av zoom och justering av visningsfönstret för att uppfatta innehåll.

WCAG 1.4.10 Reflow är särskilt relevant i turkiskt sammanhang av flera skäl. För det första är mobil internetpenetration i Turkiet exceptionellt hög, och en betydande del av användarna får tillgång till offentliga tjänster, bankportaler och e-handelsplattformar via mobilwebbläsare på varierande zoomnivåer. Ett system för sjukhusbokningar som inte klarar Reflow kan hindra äldre patienter med nedsatt syn från att självständigt boka konsultationer – ett direkt misslyckande både med tillgänglighetslagstiftningen och med de offentliga institutionernas serviceuppdrag. För det andra kräver programmet Erişilebilirlik Logosu en efterlevnadsrevision som omfattar alla framgångskriterier på nivå AA; att misslyckas med 1.4.10 skulle diskvalificera en i övrigt kompatibel webbplats från att få logotypen. För det tredje är tillgängliga självbetjäningsportaler och gränssnitt för kontohantering avgörande för telekommunikationsföretag med stora abonnentbaser – en kontopanel med fast bredd som flödar över vid 400% zoom skadar direkt abonnenter med synnedsättning som annars inte skulle behöva besöka en fysisk butik eller ringa en supportlinje.

Organisationer som vill visa efterlevnad enligt turkiska tillgänglighetsregler bör säkerställa att deras responsiva designimplementationer specifikt valideras vid tröskeln 320 CSS-pixlar, att inga viewport-meta-taggar blockerar användarzoom och att all interaktiv funktionalitet – inklusive autentiseringsflöden, formulärinlämningar och dokumentnedladdningar – förblir fullt användbar utan horisontell skrollning. Att inkludera Reflow-testning som en del av en dokumenterad tillgänglighetsrevisionskedja kommer att vara avgörande för att visa efterlevnad för tillsynsmyndigheter och för att upprätthålla behörighet för Erişilebilirlik Logosu.