WCAG 1.4.4: Zmiana rozmiaru tekstu

Co Oznacza Ta Zasada

WCAG 1.4.4 Resize Text (Poziom AA) stanowi, że tekst musi dać się powiększyć do 200 procent bez użycia technologii asystujących i bez utraty treści lub funkcjonalności. Mówiąc prościej: gdy użytkownik powiększa widok przeglądarki do 200% lub zwiększa bazowy rozmiar czcionki w ustawieniach przeglądarki albo systemu operacyjnego, cały tekst na stronie musi pozostać czytelny, a cała funkcjonalność musi pozostać nienaruszona.

Kryterium ma szerokie zastosowanie do całego tekstu renderowanego na stronie internetowej, w tym treści głównej, nagłówków, etykiet, tekstu na przyciskach, tekstu zastępczego w polach formularzy, linków nawigacyjnych, treści tabel oraz podpisów. Nie dotyczy tekstu będącego częścią logo lub nazwy marki ani tekstu dekoracyjnego, który nie przekazuje informacji i jest prezentowany wyłącznie jako treść graficzna (na przykład zeskanowana fotografia odręcznej notatki, w której sam tekst nie stanowi dostępnej treści).

Spełnienie kryterium wymaga, aby przy 200% powiększeniu — osiągniętym albo przez wbudowane powiększanie strony w przeglądarce (Ctrl/Cmd + klawisz plus lub menu Widok > Powiększ), albo przez ustawienie minimalnego rozmiaru czcionki w przeglądarce — spełnione były następujące warunki: żaden tekst nie jest przycięty ani ukryty przez swój kontener, żaden tekst nie nachodzi na inny tekst lub elementy interaktywne, przy pełnej szerokości okna nie pojawia się poziomy pasek przewijania (z wyjątkiem treści, które rzeczywiście wymagają dwuwymiarowego przewijania, takich jak mapy czy tabele danych), a wszystkie elementy interaktywne pozostają obsługiwalne.

Niepowodzenie odnotowuje się, gdy sztywne wartości w pikselach blokują możliwość powiększania tekstu, gdy kontenery mają stałe wysokości, które przycinają przepełniający tekst, gdy meta tag viewport używa user-scalable=no lub maximum-scale=1.0, aby zablokować gest szczypania w celu powiększenia na urządzeniach mobilnych, lub gdy JavaScript przechwytuje gesty powiększania, aby uniemożliwić skalowanie. Kryterium jest wyraźnie neutralne technologicznie: niezależnie od tego, czy implementacja używa CSS, tekstu SVG czy tekstu renderowanego na canvasie, liczy się rezultat dla użytkownika. Należy zauważyć, że tekst SVG i tekst renderowany na canvasie są z natury trudne do powiększania i często wymagają dodatkowej pracy inżynierskiej.

Dlaczego To Ma Znaczenie

Według Światowej Organizacji Zdrowia około 2,2 miliarda ludzi na świecie ma jakąś formę zaburzeń widzenia. Wśród nich bardzo duża część doświadcza słabowidzenia — stanu, w którym wzroku nie da się w pełni skorygować okularami lub soczewkami kontaktowymi, ale osoba nie jest całkowicie niewidoma. Użytkownicy słabowidzący rutynowo ustawiają powiększenie przeglądarki na 150%, 200% lub więcej albo konfigurują system operacyjny tak, aby renderował tekst w większym rozmiarze bazowym. Gdy strony internetowe blokują lub zakłócają to zachowanie, ci użytkownicy są całkowicie wykluczeni z dostępu do treści.

Poza zdiagnozowanym słabowidzeniem, czynniki sytuacyjne wpływają w pewnym momencie praktycznie na każdego użytkownika internetu: małe ekrany, jasne światło słoneczne, zmęczenie, starzejący się wzrok czy czytanie w obcym języku mogą sprawić, że mniejszy tekst staje się trudniejszy do odczytania. W szczególności osoby starsze — szybko rosnąca demograficznie grupa na całym świecie i w Turcji — często polegają na powiększaniu jako pierwszej formie udogodnienia dostępności, zanim sięgną po specjalistyczne technologie asystujące.

Rozważmy konkretny scenariusz: pacjent po sześćdziesiątce próbuje odczytać na smartfonie potwierdzenie wizyty online z portalu szpitalnego. Mobilny arkusz stylów szpitala ustawia rozmiar czcionki treści głównej na 12px, używając stałej wartości w pikselach, a meta tag viewport zawiera maximum-scale=1.0. Pacjent próbuje powiększyć gestem szczypania, ale interfejs się blokuje. Nie jest w stanie odczytać daty ani nazwy oddziału na tyle wyraźnie, by mieć pewność. Dzwoni na infolinię szpitala, angażując czas personelu i wywołując u siebie niepokój — to całkowicie możliwy do uniknięcia rezultat, gdyby kryterium zostało spełnione.

Z czysto komercyjnego punktu widzenia dostępne rozmiary tekstu korelują z ogólną poprawą użyteczności, która przynosi korzyści wszystkim użytkownikom. Wyszukiwarki również premiują witryny, które renderują czytelny tekst w normalnych i powiększonych rozmiarach, ponieważ Googlebot ocenia sygnały czytelności jako część Core Web Vitals i czynników rankingowych związanych z doświadczeniem strony. Naprawa problemów z powiększaniem tekstu jednocześnie poprawia więc SEO, zmniejsza obciążenie wsparcia i poszerza potencjalną grupę odbiorców.

Powiązane Reguły Axe-core

WCAG 1.4.4 jest przede wszystkim kryterium wymagającym testów manualnych. Narzędzia automatyczne mogą wskazać wąski zestaw warunków, o których wiadomo, że uniemożliwiają powiększanie tekstu, ale nie są w stanie wiarygodnie zasymulować i ocenić wszystkich rezultatów układu przy 200% powiększeniu. Poniższe warunki to te, które narzędzia automatyczne próbują wykryć i które wymagają ręcznej weryfikacji:

• meta tag viewport blokujący powiększanie (wymagana ręczna kontrola): Axe-core zawiera regułę meta-viewport, która oznacza każdy tag <meta name='viewport'>, który ustawia user-scalable=no lub maximum-scale na wartość 1.0 lub mniejszą. To jedyny scenariusz, w którym w pełni automatyczne wykrycie jest możliwe, ponieważ naruszenie ma charakter deklaratywny i nie zależy od rezultatu układu. Jednak nawet ta reguła nie jest w stanie ustalić, czy witryna używa JavaScriptu do programowego blokowania powiększania, więc ręczna weryfikacja jest zawsze konieczna.
• Stałe rozmiary czcionek w pikselach (wymagana ręczna kontrola): Narzędzia automatyczne mogą raportować, gdy wartości CSS font-size są ustawione w bezwzględnych jednostkach pikselowych (px), a nie w jednostkach względnych (em, rem, % lub jednostkach względem viewportu). Jednak nowoczesne przeglądarki nadpisują bezwzględne rozmiary czcionek w pikselach, gdy użytkownik zmienia domyślny rozmiar czcionki przeglądarki, więc sama wartość w pikselach nie stanowi gwarantowanego naruszenia — zależy to od zachowania przeglądarki i tego, czy witryna respektuje dziedziczenie font-size. Do potwierdzenia rzeczywistego naruszenia konieczna jest ręczna inspekcja stylów obliczonych i wizualna weryfikacja.
• Przepełnienie treści i przycinanie przy 200% powiększeniu (tylko ręcznie): Żadne narzędzie automatyczne nie jest w stanie wiarygodnie wyrenderować strony przy 200% i ocenić, czy cały tekst pozostaje widoczny, a wszystkie elementy interaktywne pozostają obsługiwalne. Wymaga to, aby tester ręcznie ustawił poziom powiększenia przeglądarki, przewinął stronę i zweryfikował każdą sekcję treści. Narzędzia automatyczne nie mają dostępu do stanu renderowania po powiększeniu.
• Tekst w obrazach i na canvasie (tylko ręcznie): Tekst wtopiony w obrazy rastrowe (tagi <img> zawierające zrzuty ekranu tekstu) lub renderowany na elemencie <canvas> nie może być w ogóle powiększany przez przeglądarkę. Narzędzia automatyczne mogą oznaczyć obecność elementów canvas do ręcznego przeglądu, ale nie są w stanie ustalić, czy te elementy canvas zawierają istotny tekst, który użytkownik musi przeczytać.

Jak Testować

1. Najpierw uruchom skan automatyczny. Otwórz stronę w Chrome lub Firefox i uruchom axe DevTools (rozszerzenie przeglądarki) lub Lighthouse (Chrome DevTools, zakładka Lighthouse). Poszukaj w szczególności naruszeń reguły meta-viewport. Jeśli zostaną oznaczone, zanotuj je jako krytyczne naruszenie. Sprawdź też audyt CSS pod kątem deklaracji font-size w jednostkach px, które pojawiają się w ostrzeżeniach axe best-practices.
2. Sprawdź meta tag viewport w kodzie źródłowym. Otwórz DevTools (F12), przejdź do zakładki Elements i wyszukaj meta name='viewport'. Dokładnie odczytaj atrybut content. Jeśli zawiera user-scalable=no, user-scalable=0 lub maximum-scale=1 (lub jakąkolwiek wartość mniejszą niż 2), jest to bezpośrednie naruszenie 1.4.4.
3. Ustaw powiększenie przeglądarki na 200%. W Chrome lub Firefox naciśnij wielokrotnie Ctrl + Plus (Windows/Linux) lub Cmd + Plus (macOS), aż wskaźnik powiększenia przeglądarki pokaże 200%. Alternatywnie przejdź do Widok > Powiększ. W Safari na macOS użyj Widok > Powiększ. Nie używaj skalowania wyświetlacza na poziomie systemu operacyjnego do tego testu — użyj konkretnie powiększenia przeglądarki.
4. Przewiń wszystkie sekcje strony przy 200% powiększeniu. Systematycznie przewijaj od góry do dołu. Szukaj: tekstu, który jest ucięty lub ukryty przez swój kontener, tekstu, który wychodzi poza swoje pole i nachodzi na sąsiednią treść, etykiet formularzy, które znikają za polami, przycisków z uciętym tekstem, rozwijanych menu, które wychodzą poza ekran i nie da się ich przewinąć w całości, oraz okien modalnych, które przekraczają rozmiar viewportu i nie da się ich przewinąć.
5. Przetestuj całą funkcjonalność interaktywną przy 200% powiększeniu. Aktywuj każde menu nawigacyjne, otwórz każde okno modalne, wyślij formularze, wywołaj podpowiedzi (tooltips) i wyskakujące okienka (popovers) oraz wejdź w interakcję z karuzelami lub akordeonami. Zweryfikuj, że wszystkie pozostają w pełni obsługiwalne — nie tylko widoczne.
6. Przetestuj z NVDA + Firefox (Windows). Włącz NVDA i otwórz Firefox przy 200% powiększeniu. Nawiguj za pomocą klawisza Tab i klawiszy strzałek. Potwierdź, że elementy fokusowalne otrzymują fokus, że wskaźniki fokusu są widoczne (pokrywa się to z WCAG 2.4.7, ale warto to sprawdzić) oraz że kolejność odczytu odpowiada kolejności wizualnej przy powiększonym rozmiarze.
7. Przetestuj z VoiceOver + Safari (macOS/iOS). Włącz VoiceOver. Na iOS przejdź do Ustawienia > Dostępność > Wyświetlacz i rozmiar tekstu i włącz Większy tekst (Larger Text). Przejdź tę samą stronę i zweryfikuj integralność treści. Użyj także gestu szczypania w celu powiększenia, aby potwierdzić, że nie jest blokowany.
8. Przetestuj ustawienie minimalnego rozmiaru czcionki w przeglądarce. W Firefox przejdź do Ustawienia > Ogólne > Czcionki i kolory i ustaw minimalny rozmiar czcionki na 24px. Przeładuj stronę i sprawdź, czy cały tekst spełnia to minimum i czy układ się nie psuje. Testuje to inny wektor tego samego kryterium.
9. Przetestuj z JAWS + Chrome (Windows). Otwórz stronę w Chrome przy 200% powiększeniu z aktywnym JAWS. Użyj komend odczytu JAWS (Insert + strzałka w dół, aby czytać od kursora), aby potwierdzić, że cała treść tekstowa jest odczytywana i żadna treść nie jest pomijana z powodu ukrycia przez przycinanie przepełnienia.

Jak Naprawić

Meta tag viewport blokujący powiększanie — Nieprawidłowe

<!-- WRONG: user-scalable=no prevents pinch-to-zoom on mobile,
     directly violating WCAG 1.4.4 -->
<meta name='viewport' content='width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no'>

Meta tag viewport blokujący powiększanie — Prawidłowe

<!-- CORRECT: Remove user-scalable=no and do not cap maximum-scale below 2.
     Allowing zoom to at least 2 (200%) satisfies WCAG 1.4.4. -->
<meta name='viewport' content='width=device-width, initial-scale=1.0'>

Stałe rozmiary czcionek w pikselach — Nieprawidłowe

<!-- WRONG: font-size in px ignores the user's browser font-size preference.
     If the user sets a larger default, px values override that preference. -->
<style>
  body {
    font-size: 14px;
  }
  h1 {
    font-size: 24px;
  }
  .caption {
    font-size: 11px;
  }
</style>
<p>Your appointment is confirmed.</p>

Stałe rozmiary czcionek w pikselach — Prawidłowe

<!-- CORRECT: Use rem units relative to the root font size (typically 16px browser default).
     1rem = 16px by default, but scales with user preference.
     Setting font-size on :root in % rather than px also respects user settings. -->
<style>
  :root {
    font-size: 100%; /* inherits browser default, typically 16px */
  }
  body {
    font-size: 0.875rem; /* ~14px at default, but scales with user preference */
  }
  h1 {
    font-size: 1.5rem; /* ~24px at default */
  }
  .caption {
    font-size: 0.75rem; /* ~12px at default — still scalable */
  }
</style>
<p>Your appointment is confirmed.</p>

Kontenery o stałej wysokości, które przycinają tekst — Nieprawidłowe

<!-- WRONG: A fixed height with overflow:hidden will clip enlarged text.
     At 200% zoom, the text grows but the box does not, hiding content. -->
<style>
  .card {
    height: 120px;
    overflow: hidden;
  }
</style>
<div class='card'>
  <h2>Flight Confirmation</h2>
  <p>Your flight TK0001 to Istanbul departs at 09:30 on 15 July 2025. Gate B12.</p>
</div>

Kontenery o stałej wysokości, które przycinają tekst — Prawidłowe

<!-- CORRECT: Use min-height instead of height so the container grows
     with the content when text is enlarged. -->
<style>
  .card {
    min-height: 7.5rem; /* sets a minimum but allows growth */
    overflow: visible; /* or remove overflow:hidden entirely */
  }
</style>
<div class='card'>
  <h2>Flight Confirmation</h2>
  <p>Your flight TK0001 to Istanbul departs at 09:30 on 15 July 2025. Gate B12.</p>
</div>

Tekst wtopiony w obrazy — Nieprawidłowe

<!-- WRONG: A banner image containing text cannot be resized by the browser.
     Even with alt text, the visual text is inaccessible at high zoom levels. -->
<img src='promo-banner-with-text.jpg' alt='50% indirim — sadece bu hafta sonu'>

Tekst wtopiony w obrazy — Prawidłowe

<!-- CORRECT: Use real HTML text over a background image so the browser
     can resize it. The image is decorative background; text is live HTML. -->
<div class='promo-banner' role='region' aria-label='Promosyon'>
  <p class='promo-text'>50% İndirim &mdash; Sadece Bu Hafta Sonu</p>
</div>
<!-- CSS sets the background image on .promo-banner, while .promo-text
     uses rem font-size and contrasts safely against the background. -->

Typowe Błędy

• Dodawanie user-scalable=no do meta tagu viewport, aby zapobiec „psuciu się układu” na urządzeniach mobilnych — jest to bezpośrednie, mierzalne naruszenie 1.4.4 i nigdy nie może być stosowane. Napraw układ zamiast ograniczać możliwość powiększania po stronie użytkownika.
• Ustawianie maximum-scale=1.0 lub jakiejkolwiek wartości poniżej 2.0 — nawet bez user-scalable=no ograniczenie powiększenia do 1.0 lub 1.5 uniemożliwia użytkownikom osiągnięcie 200% i powoduje niespełnienie kryterium.
• Używanie nasłuchiwaczy zdarzeń JavaScript do wywoływania event.preventDefault() na gestach szczypania lub zdarzeniach kółka myszy — programowe blokowanie natywnego powiększania jest funkcjonalnie równoważne podejściu z meta tagiem viewport i narusza to samo kryterium.
• Ustawianie font-size w pikselach na elemencie <html> lub <body>, a następnie używanie jednostek em dla wszystkiego innego — jeśli bazowy rozmiar czcionki jest ustawiony w px, wszystkie potomne jednostki em/rem są w praktyce również stałe i nie reagują na preferencje użytkownika dotyczące domyślnego rozmiaru czcionki w przeglądarce.
• Używanie height zamiast min-height w komponentach kart, paskach bocznych lub treści okien modalnych — przy 200% powiększeniu powiększony tekst wychodzi poza kontenery o stałej wysokości i jest przycinany przez overflow: hidden, ukrywając kluczową treść.
• Umieszczanie ważnego tekstu wyłącznie wewnątrz elementów <canvas> — tekst renderowany na canvasie jest bitmapą rastrową i nie może być skalowany przez mechanizmy powiększania tekstu lub strony w przeglądarce. Każdy istotny tekst, który użytkownik musi przeczytać, musi być dostępny jako prawdziwy tekst HTML lub przynajmniej jako dostępny tekst alternatywny.
• Używanie elementów SVG <text> z bezwzględnymi współrzędnymi i bez skalowania viewBox — tekst SVG może być skalowalny, gdy SVG używa viewBox i jest rozmiarowany jednostkami względnymi, ale tekst SVG z ustawionymi w pikselach atrybutami x, y, font-size wewnątrz SVG o stałej width i height nie powiększa się wraz z powiększaniem przeglądarki we wszystkich przeglądarkach.
• Zakładanie, że powiększanie w przeglądarce automatycznie spełnia kryterium i pomijanie testów manualnych — powiększanie w przeglądarce skaluje całą stronę, w tym obrazy i układ, ale tekst, który już przy 100% był zbyt mały, przycięty lub nachodzący na inne elementy, staje się większym problemem przy 200%. Ręczna weryfikacja przy powiększeniu jest zawsze wymagana.
• Zapominanie o testowaniu osadzonych widżetów zewnętrznych — widżety czatu, iframy płatności, banery zgody na pliki cookie i nakładki analityczne są często tworzone przez podmioty trzecie z użyciem stałych rozmiarów w px i mogą blokować powiększanie. Mimo że kod pochodzi od podmiotu trzeciego, kryterium dotyczy całej strony dostarczanej użytkownikowi.
• Naprawianie układu desktopowego pod kątem powiększania, ale zaniedbywanie punktu przerwania dla urządzeń mobilnych — wiele zespołów testuje powiększanie na desktopie i ogłasza sukces, ale widoki mobilne przy 200% powiększeniu stwarzają osobny zestaw wyzwań układowych, szczególnie dla menu nawigacyjnych, przyklejonych nagłówków i dolnych pasków nawigacyjnych, które opierają się na stałych wysokościach w pikselach.

Związek z Przepisami Dotyczącymi Dostępności w Turcji

Okrężnik Prezydencki Turcji 2025/10, opublikowany w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia obowiązkowe wymagania dotyczące dostępności serwisów internetowych i mobilnych dla określonego zestawu organizacji działających w Turcji. Okrężnik odwołuje się do międzynarodowo uznanych standardów dostępności — w praktyce zrównując tureckie wymagania z WCAG 2.1 i WCAG 2.2 Poziom AA jako punktem odniesienia dla zgodności.

WCAG 1.4.4 Resize Text jest kryterium na Poziomie AA, a zgodność z Poziomem AA jest progiem wymaganym do uzyskania Logotypu Dostępności (Erişilebilirlik Logosu) wydawanego przez Ministerstwo Rodziny i Usług Społecznych (Aile ve Sosyal Hizmetler Bakanlığı). Logotyp Dostępności jest zarówno sygnałem zaufania publicznego, jak i punktem kontrolnym regulacyjnym — organizacje objęte okrężnikiem, które chcą wyświetlać logotyp lub wykazać zgodność przed audytorami, muszą spełnić wszystkie kryteria Poziomu AA, w tym 1.4.4.

Kategorie podmiotów objętych Okrężnikiem Prezydenckim 2025/10 obejmują: instytucje i agencje publiczne na wszystkich szczeblach administracji; platformy e-commerce i rynki internetowe; banki i dostawców usług finansowych regulowanych przez Urząd Regulacji i Nadzoru Bankowego (BDDK); szpitale, ośrodki zdrowia i inne organizacje opieki zdrowotnej świadczące cyfrowe usługi dla pacjentów; operatorów telekomunikacyjnych z 200 000 lub większą liczbą abonentów; biura podróży i internetowe platformy turystyczne; prywatne firmy transportowe oferujące cyfrową sprzedaż biletów lub rezerwacje; oraz prywatne szkoły i instytucje edukacyjne upoważnione przez Ministerstwo Edukacji Narodowej (Millî Eğitim Bakanlığı, MoNE).

Dla każdej z tych kategorii podmiotów praktyczne znaczenie 1.4.4 jest istotne. Portal bankowości internetowej banku, który blokuje gest szczypania w celu powiększenia na urządzeniach mobilnych, nie jest jedynie porażką w zakresie użyteczności — jest to niezgodność regulacyjna, która może skutkować ustaleniami audytowymi lub wykluczeniem z programu Logotypu Dostępności. System rezerwacji wizyt szpitalnych, który używa stałych rozmiarów czcionek w pikselach wewnątrz kontenerów przycinających treść, nie tylko nie obsługuje pacjentów słabowidzących, ale jednocześnie nie spełnia zobowiązań wynikających z okrężnika. Platforma rekrutacyjna prywatnej szkoły, która osadza tekst w obrazach zamiast używać skalowalnego tekstu HTML, jest podobnie niezgodna.

Organizacje powinny traktować WCAG 1.4.4 nie jako wąski techniczny punkt kontrolny, lecz jako podstawowe oczekiwanie szacunku wobec użytkowników z niepełnosprawnościami wzroku — oczekiwanie, w którym prawo tureckie, międzynarodowe dobre praktyki i podstawowa użyteczność są ze sobą zgodne. Nakładkowy SDK Accsible wspiera zgodność w zakresie powiększania tekstu, zapewniając konfigurowalne kontrolki skalowania czcionki, które pozwalają użytkownikom końcowym zwiększać rozmiar tekstu niezależnie od powiększenia przeglądarki, oferując dodatkową warstwę udogodnień ponad podstawowe wymagania, które same witryny muszą wdrożyć.