Jak testować responsywność i widoki mobilne?

Strona mieści się na monitorze, ale na wąskim ekranie przycisk ucieka poza widok. Użytkownik może zobaczyć część formularza i nadal nie być w stanie zakończyć zadania. Test responsywności sprawdza, czy układ dostosowuje się do dostępnego miejsca oraz czy treść i działania pozostają użyteczne. Sam ładny zrzut strony początkowej to za mało.

W tej lekcji porównasz dwa warianty lokalnego interfejsu: celowo wadliwy A i poprawiony B. Przygotujesz widoki, zmierzysz poziome wychodzenie treści, wykonasz zadanie z formularzem i zapiszesz warunki raportu. Materiał jest przeznaczony dla początkujących; nie musisz pisać CSS. Demo nie wysyła wiadomości ani nie zapisuje wpisanych danych.

1. Ustal jednostki i wymaganie

Viewport to obszar, w którym przeglądarka układa stronę. Wartość 360 px w DevTools oznacza w tym ćwiczeniu piksele CSS, a nie liczbę fizycznych punktów matrycy telefonu. Gęstość ekranu może powodować, że jeden piksel CSS odpowiada kilku fizycznym pikselom. Nie wpisuj do raportu wyłącznie modelu urządzenia; zapisz szerokość i wysokość widoku.

Wymaganie laboratorium brzmi: przy 360 px główna treść ma mieścić się bez poziomego przewijania całej strony. Formularz i pomoc mogą ułożyć się jeden pod drugim. Menu, etykiety, pola, wysłanie oraz komunikat mają pozostawać osiągalne. Nie wymagamy identycznego położenia elementów jak na szerokim monitorze.

W projekcie ustal wspierane środowiska i zadania użytkowników. Nie zakładaj, że zestaw popularnych modeli w DevTools jest kompletną listą testów produktu. Długi tekst, otwarte menu, komunikat walidacji i mała wysokość mogą ujawnić problem, którego nie pokaże pusty ekran w kilku szerokościach.

2. Przygotuj lokalne porównanie A i B

Uruchom w katalogu projektu:

node tools/serwer-lekcji.cjs

Następnie otwórz http://127.0.0.1:8787/content/cwiczenia/interfejs-demo/lab.html. Potrzebujesz działającego polecenia node. Przycisk „Resetuj ćwiczenie” przywraca A i puste pola. Zmiana wariantu przebudowuje panel, więc również usuwa wpisany tekst i stan menu. Nie traktuj tej utraty danych jako nieznanego defektu — to mechanizm porównania demonstracji.

Sprawdź widoczny wybór A. Otwórz DevTools przez Ctrl+Shift+I i włącz pasek urządzeń, Toggle device toolbar. Wybierz Responsive, wpisz 360 szerokości oraz 800 wysokości. Dokumentacja Chrome Device Mode opisuje ustawianie wymiarów, orientacji i ograniczenia symulacji.

Zapisz przeglądarkę z wersją, wariant, viewport, powiększenie strony oraz rodzaj emulacji. Jeśli nie potrzebujesz ograniczeń CPU lub sieci, pozostaw je wyłączone. Responsywność układu i wydajność przy wolnym połączeniu są różnymi pytaniami; nie łącz ich przypadkowo w pierwszy test.

3. Obejrzyj całą stronę, nie tylko górę

W A cały panel .surface.bad, obejmujący formularz i pomoc, ma minimalną szerokość 760 px. Przy widoku 360 px powierzchnia wykracza poza dostępny obszar. Przewiń stronę pionowo i poziomo. Sprawdź, czy aby przeczytać zwykły tekst lub dotrzeć do części formularza, musisz przesuwać widok w bok. Zanotuj element i wpływ na zadanie, zamiast pisać tylko „mobilka się rozjechała”.

Następnie wybierz B przy tych samych wymiarach. Treść formularza dopasowuje się do dostępnego miejsca, a panel pomocy przechodzi pod formularz. Porównaj kolejność oraz dostęp do przycisku. Poprawiony układ może być wyższy; konieczność pionowego przewijania nie jest sama w sobie błędem.

Porównujemy dostępność tego samego zadania. Zmiana liczby kolumn jest zamierzonym dostosowaniem układu.

Automatyczny pomiar tej lekcji w Chromium 151.0.7922.34 dał dla A clientWidth = 360 i scrollWidth = 778, a dla B obie wartości 360. Liczba 778 obejmuje układ całej strony i marginesy; nie jest nowym wymaganym minimum panelu. Nie przepisuj jej jako gwarantowanego wyniku każdego środowiska.

4. Użyj pomiaru do potwierdzenia obserwacji

W Console lokalnego demo możesz wykonać wyrażenie:

({
  viewport: window.innerWidth,
  client: document.documentElement.clientWidth,
  scroll: document.documentElement.scrollWidth
})

Kod odczytuje wymiary i nie zmienia strony. Większe scrollWidth niż clientWidth jest sygnałem wychodzenia treści w poziomie. Własności opisują MDN: scrollWidth oraz MDN: clientWidth. Obejrzyj stronę, aby powiązać liczbę z konkretnym elementem.

Pomiar nie ocenia samodzielnie czytelności ani tego, czy przycisk jest zasłonięty przez inny panel. Ukrycie przepełnienia przez overflow-x: hidden może usunąć pasek, a jednocześnie odciąć treść. Dlatego brak poziomego przewijania nie wystarcza do zaliczenia zadania. Sprawdź, czy użytkownik rzeczywiście może odczytać, wpisać i wysłać dane.

Jeśli występuje szeroka tabela lub mapa, projekt może wymagać przewijania konkretnego obszaru. Oceniaj wtedy ustalone zadanie i sposób dostępu. Nasz formularz nie jest takim wyjątkiem; minimalna szerokość blokująca dopasowanie zwykłego panelu jest celowym defektem A.

5. Testuj pomiędzy gotowymi rozmiarami

Ustaw 1280×900, a potem zmniejszaj szerokość płynnie. W B kod zawiera regułę @media (max-width: 700px), która zmienia ułożenie formularza i pomocy. Zapisz próby przy 699, 700 i 701 px. Różnica jednego piksela pomaga sprawdzić przejście, ale nie zastępuje oględzin innych szerokości.

Media query warunkuje zastosowanie stylów, na przykład w zależności od szerokości viewportu. Opisuje to MDN: używanie media queries. Nie musisz znać wszystkich deklaracji CSS, aby testować, ale wiedza o konkretnym progu pomaga dobrać dane.

W tym artykule próby 699/700/701 stanowią zadanie do wykonania, a nie zapis rzekomo przeprowadzonych testów. Jeżeli układ nie zmienia się w oczekiwanym miejscu, sprawdź wariant oraz faktyczne wymiary. Skala podglądu DevTools może sprawić, że obszar wygląda w oknie inaczej niż wynika z wartości CSS.

Dodaj małą wysokość, na przykład 360×500, oraz orientację poziomą 800×360. Sprawdź, czy dół formularza jest osiągalny i czy menu nie blokuje dostępu. Strona może nie mieć problemu z szerokością, lecz wymagać przewijania do kontrolki zasłoniętej przez stały element. Obserwuj całe zadanie, nie tylko zmianę liczby kolumn.

6. Sprawdź stany i rzeczywiste dane testowe

W B wpisz qa@example.com i „Wiadomość testowa”. Otwórz menu, sprawdź odnośniki, wróć do formularza i aktywuj „Wyślij wiadomość”. Oczekuj tekstu „Wiadomość wysłana — symulacja. Dane nie opuściły przeglądarki.”. To lokalny komunikat, nie dowód działania poczty albo API.

Powtórz z dłuższą wiadomością oraz długim syntetycznym e-mailem. Pola powinny pozwalać odczytać i poprawić treść bez rozsadzania układu. Nie potrzebujesz prawdziwej osoby ani aktywnej skrzynki. Nie zmieniaj wymagań formatu tylko po to, aby test długich danych przeszedł.

Wyślij puste wymagane pola. W tym labie natywna walidacja przeglądarki blokuje wysłanie. Obejrzyj komunikat i możliwość poprawienia danych. Jego wygląd może zależeć od przeglądarki; nie zgłaszaj różnicy stylistycznej bez wymagania. Zwróć uwagę, czy pole oraz przycisk pozostają osiągalne przy małej wysokości.

Przejdź kontrolki klawiaturą w wąskim widoku. Fokus może przesuwać stronę do pola; ważne, aby aktywny element był rozpoznawalny i obsługiwalny. Szczegółową ocenę semantyki menu, etykiet i statusu wykonasz w lekcji dostępności. Responsywność i dostępność mają części wspólne, ale nie są zamiennymi ocenami.

7. Odróżnij szerokość, zoom i urządzenie

Zmniejszenie viewportu, powiększenie strony i ustawienie skali podglądu to trzy różne operacje. Zoom przeglądarki 200% powiększa treść użytkownikowi. Skala w pasku Device Mode pomaga zmieścić emulowany obszar w oknie narzędzia. Nie opisuj ustawienia „50%” podglądu jako testu powiększenia tekstu.

Wyłącz emulację i ustaw zoom strony na 200%. Wykonaj ponownie zadanie z menu i formularzem, odczytaj komunikat oraz zanotuj rezultat. Ta próba jest zaplanowana dla czytelnika; nie została ręcznie wykonana podczas weryfikacji materiału. Po próbie przywróć 100%, aby kolejne warunki nie były przypadkowo zmienione.

Kryterium WCAG 1.4.10 Reflow dotyczy zachowania przy szerokości odpowiadającej 320 pikselom CSS dla treści przewijanej pionowo, z określonymi wyjątkami. Przykładowo 1280 px przy powiększeniu 400% odpowiada takiemu obszarowi. Sam test 360 px albo 200% nie dowodzi spełnienia tego kryterium. W3C: Understanding Reflow.

Device Mode jest przybliżeniem mobilnych warunków. Nie uruchamia kodu na procesorze telefonu i nie odtwarza wszystkich zachowań systemu, klawiatury ekranowej czy przeglądarki. Test na rzeczywistym urządzeniu wykonaj oddzielnie. W tym materiale pozostaje niewykonany, a w raporcie nie otrzymuje wyniku OK.

8. Zgłoś problem z konkretnymi warunkami

Raport A może mieć tytuł „Panel kontaktu wymaga poziomego przewijania przy viewport 360×800”. Zapisz wariant A, 100% zoom, przeglądarkę, reset, wymiary i kroki. Oczekiwanie: główna treść mieści się w szerokości, a całe zadanie jest dostępne. Wynik: panel wykracza poza widok; część treści wymaga ruchu w poziomie.

Dodaj własny pomiar oraz zrzut pokazujący problem. Nie opisuj testu jako „iPhone”, jeżeli użyłeś jedynie wymiarów w komputerze. Nie wpisuj „na wszystkich telefonach”, jeśli nie sprawdziłeś tych środowisk. Raport powinien pozwalać odtworzyć warunki, a nie zwiększać zakres wniosku ponad dowody.

Po poprawce powtórz wadliwą szerokość i sprawdź sąsiednie widoki oraz pełne zadanie. Usunięcie paska nie potwierdza naprawy, jeśli treść została odcięta. Użyj checklisty lub PDF, pamiętając, że oczekiwane wyniki nie są automatycznie wynikami wykonania.

Do notatki dodaj macierz „wariant × widok × stan”. Przykładowo B przy 360×800 z pustym formularzem i B przy tych samych wymiarach po wyświetleniu komunikatu to dwa różne stany. Nie trzeba mnożyć każdej kombinacji bez celu, ale taki zapis ujawnia brakujące sprawdzenia. Jeśli testowano tylko ekran początkowy, zaznacz to wyraźnie. W raporcie krótkiej sesji łatwiej wtedy odróżnić problem układu od zadania, którego w ogóle nie próbowano zakończyć.

9. Zadanie i rozwiązanie

Porównaj A i B przy 360×800 oraz 1280×900. Zapisz trzy wymiary z Console, wykonaj wysłanie w B i dodaj próby 699/700/701. Osobno zaplanuj 200% oraz telefon. Przy każdym wyniku podaj „wykonany”, „niezgodny” albo „niewykonany”, zamiast jednego ogólnego „mobilny działa”.

Rozwiązanie podstawowego porównania: A ma minimalną szerokość 760 px i wychodzi poza wąski widok; B dopasowuje panel i układa pomoc pod formularzem. W potwierdzonej automatycznej próbie 360 px A dało scrollWidth = 778, B = 360. Wysłanie w B ma pokazać wyłącznie lokalną symulację. Pozostałe obserwacje uzupełnij po rzeczywistych próbach, nie na podstawie wyglądu szerokiego widoku.

Źródła i kod sprawdzono 2 października 2026 r. Automatyczna weryfikacja w Chromium 151.0.7922.34 objęła pomiar A/B przy 360 px; projektowy test labu sprawdził także wysłanie i reset. Ręczny zoom 200%, fizyczny telefon oraz pełny audyt WCAG nie zostały wykonane. Autor serwisu: Marcin Kozłowski. Tekst przygotowany z pomocą AI.