SandboxOne

~/nauka programowania od podstaw

Piaskownica

~/front-end/responsywna-i-dostepna-strona.md

Responsywna i dostępna strona: mobile first w praktyce

Marta KowalczykMarta Kowalczyk 6 min czytania akt.
8,6/10197 ocen
Laptop na drewnianym stole w kawiarni obok kanapek i soku
Laptop na drewnianym stole w kawiarni obok kanapek i soku.

Ponad połowa ruchu w polskim internecie pochodzi z telefonów, a kilka milionów osób w Polsce korzysta z sieci z jakąś niepełnosprawnością. Strona, która wygląda dobrze tylko na Twoim monitorze, traci więc sporą część odbiorców. Dobra wiadomość: responsywność i dostępność to w większości kwestia dobrych nawyków, a nie drogich narzędzi.

Dlaczego mobile first

Podejście mobile first oznacza, że najpierw piszesz style dla najmniejszego ekranu, a dopiero potem dodajesz reguły dla większych. Brzmi jak drobiazg, ale zmienia sposób myślenia. Na wąskim ekranie nie zmieścisz trzech kolumn i pięciu banerów, więc musisz zdecydować, co jest najważniejsze.

Technicznie mobile first upraszcza też kod. Domyślny układ jednokolumnowy wymaga niewielu reguł, a media queries z min-width tylko dokładają kolejne kolumny. Odwrotna kolejność kończy się zwykle nadpisywaniem i „odkręcaniem” stylów desktopowych.

Widok z góry na dłonie piszące na laptopie
Projektując od najmniejszego ekranu, zmuszasz się do wyboru tego, co naprawdę ważne.

Dobrym ćwiczeniem jest naszkicowanie strony na kartce w trzech wersjach: telefon, tablet i szeroki monitor. Zobaczysz od razu, które elementy muszą się przesunąć, które schować w menu, a które mogą zniknąć zupełnie. Taki szkic zajmuje kwadrans, a oszczędza godziny przepisywania stylów. Pamiętaj też, że użytkownicy telefonów często korzystają ze strony w ruchu, jedną ręką i przy słabym zasięgu – projektuj z myślą o takich warunkach.

Jednostki względne i płynna typografia

Stałe szerokości w pikselach to najczęstsza przyczyna poziomego przewijania na telefonach. Zamiast nich używaj jednostek względnych: procentów, rem dla odstępów i czcionek oraz max-width dla kontenerów.

podstawy.cssCSS
html {
  font-size: 100%;
}
 
h1 {
  font-size: clamp(1.75rem, 1.2rem + 2.5vw, 3rem);
}
 
img {
  max-width: 100%;
  height: auto;
}
 
.kontener {
  width: min(100% - 2rem, 70rem);
  margin-inline: auto;
}

Funkcja clamp() przyjmuje wartość minimalną, preferowaną i maksymalną. Dzięki niej nagłówek płynnie rośnie razem z oknem przeglądarki, ale nigdy nie staje się za mały ani za duży. Linia z max-width: 100% dla obrazów to z kolei najprostsza ochrona przed grafikami, które wystają poza ekran.

Pamiętaj też o znaczniku meta viewport w sekcji <head>. Bez niego telefon wyświetli stronę w szerokości około 980 pikseli i pomniejszy ją, a Twoje media queries nie zadziałają.

Media queries i punkty przełamania

Punkty przełamania nie powinny odpowiadać konkretnym modelom telefonów, bo tych jest setki. Ustawiaj je tam, gdzie treść zaczyna źle wyglądać. Zmniejszaj okno przeglądarki powoli i obserwuj, kiedy linie tekstu stają się za długie albo karty za wąskie.

uklad.cssCSS
.karty {
  display: grid;
  gap: 1rem;
}
 
@media (min-width: 48em) {
  .karty {
    grid-template-columns: repeat(2, 1fr);
  }
}
 
@media (min-width: 72em) {
  .karty {
    grid-template-columns: repeat(3, 1fr);
  }
}

W wielu przypadkach media queries nie są w ogóle potrzebne. Siatka z repeat(auto-fit, minmax(...)) albo Flexbox z flex-wrap dopasowują się same. Coraz popularniejsze są też zapytania o kontener (@container), które reagują na szerokość komponentu, a nie całego okna.

Dostępność: kilka zasad, które robią różnicę

Dostępność, w skrócie a11y, oznacza, że ze strony mogą korzystać wszyscy: osoby niewidome z czytnikami ekranu, osoby poruszające się wyłącznie klawiaturą, osoby z daltonizmem czy starsi użytkownicy z gorszym wzrokiem. Standardem odniesienia są wytyczne WCAG, a w Unii Europejskiej wymagania dostępności obejmują coraz więcej usług cyfrowych.

  • Kontrast tekstu do tła wynosi co najmniej 4,5:1 dla zwykłego tekstu.
  • Każdy element interaktywny da się obsłużyć klawiaturą, a fokus jest wyraźnie widoczny.
  • Obrazy niosące treść mają opisowy tekst alternatywny.
  • Pola formularzy mają widoczne etykiety, a nie tylko placeholder.
  • Informacja nie jest przekazywana wyłącznie kolorem, na przykład błąd ma też ikonę lub tekst.
  • Animacje respektują ustawienie prefers-reduced-motion.

Nigdy nie usuwaj obrysu fokusu regułą outline: none bez zastąpienia go własnym stylem. Dla osoby korzystającej z klawiatury to jak wyłączenie kursora myszy.

Kilka modeli Raspberry Pi z klawiaturą na białym tle
Stronę otwierają dziś bardzo różne urządzenia – od małych ekranów po telewizory.

Responsywne obrazy i wydajność

Zdjęcie o szerokości 4000 pikseli wyświetlane na telefonie w pasku 360 pikseli to marnowanie transferu i baterii użytkownika. Atrybuty srcset i sizes pozwalają przeglądarce wybrać plik w odpowiedniej rozdzielczości. Nowoczesne formaty, takie jak WebP czy AVIF, zmniejszają rozmiar plików nawet o połowę przy podobnej jakości.

Obrazy poniżej pierwszego ekranu oznacz atrybutem loading="lazy" – pobiorą się dopiero wtedy, gdy użytkownik do nich przewinie. Zawsze podawaj width i height, żeby przeglądarka zarezerwowała miejsce i treść nie przeskakiwała podczas ładowania. Wydajność to także element dostępności: osoba z wolnym internetem na wsi czy w pociągu też ma prawo skorzystać z Twojej strony.

Jak testować bez drogiego sprzętu

Nie potrzebujesz kolekcji telefonów. W narzędziach deweloperskich przeglądarki włączysz tryb urządzeń mobilnych i sprawdzisz szerokości od 320 pikseli wzwyż. Raz na jakiś czas otwórz jednak stronę na prawdziwym telefonie – dotyk, rozmiar palca i odblaski ekranu trudno zasymulować.

Dostępność testuj w trzech krokach. Najpierw automatycznie, na przykład audytem Lighthouse, który wyłapie brakujące etykiety i słaby kontrast. Potem ręcznie: odłóż mysz i przejdź całą stronę klawiszem Tab. Na koniec włącz wbudowany czytnik ekranu – Narrator w Windows lub VoiceOver w systemach Apple – i posłuchaj, jak brzmi Twoja strona. To doświadczenie zmienia perspektywę bardziej niż każdy poradnik.

Dobrym nawykiem jest też krótka lista kontrolna przed każdym wdrożeniem: sprawdzenie szerokości 320 pikseli, nawigacja klawiaturą, powiększenie tekstu do 200 procent i test w trybie wysokiego kontrastu. Po kilku projektach wykonasz ją w dziesięć minut, a wyłapiesz dzięki niej większość typowych błędów, zanim zobaczy je ktokolwiek inny. Zapisz wyniki w pliku README – to także świetny materiał do rozmowy rekrutacyjnej.

Najczęstsze pytania

Jakie szerokości ekranu warto sprawdzać?

Dobrym minimum jest 320, 375, 768, 1024 i 1440 pikseli. Ważniejsze od konkretnych liczb jest jednak płynne zmniejszanie okna i szukanie miejsc, w których układ się psuje.

Czy dostępność jest obowiązkowa?

Dla podmiotów publicznych w Polsce tak, na mocy ustawy o dostępności cyfrowej. Od 2025 roku wymagania obejmują też wiele usług prywatnych, na przykład sklepy internetowe i bankowość. Nawet tam, gdzie nie ma obowiązku, dostępność poprawia jakość strony dla wszystkich.

Czy em i rem to to samo?

Nie. Jednostka rem odnosi się do rozmiaru czcionki elementu html, więc jest przewidywalna w całym dokumencie. Jednostka em zależy od czcionki rodzica, co przy zagnieżdżeniach potrafi zaskoczyć.

responsywnośćdostępnośćcsswcag
Wróć do archiwum

// czytaj dalej