Przejdź do treści głównej
SiteScan.top

Wersja mobilna: defekty, których przegląd na desktopie nie widzi

Viewport, obszary dotyku, przewijanie w poziomie i klawiatura zasłaniająca przycisk. Kontrole decydujące o tym, czy użytkownik telefonu dokończy zadanie.

Mobile · Opublikowano: 4 września 2026 · 3 min czytania · Дмитрий Орлов

Większość zespołów ogląda swoją witrynę na laptopie i wdraża. Większość ich ruchu jest z telefonu. W szczelinie między tymi zdaniami mieszka osobna rodzina defektów: żadnego nie widać przy szerokości 1440 pikseli, a każdy potrafi przerwać zakup.

Zacznij od viewportu

Jedna brakująca linia sprawia, że telefon renderuje stronę w szerokości desktopowej i ją zmniejsza:

<meta name="viewport" content="width=device-width, initial-scale=1">

Dwa jej warianty są gorsze niż brak. maximum-scale=1 i user-scalable=no blokują zoom szczypaniem — to twarda porażka dostępności dla każdego, kto słabo widzi, a przeglądarki i tak coraz częściej je ignorują. Żaden układ nie jest wart odebrania czytelnikowi powiększania.

Obszary dotyku

Opuszka palca ma około dziewięciu milimetrów. Wytyczne zgadzają się na minimum około 44 × 44 pikseli CSS plus kilka pikseli odstępu. Poniżej tego dotknięcia lądują obok celu, a odwiedzający wini witrynę, nie swój kciuk.

Psuje się to przewidywalnie: przyciski-ikony pomniejszone na mobile, linki w gęstej stopce, nieklikalne etykiety checkboxów i paginacja zaprojektowana pod mysz. Szukaj małej kontrolki obok innej małej kontrolki: chybienie w pojedynczy przycisk kosztuje chwilę, chybienie w rzędzie pięciu — błędną akcję.

Przewijanie w poziomie

Jeśli choć jeden element jest szerszy od viewportu, cała strona jedzie w bok, a tekst ucieka za krawędź. Zwykli winowajcy to tabela o stałej szerokości, obraz bez max-width: 100%, blok kodu albo kontener z min-width skopiowanym z projektu desktopowego.

Test to jedna linia w konsoli:

document.documentElement.scrollWidth > window.innerWidth

Uruchom przy 360 pikselach dla każdego szablonu, nie tylko dla strony głównej.

Problem klawiatury

Na telefonie klawiatura ekranowa zasłania dolną jedną trzecią ekranu. Przycisk wysyłki przypięty do dołu formularza ląduje pod nią. Tak samo komunikat o błędzie wyjaśniający, dlaczego formularz się nie wysłał. To najczęstszy powód, dla którego mobilny formularz "nic nie robi": informacja zwrotna istnieje, tylko poza kadrem.

Sprawdzaj z otwartą klawiaturą, a nie z polem jedynie zafokusowanym w emulatorze desktopowym.

Tekst i pola

Rozmiar czcionki poniżej 16 pikseli w polu sprawia, że iOS przybliża stronę przy fokusie, a układ już się z tego nie podnosi. Tekst poniżej 14 pikseli to problem czytelności w słońcu. I każde pole zasługuje na właściwe inputmode i autocomplete — klawiatura numeryczna do numeru telefonu to zmiana dwóch atrybutów, która mierzalnie podnosi odsetek wypełnień.

Testuj na prawdziwych szerokościach

Emulacja w DevTools łapie układ, ale nie łapie klawiatury, pasków przeglądarki zjadających sto pikseli ani chybienia o dwa milimetry. Raz na wydanie przejdź kluczowe ścieżki na prawdziwym urządzeniu, a część mechaniczną — meta viewport, rozmiary celów, przepełnienie, atrybuty pól — zautomatyzuj na każdej stronie i przy każdym wdrożeniu.

Przeczytaj także

Sprawdź, ile z tego dotyczy Twojej strony

Darmowe skanowanie pokaże uszkodzone linki, błędy JS i problemy z wydajnością w minutę.