Najważniejsze wnioski
- Powiększenie tekstu do 200% powinno zachować treść i funkcjonalność; samo zwiększenie liter nie wystarcza, jeśli układ ucina przyciski, formularze lub komunikaty.
- Kryterium WCAG 2.2 1.4.12 nie wymaga domyślnej interlinii 1,5. Wymaga jednak, aby po ustawieniu określonych odstępów nie doszło do utraty treści ani funkcji.
- Reflow należy testować na szerokości odpowiadającej 320 CSS px: istotna treść nie powinna wymagać przewijania poziomego.
- WCAGbot wspiera użytkownika narzędziami do powiększania tekstu, zmiany interlinii i odstępów. Nie zastępuje jednak napraw źródłowych, gdy komponent ma stałą wysokość, ukrywa przepełnienie lub nie przechodzi do układu jednokolumnowego.
- Największe ryzyko w e-commerce dotyczy zwykle nagłówka, filtrów, kart produktów, koszyka, formularzy, podsumowania zamówienia i bramki płatności.
Dla zarządzającego
Odporność layoutu jest częścią jakości usługi cyfrowej, a nie kosmetycznym dodatkiem. Widget może dać użytkownikowi natychmiastową kontrolę nad prezentacją tekstu, lecz zespół powinien zaplanować audyt i poprawki źródłowe dla miejsc, w których powiększenie ujawnia bariery w zakupie lub obsłudze usługi.
Dla sprzedaży
Jeżeli klient pyta o większy tekst, warto wyjaśnić dwie rzeczy: WCAGbot pozwala szybko uruchomić funkcje wspierające dostępność, a równolegle strona powinna przejść test reflow oraz odstępów. To uczciwy pierwszy krok, który ułatwia rozmowę o dalszym audycie i priorytetach napraw.
Test odpornego layoutu odpowiada na proste pytanie: czy użytkownik nadal może wygodnie korzystać ze strony, gdy zwiększy tekst, interlinię albo odstępy? Jeśli po zmianie ustawień nagłówek znika, przycisk „Do koszyka” jest ucięty, filtr zasłania listę produktów albo formularz nie pokazuje błędu, layout nie jest odporny.
To nie jest wyłącznie kwestia estetyki. Dla części osób większy tekst i większa przestrzeń między znakami ułatwiają odbiór treści. Dla właściciela e-commerce jest to też praktyczny test jakości ścieżki zakupowej. WCAGbot może dać użytkownikowi szybki dostęp do funkcji typograficznych bez przebudowy strony, ale komponenty witryny muszą umieć bezpiecznie przyjąć te zmiany.
Najważniejsze wnioski
- Sprawdzaj powiększenie, reflow i odstępy na realnych ekranach zakupowych, nie tylko na stronie głównej.
- Nie zmniejszaj automatycznie tekstu, aby „zmieścić go” w stałym boksie. Najpierw pozwól treści się zawinąć, a komponentowi zwiększyć wysokość.
- Traktuj narzędzia typograficzne WCAGbot jako kontrolę dla użytkownika oraz sygnał do testu. Nie traktuj ich jako zastępstwa audytu WCAG i naprawy źródłowej.
- Testuj nie tylko opis produktu, lecz także menu, filtry, koszyk, formularze, komunikaty błędów i etap płatności.
Co oznacza odporny layout?
Odporny layout zachowuje treść, kolejność informacji i możliwość wykonania zadania, gdy warunki prezentacji się zmieniają. W tym artykule chodzi o trzy powiązane sytuacje: powiększenie tekstu, przeformatowanie układu na węższej szerokości oraz zwiększenie odstępów typograficznych.
W praktyce nie wystarczy, że litery są większe. Po zmianie tekstu użytkownik powinien nadal znaleźć cenę, wariant produktu, przycisk zakupu, etykietę pola i błąd walidacji. Nie powinien też przewijać poziomo całej strony tylko dlatego, że korzysta z większego tekstu.
Dostępny tekst nie kończy się na większej czcionce. Zaczyna się tam, gdzie większa czcionka nie odbiera użytkownikowi dostępu do działania.
Jakie wymagania WCAG dotyczą tekstu i układu?
W WCAG 2.2, kryterium 1.4.4 Resize Text na poziomie AA wskazano, że tekst — poza określonymi wyjątkami, takimi jak napisy i tekst będący obrazem — musi dać się powiększyć do 200% bez utraty treści lub funkcjonalności.
Kryterium 1.4.10 Reflow dotyczy przeformatowania treści. Dla treści przewijanej pionowo punktem odniesienia jest szerokość 320 CSS px. Zasadą jest brak konieczności przewijania w dwóch kierunkach, o ile dwuwymiarowy układ nie jest rzeczywiście konieczny do zrozumienia lub obsługi elementu. Przykładem uzasadnionego wyjątku może być rozbudowana tabela danych, ale nie zwykła karta produktu.
Kryterium 1.4.12 Text Spacing, także na poziomie AA, wymaga odporności na ustawienie co najmniej następujących wartości: interlinii 1,5 wysokości fontu, odstępu po akapicie 2 wysokości fontu, odstępu między literami 0,12 wysokości fontu i odstępu między słowami 0,16 wysokości fontu. Nie oznacza to obowiązku ustawienia takich wartości domyślnie. Strona ma po prostu nie gubić przez nie treści ani funkcji.
Warto odróżnić to od kryterium 1.4.8 Visual Presentation na poziomie AAA. Tam pojawiają się dodatkowe preferencje dla bloków tekstu, w tym interlinia co najmniej 1,5. Nie należy więc mówić, że domyślna interlinia 1,5 jest wymogiem WCAG AA dla każdej strony.
Szersze podstawy tych wymagań oraz relację między WCAG 2.1, WCAG 2.2 i normą techniczną opisuje artykuł WCAG 2.1, WCAG 2.2 i EN 301 549 — czym się różnią?. W kontekście usług e-commerce warto pamiętać, że EN 301 549 dla e-commerce obejmuje szerszy kontekst niż sama lista kryteriów WCAG.
WCAGbot Accessibility Path: od ustawienia tekstu do naprawy
Gdzie większy tekst najczęściej psuje sklep internetowy?
Problemy zwykle wynikają nie z samego fontu, lecz z ograniczeń CSS i założeń projektowych. Szczególne ryzyko tworzą stałe wysokości, właściwość overflow: hidden, zbyt ciasne siatki kolumn, tekst wstawiony jako obraz oraz przyciski bez miejsca na zawijanie etykiety.
| Obszar | Objaw po zmianie tekstu lub odstępów | Bezpieczniejszy kierunek naprawy | Co sprawdzić ręcznie |
|---|---|---|---|
| Nagłówek i menu | Logo, wyszukiwarka i pozycje menu nachodzą na siebie | Wariant mobilny, zawijanie lub przejście do menu rozwijanego | Czy menu da się otworzyć i zamknąć klawiaturą |
| Karta produktu | Nazwa produktu ucina się, a cena nachodzi na przycisk | Automatyczna wysokość, elastyczne kolumny, zawijanie tekstu | Czy wszystkie karty zachowują działający przycisk |
| Filtry | Długie etykiety wychodzą poza kontrolkę | Więcej miejsca w pionie, czytelne etykiety, układ jednokolumnowy | Czy zaznaczony filtr i liczba wyników są widoczne |
| Koszyk | Ilość, cena i usunięcie produktu mieszczą się tylko w jednym wierszu | Zmiana układu na pionowy dla węższej przestrzeni | Czy można zmienić ilość i przejść dalej |
| Formularz | Etykieta lub komunikat błędu jest obcięty | Brak stałej wysokości, błąd pod polem, elastyczny układ | Czy błąd opisuje problem i pozostaje przy polu |
| Baner zgody lub promocji | Przycisk akcji znika poza ekranem | Przewijany pionowo kontener lub układ kolumnowy | Czy da się podjąć decyzję bez poziomego przewijania |
Formularze zasługują na osobny test, bo błąd układu może zmienić się w błąd transakcji. Etykieta pola, wskazówka i komunikat walidacyjny muszą pozostawać dostępne. Warto połączyć ten test z kontrolą kolejności fokusu opisaną w materiale Nawigacja klawiaturą: test strony bez myszy w 15 minut.
Jak przeprowadzić test odpornego layoutu?
Najlepiej wykonywać test na wersji produkcyjnej lub środowisku możliwie zbliżonym do produkcyjnego. Nie ograniczaj go do landing page’a. Wybierz pełną ścieżkę: lista produktów, karta produktu, koszyk, dostawa, płatność i potwierdzenie.
1. Ustal ekrany i zadania krytyczne
Zapisz konkretne zadania użytkownika, na przykład: znajdź produkt, ustaw filtr, wybierz wariant, dodaj do koszyka, popraw błędny kod pocztowy i przejdź do płatności. To ważniejsze niż abstrakcyjne oglądanie strony, ponieważ layout często rozpada się dopiero po rozwinięciu filtra, pokazaniu błędu albo dodaniu długiej nazwy produktu.
2. Sprawdź powiększenie do 200%
Użyj powiększenia przeglądarki. Zgodnie z polskimi wskazówkami dotyczącymi powiększania tekstu na stronach internetowych warto opierać projekt na jednostkach względnych i nie blokować wzrostu kontenerów z tekstem stałą wysokością.
Podczas testu odpowiedz: czy każdy tekst da się odczytać? Czy nie znikają działania podstawowe? Czy modal mieści nagłówek, opis i przyciski? Czy nagłówek strony nie zasłania treści po przewinięciu?
3. Sprawdź reflow przy wąskim widoku
Ustaw widok odpowiadający szerokości 320 CSS px lub skorzystaj z narzędzi deweloperskich przeglądarki. Przewijanie poziome całej strony powinno być sygnałem do analizy. Sprawdź wyjątki osobno: tabela parametrów może wymagać przewijania w poziomie, ale jej kontener powinien być rozpoznawalny, a kluczowa akcja zakupu nie powinna znikać poza widokiem.
4. Zastosuj wartości odstępów z WCAG 1.4.12
Użyj arkusza stylów użytkownika, rozszerzenia testowego albo narzędzia, które pozwala zmienić interlinię i odstępy. Ustaw jednocześnie wartości z kryterium 1.4.12. Nie oceniaj jedynie wyglądu. Przejdź zadanie zakupowe od początku do końca.
Zwróć uwagę na tekst w przyciskach, zakładkach, etykietach filtrów, dymkach pomocy, toastach i komunikatach błędów. Te elementy są zwykle krótkie, ale krytyczne. Właśnie tam projektanci najczęściej ustawiają sztywną wysokość lub ukrywają nadmiar tekstu.
5. Zapisz defekt jako problem zadaniowy
Zamiast notatki „mobilka do poprawy”, zapisz: „Po zwiększeniu odstępów etykieta przycisku płatności jest obcięta; użytkownik nie widzi pełnej informacji o metodzie płatności; naprawa: usunąć stałą wysokość i dopuścić zawijanie”. Taki zapis jest przydatny dla projektanta, developera, osoby od QA i właściciela procesu.
Odporność layoutu a pozorne dopasowanie
WCAGbot Accessibility Path: jak połączyć wsparcie użytkownika z naprawą strony?
WCAGbot Accessibility Path porządkuje dwa równoległe działania. Pierwsze daje użytkownikowi kontrolę od razu. Drugie usuwa trwałe bariery w źródle strony.
- Uruchom funkcje wspierające dostępność. WCAGbot można dodać jedną linią kodu. Panel udostępnia między innymi powiększenie tekstu, zmianę interlinii i odstępów między literami, czytelną czcionkę, wyrównanie tekstu oraz tryby kontrastu.
- Otwórz panel na własnej stronie. Zwiększ tekst, przetestuj interlinię i odstępy na karcie produktu lub formularzu. Nie testuj tylko jednego akapitu w stopce.
- Rozdziel wynik testu. Jeżeli użytkownik zyskuje wygodniejszą prezentację treści, funkcja widgetu spełnia swoje zadanie wspierające. Jeżeli komponent ucina treść, problem leży po stronie layoutu i wymaga naprawy źródłowej.
- Napraw komponent oraz wykonaj retest. Zmiana może dotyczyć CSS, struktury HTML, kolejności elementów, obsługi modala lub treści etykiety.
- Włącz test do procesu zmian. Powtarzaj go po wdrożeniu nowego szablonu, aplikacji marketingowej, modułu płatności lub zmianie motywu.
Opis funkcji typograficznych znajdziesz w artykule Kontrast, większy tekst i czytanie treści w WCAGbot, a techniczne uruchomienie omawia poradnik Jak zainstalować WCAGbot na stronie w 5 minut.
Doświadczeniowe CTA: otwórz panel WCAGbot na swojej stronie, zwiększ tekst i interlinię, a następnie spróbuj dodać produkt do koszyka. Jeśli na którymkolwiek etapie treść znika lub akcja staje się niejasna, dodaj ten ekran do listy napraw źródłowych.
Mini-scenariusz: test karty produktu i koszyka
Scenariusz ilustracyjny — nie opisuje wdrożenia u klienta. Sklep sprzedaje produkty o długich nazwach i oferuje kilka wariantów dostawy. Zespół uruchamia panel WCAGbot, powiększa tekst oraz zwiększa interlinię i odstępy. Na liście produktów nazwy zawijają się prawidłowo, ale w jednej karcie cena przesuwa przycisk „Dodaj do koszyka” poza widoczną część komponentu.
W koszyku problem jest większy: etykieta metody dostawy zawija się do trzech linii, a kontener ma stałą wysokość. Użytkownik widzi tylko pierwszą linię i nie może zrozumieć pełnej opcji. Zespół nie „naprawia” tego przez zmniejszenie fontu. Usuwa stałą wysokość, pozwala elementowi rosnąć, układa cenę i wybór dostawy pionowo na wąskiej szerokości, a potem powtarza test.
To jest właściwy podział odpowiedzialności: WCAGbot daje możliwość wybrania wygodniejszej prezentacji, natomiast poprawiony komponent nie traci informacji po tej zmianie. Podobne podejście warto stosować do struktury tekstu — pomocny będzie materiał Nagłówki i linki: strona zrozumiała bez wzroku.
Jakich skrótów unikać?
- Nie testuj wyłącznie widoku desktopowego. Problem reflow pojawia się najczęściej na ograniczonej szerokości i po zawinięciu treści.
- Nie ograniczaj testu do strony głównej. Zakup kończy się w koszyku i płatności, gdzie układ bywa tworzony przez inne komponenty lub zewnętrznych dostawców.
- Nie ukrywaj tekstu przez
overflow: hidden. To może poprawić zrzut ekranu, lecz odbiera użytkownikowi informację. - Nie zakładaj, że ARIA naprawi problem wizualnego układu. Atrybuty ARIA nie przywrócą treści uciętej przez CSS. Więcej o granicach tego mechanizmu wyjaśnia tekst ARIA bez pułapek: kiedy pomaga, a kiedy psuje dostępność?.
- Nie uznawaj widgetu za dowód pełnej zgodności. Widget dostępności wspiera użytkownika, ale nie zastępuje audytu, testów z użytkownikami ani poprawek w kodzie i treści. Szerzej omawia to artykuł Widget dostępności a zgodność z WCAG: uczciwe porównanie.
Punkty kontrolne testu e-commerce
Co zyskuje zespół po takim teście?
Właściciel strony dostaje listę konkretnych ryzyk zamiast ogólnego hasła „strona powinna być responsywna”. UX otrzymuje informację, które komponenty nie mają bezpiecznego wariantu dla dłuższej treści. Developer widzi, gdzie należy zmienić ograniczenia CSS albo strukturę komponentu. Obsługa klienta rzadziej musi wyjaśniać użytkownikowi, co było ukryte w źle działającym formularzu.
Test typografii jest jednym z pierwszych kroków w szerszym procesie. Następnie warto przejść przez kontrast, tekst alternatywny, nagłówki, linki, obsługę klawiaturą oraz komunikaty błędów. Punkt startowy dla sklepu zbiera checklista pierwszych kroków do dostępności sklepu internetowego.
FAQ: większy tekst, interlinia i odporność layoutu
Czy WCAG wymaga domyślnej interlinii 1,5?
Nie na poziomie AA. WCAG 2.2 SC 1.4.12 wymaga, aby strona zachowała treść i funkcjonalność po ustawieniu interlinii 1,5 oraz pozostałych określonych odstępów. Wartość 1,5 jako cecha domyślnej prezentacji bloków tekstu pojawia się w kryterium 1.4.8 na poziomie AAA.
Czy powiększenie tekstu do 200% oznacza powiększenie całej strony?
To dwa powiązane, ale nieidentyczne mechanizmy. Użytkownicy mogą korzystać z powiększenia strony w przeglądarce, ustawień tekstu, lupy systemowej albo funkcji wspierających dostępność. Strona powinna poprawnie reagować na zmianę, a nie zakładać jednego sposobu powiększania.
Co dokładnie oznacza reflow?
Reflow to przeformatowanie układu do dostępnej szerokości. Przykładowo trzy kolumny mogą przejść do jednej, a elementy w wierszu mogą ustawić się jeden pod drugim. Celem jest zachowanie treści i obsługi bez poziomego przewijania całej strony.
Czy każda tabela musi zniknąć na małym ekranie?
Nie. Jeżeli układ dwuwymiarowy jest potrzebny do zrozumienia danych, tabela może wymagać przewijania w poziomie. Trzeba jednak ocenić, czy jest to rzeczywiście konieczne, oraz zadbać o czytelny kontener, nagłówki i dostęp do najważniejszych działań.
Czy większe odstępy między literami zawsze poprawiają czytanie?
Nie. Potrzeby użytkowników są zróżnicowane. Zwiększenie odstępów może pomagać części osób, ale zbyt duże lub źle zrównoważone odstępy między literami i słowami mogą utrudniać rozpoznawanie całych wyrazów. Dlatego wartości należy traktować jako ustawienia użytkownika i testować odporność strony, a nie jako uniwersalne ustawienie projektu.
Czy WCAGbot naprawi obcięty tekst w karcie produktu?
WCAGbot może umożliwić użytkownikowi powiększenie tekstu i zmianę odstępów. Jeśli jednak karta ma stałą wysokość, ukrywa przepełnienie lub ma nieelastyczny układ, potrzebna będzie naprawa w kodzie źródłowym strony.
Jakie elementy sklepu testować w pierwszej kolejności?
Najpierw sprawdź nagłówek, wyszukiwarkę, menu, filtry, karty produktów, koszyk, formularze dostawy, płatności, komunikaty błędów i okna modalne. Są to miejsca, w których użytkownik wykonuje zadania niezbędne do zakupu.
Czy test powinien obejmować zewnętrzną bramkę płatności?
Tak, o ile użytkownik przechodzi do niej w ramach procesu zakupu. Zakres możliwości naprawy zależy od modelu integracji i dostawcy, ale barierę należy co najmniej rozpoznać, opisać i uwzględnić w planie działań.
Czy automatyczny tester wystarczy do oceny reflow i odstępów?
Nie. Narzędzia automatyczne mogą pomóc wykryć część problemów, lecz nie potwierdzą, czy użytkownik rozumie układ, widzi pełną etykietę i może dokończyć zakup po zmianie ustawień. Potrzebny jest test manualny, a w szerszym procesie także audyt i testy z użytkownikami.
Jak często powtarzać test odpornego layoutu?
Wykonuj go przed publikacją nowego szablonu lub istotnej funkcji oraz po zmianach w motywie, koszyku, formularzu, module marketingowym lub integracji płatności. Warto też włączyć go do stałej checklisty QA.
Spokojny następny krok
Jeśli chcesz dać użytkownikom szybką kontrolę nad tekstem, interlinią i odstępami, zacznij od funkcji wspierających dostępność. Następnie wykorzystaj wynik testu do ustalenia kolejności napraw w kodzie i treści. Dodaj funkcje dostępności i sprawdź swoją stronę na własnym przykładzie.
Źródła i materiały
- W3C, Web Content Accessibility Guidelines (WCAG) 2.2
- W3C, Web Content Accessibility Guidelines (WCAG) 2.2
- W3C, Understanding Success Criterion 1.4.12: Text Spacing
- gov.pl, Powiększanie tekstu na stronach internetowych
- WebAIM Million 2025
- WebAIM, Survey of Users with Low Vision Results
- webaim.org
- www.w3.org
- webaim.org
- webable.com
- www.w3.org
- www.w3.org
