HTML

O tym, że istnieją znaczniki opisujące znaczenie treści, pisze dziś każdy poradnik. Trudniejsze jest konsekwentne stosowanie ich w prawdziwym projekcie, w którym termin goni, a projekt graficzny zawiera dziesiątki nietypowych elementów. Dobrym przykładem jest „przycisk” zbudowany ze zwykłego bloku z obsługą kliknięcia w JavaScripcie. Wygląda jak przycisk, ale nie da się do niego przejść klawiszem Tab, czytnik ekranu nie ogłosi go jako przycisku, a klawisze Enter i spacja nic nie zrobią. Natywny element <button> zapewnia to wszystko bez jednej dodatkowej linijki kodu.

Semantyka nie jest więc sztuką dla sztuki. To sposób na to, żeby przeglądarka, technologie wspomagające i roboty wyszukiwarek dostały od strony informacje, które inaczej trzeba by im dostarczać dodatkowym kodem, często z błędami. Poniżej obszary, które sprawdzamy w każdym kodowanym szablonie.

Regiony strony

Układ strony opisujemy elementami <header>, <nav>, <main> i <footer>, a treści uzupełniające elementem <aside>. Region główny występuje na podstronie tylko raz. Gdy na stronie jest kilka nawigacji, na przykład menu główne, okruszki i spis treści, każda dostaje własną etykietę. Osoby korzystające z czytników ekranu przeskakują między tymi regionami jak między rozdziałami książki, więc ich poprawne oznaczenie realnie skraca drogę do treści.

Hierarchia nagłówków

Nagłówek pierwszego stopnia opisuje treść podstrony, nagłówki drugiego stopnia jej główne części, a kolejne poziomy – podrozdziały. Nie przeskakujemy poziomów tylko dlatego, że mniejszy nagłówek lepiej pasuje wizualnie, bo wielkość tekstu to zadanie CSS. Nie używamy też nagłówków do wyróżniania haseł typu „Zadzwoń teraz” w stopce. Spis nagłówków strony powinien czytać się jak sensowny konspekt.

Linki, przyciski i formularze

• Link prowadzi, przycisk działa. Element <a> z atrybutem href służy do przejścia pod inny adres lub w inne miejsce strony. Otwarcie okna, rozwinięcie menu czy wysłanie formularza to zadanie dla <button>.
• Opisowa treść linków. „Zobacz cennik pozycjonowania” mówi więcej niż „kliknij tutaj” zarówno użytkownikowi czytnika ekranu, który przegląda listę linków, jak i wyszukiwarce.
• Etykiety i grupy pól. Każde pole ma element <label>, a powiązane opcje, na przykład przyciski wyboru, są zgrupowane w <fieldset> z opisem w <legend>. Sam tekst zastępczy w polu nie jest etykietą, bo znika po rozpoczęciu pisania.
• Właściwe typy pól. Pola typu email i tel otwierają na telefonie odpowiednią klawiaturę, a atrybut autocomplete pozwala przeglądarce podpowiedzieć zapisane dane. To drobiazgi, które wyraźnie ułatwiają wypełnienie formularza.

Tabele i listy

Tabel używamy wyłącznie do danych tabelarycznych, takich jak cenniki, porównania czy harmonogramy, i opisujemy je podpisem oraz komórkami nagłówkowymi. Układu strony nie budujemy tabelami od lat, ale wciąż spotykamy je w starszych serwisach. Menu i zestawy linków zapisujemy jako listy, dzięki czemu czytnik ekranu od razu poinformuje, ile pozycji zawiera nawigacja.

Szybkość strony kojarzy się zwykle z serwerem i hostingiem, tymczasem wiele problemów ma źródło w samym kodzie HTML: w tym, jak zadeklarowano obrazy, w jakiej kolejności ładują się skrypty i jak rozbudowane jest drzewo elementów. Google opisuje doświadczenie użytkownika trzema wskaźnikami Core Web Vitals: LCP mówi, jak szybko pojawia się największy element treści, INP – jak szybko strona reaguje na kliknięcia i dotknięcia, a CLS – czy układ nie przeskakuje podczas ładowania. INP zastąpił w 2024 roku wcześniejszy wskaźnik FID. Na każdy z nich wpływają decyzje podejmowane podczas pisania HTML.

Obrazy

• Wymiary w kodzie. Atrybuty width i height pozwalają przeglądarce zarezerwować miejsce na obraz, zanim zostanie pobrany. Bez nich tekst przesuwa się w dół, gdy obraz się pojawi, co pogarsza CLS i irytuje czytających.
• Różne rozmiary dla różnych ekranów. Atrybuty srcset i sizes pozwalają telefonowi pobrać mniejszy plik niż monitor o dużej rozdzielczości, a element <picture> – podać nowoczesne formaty, takie jak AVIF i WebP, z bezpiecznym wariantem zapasowym.
• Leniwe ładowanie z głową. Atrybut loading="lazy" stosujemy dla obrazów poniżej pierwszego ekranu, ale nigdy dla głównego obrazu, który zwykle jest elementem mierzonym przez LCP. Ten oznaczamy wyższym priorytetem pobierania.

Skrypty i style

Skrypt wstawiony w sekcji head bez atrybutów defer lub async zatrzymuje budowanie strony do czasu, aż zostanie pobrany i wykonany. Dlatego własne skrypty ładujemy z atrybutem defer, a narzędzia firm zewnętrznych, takie jak czaty, mapy czy wtyczki społecznościowe, wczytujemy dopiero wtedy, gdy są potrzebne, na przykład po przewinięciu do sekcji z mapą. Style krytyczne dla pierwszego ekranu są małe i dostępne od razu, reszta może poczekać.

Rozmiar drzewa elementów

Kreatory wizualne potrafią owinąć jeden akapit w kilka lub kilkanaście zagnieżdżonych bloków. Przy rozbudowanych podstronach daje to tysiące elementów, które przeglądarka musi przechowywać w pamięci i przeliczać przy każdej zmianie, co spowalnia reakcję na działania użytkownika. Narzędzie Lighthouse ostrzega przed nadmiernym rozmiarem DOM. Pisząc kod ręcznie, używamy tylko tych kontenerów, które są potrzebne do układu.

Czcionki

Każda grubość i odmiana kroju to osobny plik. Ograniczamy je do niezbędnych, wybieramy zestawy znaków z polskimi literami, a główny plik czcionki ładujemy z wyprzedzeniem. Ustawiamy też wyświetlanie tekstu krójem zastępczym, dopóki właściwa czcionka się nie pobierze, żeby użytkownik nie patrzył na pustą stronę.

Przez lata wiele typowych elementów interfejsu wymagało bibliotek JavaScript: rozwijane sekcje, okna modalne, podpowiedzi, walidacja formularzy, leniwe ładowanie obrazów. Dziś dużą część tych zadań przeglądarki realizują natywnie. Mniej skryptów oznacza szybsze ładowanie, mniej miejsc, w których coś może się zepsuć po aktualizacji, i lepszą dostępność od pierwszego dnia, bo natywne elementy mają wbudowaną obsługę klawiatury i technologii wspomagających. Zanim sięgniemy po nowość, sprawdzamy jej obsługę w tabelach zgodności przeglądarek i testujemy na urządzeniach.

Rozwijane sekcje bez skryptu

Para elementów <details> i <summary> tworzy sekcję, którą użytkownik rozwija i zwija kliknięciem lub klawiaturą. Tak zbudowana jest sekcja pytań na tej stronie. Treść odpowiedzi znajduje się w kodzie od początku, więc wyszukiwarka ją widzi, a część przeglądarek potrafi ją nawet automatycznie rozwinąć, gdy ktoś szuka na stronie słowa ukrytego w zwiniętym fragmencie.

Okna dialogowe i panele wyskakujące

Element <dialog> otwarty jako okno modalne wyświetla się nad całą stroną, blokuje interakcję z resztą treści i zamyka się klawiszem Escape. Wcześniej każde z tych zachowań trzeba było oprogramować ręcznie, a błędy w obsłudze fokusu były jednym z najczęstszych problemów z dostępnością. Do lżejszych zastosowań, takich jak menu kontekstowe czy podpowiedź, służy atrybut popover, który otwiera panel przyciskiem i zamyka go kliknięciem poza nim, bez własnego kodu obsługi zdarzeń.

Formularze, które pilnują się same

Atrybuty required, minlength, pattern czy typy pól, takie jak email, url i number, pozwalają przeglądarce zatrzymać oczywiste błędy przed wysłaniem formularza i wskazać problematyczne pole. Atrybut inputmode podpowiada telefonowi, jaką klawiaturę pokazać. To jednak tylko pierwsza linia: dane zawsze sprawdzamy ponownie po stronie serwera, bo walidację w przeglądarce można łatwo obejść.

Wyłączanie fragmentów strony

Atrybut inert sprawia, że wskazany fragment strony staje się nieaktywny: nie da się do niego przejść klawiaturą ani go kliknąć, a czytnik ekranu go pomija. Przydaje się na przykład przy otwartym menu mobilnym, które zasłania resztę treści. Zamiast pisać własną logikę „płapania” fokusu, wystarczy oznaczyć tło jednym atrybutem.