WCAG 1.4.10: Przepływ tekstu

Co Oznacza Ta Zasada

WCAG 1.4.10 Reflow to kryterium sukcesu na poziomie AA wprowadzone w WCAG 2.1 i przeniesione do WCAG 2.2. Określa ono, że treść internetowa musi być zdolna do reflow — czyli do reorganizowania się i zmiany rozmiaru — tak, aby pozostała w pełni użyteczna przy szerokości okna widoku równoważnej 320 pikselom CSS, bez konieczności poziomego przewijania przez użytkownika w celu odczytania treści lub interakcji z nią. Punkt odniesienia 320 pikseli CSS odpowiada temu, co użytkownik widzi, gdy ustawi poziom powiększenia przeglądarki na 400% na standardowym ekranie o szerokości 1280px.

Kluczowym wymaganiem jest, aby przy tej ograniczonej szerokości nie dochodziło do utraty informacji ani funkcjonalności. Cały tekst musi pozostać czytelny, wszystkie elementy interaktywne muszą pozostać obsługiwalne, a cała istotna treść musi pozostać widoczna bez wywoływania dwuwymiarowego przewijania. Przewijanie pionowe jest dozwolone — kryterium zabrania jedynie przewijania poziomego dla treści płynącej pionowo (oraz przewijania pionowego dla treści płynącej poziomo, choć to rzadkie). Układ, który zmusza użytkowników do jednoczesnego przewijania w górę–w dół i w lewo–w prawo, aby przeczytać akapit tekstu, nie spełnia tego kryterium.

W3C definiuje wyraźne wyjątki, w których przewijanie dwuwymiarowe jest akceptowalne. Obejmują one treści, w których układ dwuwymiarowy jest niezbędny dla ich użycia i znaczenia: duże tabele danych z wieloma kolumnami, złożone mapy i diagramy geograficzne, odtwarzacze wideo i ich kontrolki, paski narzędzi z wieloma przyciskami akcji ułożonymi obok siebie oraz gry lub interaktywne diagramy wymagające precyzyjnych relacji przestrzennych między elementami. Wyjątki te należy interpretować wąsko — zwolnienie dotyczy samej treści (na przykład komórek tabeli danych), a nie otaczającej nawigacji, nagłówków czy tekstu objaśniającego, który jej towarzyszy.

Strona spełnia to kryterium, jeśli: po powiększeniu przeglądarki do 400% (lub ustawieniu szerokości okna widoku na 320px) treść przepływa do jednej kolumny, nawigacja odpowiednio się zwija lub układa, obrazy zmieniają rozmiar proporcjonalnie, a użytkownik może wykonać wszystko to, co przy domyślnym poziomie powiększenia, używając wyłącznie przewijania pionowego. Strona nie spełnia kryterium, jeśli do przeczytania zdań, dotarcia do przycisków lub skorzystania z jakiejkolwiek treści nieobjętej wyjątkiem wymagane jest przewijanie poziome.

Dlaczego To Ma Znaczenie

Około 2,2 miliarda osób na świecie żyje z jakąś formą upośledzenia wzroku, według Światowej Organizacji Zdrowia. Znaczna część tych osób polega na powiększaniu w przeglądarce, powiększaniu w systemie operacyjnym lub dedykowanym oprogramowaniu powiększającym ekran (takim jak ZoomText czy Windows Magnifier), aby tekst i elementy interfejsu były na tyle duże, by można je było komfortowo postrzegać. Gdy układ „rozsypuje się” przy wysokich poziomach powiększenia — wypychając treść poza ekran lub wymagając przewijania poziomego — użytkownicy ci doświadczają fragmentarycznego czytania, w którym każde zdanie wymaga ruchu „tam i z powrotem”. To nie jest tylko niewygodne; może sprawić, że złożona treść stanie się w praktyce niedostępna.

Rozważ 65-letniego użytkownika z wysiękową postacią zwyrodnienia plamki związanego z wiekiem, który przegląda portal rezerwacji wizyt w tureckim szpitalu przy powiększeniu przeglądarki ustawionym na 300%. Jeśli formularz rezerwacji jest renderowany w kolumnach o stałej szerokości, przycisk „Submit” może zostać całkowicie wypchnięty poza prawą krawędź widocznego obszaru. Użytkownik nie ma możliwości dowiedzieć się, że przycisk istnieje, nie mówiąc już o interakcji z nim. Nie może samodzielnie zarezerwować wizyty. To bezpośredna, konkretna szkoda spowodowana niespełnieniem wymogu Reflow.

Poza osobami z niską ostrością wzroku, Reflow przynosi korzyści szerokiej grupie ludzi. Użytkownicy z niepełnosprawnością ruchową, korzystający z przełączników (switch access) lub urządzeń śledzących ruch głowy, uznają przewijanie poziome za niezwykle trudne lub wręcz niemożliwe do niezawodnego wykonania. Niepełnosprawność poznawcza dotyczy znaczącej części populacji, a badania konsekwentnie pokazują, że wąskie, jednokolumnowe układy — typowe dla dobrze zaimplementowanego Reflow — zmniejszają obciążenie poznawcze i poprawiają zrozumienie czytanego tekstu. Osoby korzystające z urządzeń z małym ekranem lub czytające w trybie podzielonego ekranu również odnoszą bezpośrednie korzyści, nawet jeśli nie mają żadnej niepełnosprawności.

Z technicznego i biznesowego punktu widzenia prawidłowe wdrożenie Reflow niemal całkowicie pokrywa się z budowaniem dobrze zaprojektowanego, responsywnego layoutu. Oznacza to, że zgodność z 1.4.10 naturalnie poprawia użyteczność na urządzeniach mobilnych, zmniejsza współczynnik odrzuceń i pozytywnie wpływa na wskaźniki Core Web Vitals, które oddziałują na pozycjonowanie w wyszukiwarkach. W szczególności dla tureckich platform e-commerce, gdzie ruch mobilny dominuje, zgodność z Reflow i komercyjna optymalizacja mobilna są w praktyce tym samym celem.

Powiązane Reguły Axe-core

WCAG 1.4.10 Reflow wymaga ręcznego testowania, a nie automatycznego skanowania. Żadna reguła axe-core nie może w pełni zautomatyzować wykrywania naruszeń Reflow, ponieważ kryterium zależy od wizualnego i funkcjonalnego zachowania całego renderowanego układu przy określonym rozmiarze okna widoku — co wymaga prawdziwego środowiska przeglądarki, ludzkiej oceny przewijalności i weryfikacji, że nie doszło do utraty informacji. Narzędzia automatyczne nie są w stanie wiarygodnie odróżnić zamierzonego przewijania dwuwymiarowego (dla mapy lub tabeli objętej wyjątkiem) od niezamierzonego przepełnienia układu spowodowanego kontenerem o stałej szerokości.

• Test ręczny — szerokość okna widoku 320px: Zmień rozmiar okna przeglądarki dokładnie do 320 pikseli CSS szerokości (lub powiększ do 400% na ekranie o szerokości 1280px) i przewiń pionowo przez każdy szablon strony, stan ekranu i komponent interaktywny. Zweryfikuj, że żadna treść nie jest obcięta, nie pojawia się poziomy pasek przewijania dla treści nieobjętej wyjątkiem, a cała funkcjonalność pozostaje dostępna. Axe DevTools oznaczy to jako element „Wymaga przeglądu” zamiast automatycznego naruszenia, ponieważ analiza układu oparta na narzędziu nie może określić, czy przepełnienie stanowi rzeczywiste naruszenie, czy mieści się w wyjątku.
• Zautomatyzowany sygnał częściowy — sprawdzenie meta tagu viewport: Axe-core może wykryć, czy strona używa tagu meta name='viewport' z user-scalable=no lub maximum-scale=1, które uniemożliwiają użytkownikom jakiekolwiek powiększanie, a tym samym uniemożliwiają osiągnięcie stanu 400% powiększenia, do którego odnosi się Reflow. Choć technicznie jest to osobny problem (WCAG 1.4.4), jest on ściśle powiązany, a jego występowanie gwarantuje naruszenie Reflow. Axe oznacza to w ramach reguły meta-viewport. Każda strona, która blokuje powiększanie, z definicji blokuje również zgodność z Reflow.
• Ręczny audyt komponentów: Poza układem całej strony, poszczególne komponenty, takie jak karuzele, przyklejone nagłówki, okna modalne, pływające widżety czatu, banery cookie i tabele danych, wymagają indywidualnej weryfikacji przy 320px. Nagłówek strony może poprawnie się przeorganizowywać, podczas gdy promocyjne okno modalne renderuje się ze stałą szerokością 600px i niedostępnym przyciskiem zamknięcia — to naruszenie, które zostanie wychwycone tylko przez ręczny przegląd komponent po komponencie.

Jak Testować

1. Zautomatyzowany skan wstępny: Uruchom axe DevTools lub Lighthouse w Chrome DevTools dla każdej strony. Szukaj w szczególności naruszenia meta-viewport, które wskazuje, że powiększanie jest zablokowane i gwarantuje naruszenie Reflow. Zwróć też uwagę na wszelkie ostrzeżenia związane z przepełnieniem oznaczone jako „Wymaga przeglądu”. Zapisz wyniki, ale pamiętaj, że czysty skan automatyczny nie potwierdza zgodności z Reflow — kroki ręczne są obowiązkowe.
2. Ustaw okno widoku na 320px: W Chrome lub Firefox DevTools otwórz pasek narzędzi urządzeń (Ctrl+Shift+M / Cmd+Shift+M), wprowadź niestandardowy rozmiar urządzenia 320×568 pikseli (lub dowolną wysokość) i ustaw współczynnik pikseli urządzenia na 1. Alternatywnie otwórz okno przeglądarki o szerokości 1280px i powiększ do 400% za pomocą Ctrl+= (Cmd+= na Macu). Obie metody symulują warunek 320 pikseli CSS określony przez WCAG.
3. Przewiń pionowo przez całą stronę: Zaczynając od góry strony, przewijaj w dół, używając wyłącznie pionowego paska przewijania lub kółka myszy. W żadnym momencie nie powinien pojawić się poziomy pasek przewijania dla treści nieobjętej wyjątkiem. Jeśli się pojawi, strona nie spełnia kryterium. Potwierdź, że cały tekst jest w pełni czytelny — żadne zdania nie są ucięte, żadne znaki nie są obcięte przez krawędź okna widoku.
4. Przetestuj całą funkcjonalność interaktywną: Przy szerokości 320px spróbuj wykonać każde kluczowe zadanie użytkownika: wypełnij i wyślij formularze, otwórz menu nawigacyjne, aktywuj okna modalne i dialogi, używaj akordeonów i kart, wchodź w interakcje z karuzelami i wywołuj wszelkie treści dynamiczne. Każdy element sterujący musi być osiągalny i obsługiwalny przy użyciu wyłącznie przewijania pionowego i normalnej interakcji.
5. Sprawdź wszystkie szablony i stany stron: Przetestuj stronę główną, wewnętrzne strony z treścią, formularze, procesy zakupowe, stany błędów oraz wszelkie widoki wymagające uwierzytelnienia. Responsywna nawigacja, która poprawnie się zwija na stronie głównej, może nadal się „psuć” na głęboko zagnieżdżonej stronie produktu z innym szablonem.
6. Parowanie z czytnikiem ekranu (uzupełniająco): Użyj NVDA z Firefoxem lub VoiceOver z Safari przy szerokości 320px, aby potwierdzić, że kolejność treści i znaczenie są zachowane po reflow. Czasami reflow oparty na CSS zmienia kolejność wizualną bez zmiany kolejności w DOM, co powoduje, że komunikaty czytnika ekranu stają się mylące. Nie jest to ściśle test Reflow, ale pozwala wychwycić implementacje reflow, które tworzą inne problemy z dostępnością.
7. Udokumentuj wyjątki: Dla każdej treści, która rzeczywiście wymaga przewijania poziomego (tabele danych, mapy, bloki kodu), zweryfikuj i udokumentuj, że rzeczywiście mieści się w wyjątku zdefiniowanym przez WCAG. Potwierdź, że otaczająca treść strony (nagłówki, instrukcje, nawigacja) nadal prawidłowo się reorganizuje, nawet jeśli osadzony komponent tego nie robi.

Jak Naprawić

Kontener o stałej szerokości psujący układ — Nieprawidłowe

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

Kontener o stałej szerokości psujący układ — Prawidłowe

<!-- 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 blokujący powiększanie — Nieprawidłowe

<!-- 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 blokujący powiększanie — Prawidłowe

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

Poziomy pasek nawigacyjny powodujący przepełnienie — Nieprawidłowe

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

Poziomy pasek nawigacyjny powodujący przepełnienie — Prawidłowe

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

Tabela danych bez dostosowania do reflow — Nieprawidłowe

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

Tabela danych bez dostosowania do reflow — Prawidłowe

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

Typowe Błędy

• Używanie overflow: hidden na elemencie <body> lub kontenerze najwyższego poziomu, aby ukryć poziome paski przewijania bez naprawy źródłowego przepełnienia: Ukrywa to pasek przewijania, ale treść nadal jest obcięta i niedostępna, co jest prawdopodobnie gorsze niż widoczne przepełnienie, ponieważ użytkownik nie ma żadnej wskazówki, że treść istnieje poza krawędzią okna widoku.
• Ustawianie max-scale=1 lub user-scalable=no w meta tagu viewport, aby zapobiec „psuciu się” układu mobilnego przy wysokim powiększeniu: To całkowicie wyłącza możliwość powiększania przez użytkownika, co jest zarówno naruszeniem Reflow, jak i naruszeniem WCAG 1.4.4 Resize Text.
• Stosowanie white-space: nowrap do kontenerów tekstu, list nawigacyjnych lub grup przycisków bez nadpisania zależnego od breakpointu: Wymusza to umieszczenie tekstu w jednym wierszu niezależnie od dostępnej przestrzeni i jest jedną z najczęstszych przyczyn przepełnienia poziomego przy 320px.
• Używanie bezwzględnych wartości pikselowych w definicjach CSS Grid grid-template-columns (np. grid-template-columns: 300px 600px) bez responsywnego rozwiązania zapasowego: Przy 320px dwie kolumny mają łącznie 900px i spowodują przepełnienie bez reflow, chyba że zapytanie medialne zastąpi definicję na 1fr lub 100%.
• Osadzanie elementów <iframe> ze stałymi atrybutami width i height wskazującymi na treści zewnętrzne (mapy, wideo, formularze): Iframe’y nie skalują się automatycznie, więc osadzona mapa o szerokości 600px spowoduje przepełnienie okna widoku 320px. Owiń iframe w kontener zachowujący proporcje i ustaw sam iframe na width: 100%.
• Projektowanie okien modalnych i paneli wysuwanych spoza ekranu z minimalną szerokością większą niż 320px: Okno modalne z min-width: 500px spowoduje przepełnienie i prawdopodobnie ukryje przycisk zamknięcia poza ekranem, uwięziwszy użytkowników klawiatury w dialogu przy małych szerokościach okna widoku.
• Traktowanie bloków kodu i elementów <pre> jako zwolnionych z Reflow bez opakowania ich w poziomo przewijalny kontener: Surowe bloki kodu nie są wymienione jako wyjątek WCAG. Choć sama treść kodu może być złożona, otaczająca strona musi się reorganizować; blok kodu powinien przewijać się niezależnie w obudowie z overflow-x: auto, a nie powodować poziome przewijanie całej strony.
• Zapominanie o testowaniu stanów uwierzytelnionych i dynamicznych: Wiele zespołów testuje tylko wylogowaną stronę główną. Pulpity, strony profilu użytkownika, wieloetapowe formularze i stany błędów ładowane przez JavaScript są często budowane z założeniami o stałej szerokości i nie spełniają Reflow, nawet gdy strony marketingowe przechodzą testy.
• Używanie CSS transform: scale() do wizualnego zmniejszania treści zamiast wdrożenia prawdziwego responsywnego układu: Skalowanie zmniejsza pozorny rozmiar, ale nie powoduje reflow treści — tekst staje się mały i nieczytelny zamiast przepływać do czytelnej jednokolumnowej formy, co narusza zarówno kryteria Reflow, jak i Resize Text.
• Zakładanie, że projekt responsywny automatycznie spełnia Reflow: Projekt responsywny zazwyczaj celuje w breakpointy 360px, 768px i 1024px. Punkt odniesienia WCAG 320px jest węższy niż większość breakpointów mobilnych, co oznacza, że treść, która wygląda poprawnie na standardowym małym telefonie, może nadal powodować przepełnienie przy 320px. Zawsze testuj dokładnie przy 320px, a nie przy ogólnym rozmiarze „mobilnym”.

Związek z Tureckimi Regulacjami Dotyczącymi Dostępności

Turecka Okólnik Prezydencki 2025/10, opublikowana w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia wiążące wymagania dotyczące dostępności dla szerokiej grupy dostawców usług cyfrowych działających w Turcji. Okólnik nakazuje zgodność z międzynarodowymi standardami dostępności stron internetowych — przy czym WCAG 2.1 poziom AA stanowi punkt wyjścia — dla podmiotów objętych regulacją. WCAG 2.2 poziom AA, który obejmuje wszystkie kryteria 2.1, w tym 1.4.10 Reflow, jest zdecydowanie zalecany i jest standardem wymaganym do uzyskania Erişilebilirlik Logosu (Logotypu Dostępności) wydawanego przez Ministerstwo Rodziny i Usług Społecznych (Aile ve Sosyal Hizmetler Bakanlığı).

Typy podmiotów objętych Okólnikiem Prezydenckim 2025/10 obejmują instytucje publiczne i organy rządowe na wszystkich szczeblach, banki i instytucje finansowe, szpitale i świadczeniodawców opieki zdrowotnej, firmy telekomunikacyjne z 200 000 lub większą liczbą abonentów, platformy e-commerce, biura podróży, prywatne firmy transportowe oraz szkoły niepubliczne upoważnione przez Ministerstwo Edukacji Narodowej (Millî Eğitim Bakanlığı). Dla każdego z tych sektorów oczekuje się, że wszystkie publicznie dostępne interfejsy cyfrowe — strony internetowe, aplikacje webowe i treści mobilne w sieci — będą dostępne dla osób z niepełnosprawnościami, w tym dla tych, które polegają na powiększaniu i dostosowywaniu okna widoku, aby postrzegać treść.

WCAG 1.4.10 Reflow ma szczególne znaczenie w tureckim kontekście z kilku powodów. Po pierwsze, penetracja internetu mobilnego w Turcji jest wyjątkowo wysoka, a znaczna część użytkowników uzyskuje dostęp do usług rządowych, portali bankowych i platform e-commerce za pośrednictwem przeglądarek mobilnych przy różnych poziomach powiększenia. System rezerwacji wizyt w szpitalu, który nie spełnia Reflow, może uniemożliwić starszym pacjentom z niską ostrością wzroku samodzielne umawianie konsultacji — co stanowi bezpośrednie naruszenie zarówno prawa dotyczącego dostępności, jak i misji świadczenia usług publicznych przez instytucje objęte regulacją. Po drugie, program Erişilebilirlik Logosu wymaga audytu zgodności obejmującego wszystkie kryteria sukcesu na poziomie AA; niespełnienie 1.4.10 zdyskwalifikowałoby w inny sposób zgodną stronę z otrzymania logotypu. Po trzecie, dla firm telekomunikacyjnych z dużą bazą abonentów dostępne portale samoobsługowe i interfejsy zarządzania kontem są kluczowe — pulpit konta o stałej szerokości, który powoduje przepełnienie przy powiększeniu 400%, bezpośrednio szkodzi abonentom z niepełnosprawnością wzroku, którzy w przeciwnym razie nie musieliby odwiedzać fizycznego salonu ani dzwonić na infolinię.

Organizacje dążące do wykazania zgodności z tureckimi regulacjami dotyczącymi dostępności powinny upewnić się, że ich implementacje projektów responsywnych są w sposób szczególny weryfikowane przy progu 320 pikseli CSS, że żadne meta tagi viewport nie blokują powiększania przez użytkownika oraz że cała funkcjonalność interaktywna — w tym procesy uwierzytelniania, wysyłanie formularzy i pobieranie dokumentów — pozostaje w pełni obsługiwalna bez przewijania poziomego. Uwzględnienie testów Reflow jako części udokumentowanego śladu audytu dostępności będzie kluczowe dla wykazania zgodności przed organami regulacyjnymi i dla utrzymania kwalifikacji do Erişilebilirlik Logosu.