1. Wybierz zadanie strony, zanim wybierzesz layout
Zacznij od stron realizujących zadanie klienta lub biznesu: strony usługowe, karty produktowe, formularze leadów, rezerwacje, logowanie, koszyk i pomocy. Napisz jedno zdanie definicyjne ukończenia dla każdej z nich, np.: „Nowy odwiedzający rozumie tę usługę, widzi istotne dowody i może poprosić o telefon.” Jeśli strona ma więcej niż jedno zadanie, zdecyduj, które ma się pojawić jako pierwsze.
Wypisz jej treści jako niezbędne, wspierające lub opcjonalne. „Niezbędne” nie znaczy krótkie; odwiedzający może potrzebować kontekstu cenowego, warunków uprawniających, szczegółów dostawy czy informacji porównawczych. Zapewnij tej treści wyraźną drogę w wąskim układzie. Google zaleca równoważność treści podstawowej na urządzeniach mobilnych i desktopie, przy dopuszczeniu innej prezentacji, np. kart czy akordeonów.
Na wąskiej szerokości współpracownik powinien być w stanie powiedzieć, co strona oferuje, komu pomaga i jakie jest następne sensowne działanie.
2. Zrób wąski baseline kompletnym
Zacznij od działającej ścieżki jednoukładowej zamiast pomniejszania layoutu desktopowego. Używaj elastycznych kontenerów, pozwól tekstowi owijać się i dołącz ustawienie viewportu, które pozwala przeglądarce dopasować layout do szerokości urządzenia. Nie blokuj powiększania. Sprawdź, czy menu, powiadomienia, obrazy, embedy i błędy formularzy mieszczą się w viewport; niezamierzone poziome przewijanie całej strony zwykle jest defektem.
Użyj 320 pikseli CSS jako wymagającego testu przepływu dla zwykłego czytania i treści zadaniowych. WCAG 2.2 opisuje prezentowanie treści pionowej przy tej szerokości bez utraty informacji czy funkcjonalności ani bez przewijania w dwóch wymiarach. Mapy, wykresy lub tabele danych mogą wymagać własnego regionu przewijania, ale to nie uzasadnia wymuszania bocznego przewijania otaczającej strony.
Dopasuj obrazy do ich kontenera i podaj wymiary, aby przeglądarka mogła zarezerwować przestrzeń zanim się załadują.
3. Dodawaj ulepszenia, nie czyniąc ścieżki bazowej kruchej
Progressive enhancement oznacza, że istotne treści i funkcje działają w baseline, podczas gdy przeglądarki z większymi możliwościami i większe ekrany dostają dodatki. Adres, szczegóły produktu, etykiety formularzy, wyjaśnienie ceny i ścieżka wysyłki nie powinny zależeć od animacji, hovera czy skryptu ładowanego późno. Szerszy układ może dodać panel porównań, stałą nawigację czy bogatsze filtrowanie bez czynienia baseline niekompletnym.
Poproś wykonawcę, by dodał punkt przerwania (breakpoint) wtedy, gdy treść zaczyna się robić ciasna lub marnotrawna, a nie dlatego, że w liście pojawia się nazwa urządzenia. Breakpoint to po prostu miejsce, gdzie zmienia się reguła layoutu. Nie używaj wąskich układów do cichego usuwania tekstu pomocniczego, warunków polityki, opinii, metadanych czy istotnych zorganizowanych szczegółów.
Pokaż najpierw podstawowy obraz galerii i opis, a potem dodaj powiększenie lub kontrolki przesuwania, gdy ich skrypty będą dostępne.
4. Projektuj kontrolki pod dotyk, czytelność i odzyskiwalność
Ergonomia dotykowa oznacza projektowanie dla dłoni, a nie precyzyjnego wskaźnika myszy. Daj przyciskom, checkboxom, ikonom zamykania, selektorom ilości i opcjom formularzy odpowiedni rozmiar i odstęp, by zmniejszyć nieprawidłowe tapnięcia. Etykietuj ikony, gdy ich znaczenie nie jest oczywiste. Nie czynij hovera jedynym sposobem odsłonięcia ceny, podmenu, wyjaśnienia czy akcji.
WCAG 2.2 zawiera kryterium poziomu AA dotyczące wielkości targets: co najmniej 24 na 24 piksele CSS dla celów wskazujących, z określonymi wyjątkami, w tym odstępami i linkami inline. Traktuj to jako minimalny punkt odniesienia, a nie gwarancję komfortu. Krytyczne akcje zasługują na jasne etykiety, hojne odstępy i odwracalny krok potwierdzenia. W przypadku ścieżek wysokiego ryzyka lub formalnych roszczeń zgodności zasięgnij kwalifikowanej recenzji dostępności.
Zachowaj widoczne etykiety, pokaż użyteczny feedback walidacji i zachowaj wpisane wartości po wystąpieniu błędu.
5. Traktuj media i embedy jako część ścieżki odwiedzającego
Zdecyduj, czy każde zdjęcie jest informacyjne, perswazyjne czy dekoracyjne. Obraz informacyjny potrzebuje odpowiedniego opisu alternatywnego oraz przycięcia na wąskim układzie, które zachowa niezbędne detale. Opcje responsywnych obrazów pozwalają przeglądarce wybrać odpowiedni zasób zamiast zmuszać każdego odwiedzającego do pobrania największego zasobu desktopowego. Nie pozwól, by hero image lub wideo zasłoniły cel strony i główną akcję.
Sporządź inwentarz map, czatów, wideo, płatności, planowania, zgód i widgetów opinii. Na wąskim ekranie sprawdź ich stan ładowania, rozmiar kontrolek, ograniczony layout i praktyczny fallback. W przypadku płatności, tożsamości czy przepływów regulowanych zaangażuj kwalifikowanych recenzentów bezpieczeństwa, prywatności i zgodności; test wizualny nie jest oceną bezpieczeństwa.
Zapisz każdy zewnętrzny komponent, jego właściciela, funkcję biznesową i zatwierdzony fallback na wypadek, gdyby był wolny lub zepsuty.
6. Testuj ścieżki zadań przed wydaniem i planuj remediację
Używaj trybu responsywnego przeglądarki wcześnie, by przejrzeć wąskie, średnie i szerokie szerokości. Chrome Device Mode może przybliżać viewport, dotyk, orientację, sieć i warunki CPU, ale Chrome dokumentuje to jako przybliżenie, a nie rzeczywiste wykonanie na urządzeniu. Gdy to możliwe, zakończ krytyczne ścieżki na rzeczywistych telefonach i odpowiednich przeglądarkach.
Testuj zadanie, a nie tylko zrzut ekranu: zimne ładowanie, nawigacja, nieprawidłowe i poprawne wysłanie formularza, zmiana orientacji, zoom i powrót z ekranu strony trzeciej. Zapisz URL, przeglądarkę lub urządzenie, zadanie, oczekiwany rezultat, właściciela i decyzję o rollbacku. Dla większych zmian w szablonach, checkoutcie, CMS-ie lub zależnościach, etapuj wydanie i przygotuj przywrócenie poprzedniej ścieżki zamiast improwizacji pod presją.
Zatwierdź dopiero po tym, gdy krytyczne zadanie działa, kontrolki są użyteczne, nie występuje poziome przewijanie całej strony, a kluczowe zależności mają fallback.