Najważniejsze wnioski
- Nagłówki HTML są dla użytkownika czytnika ekranu praktycznym spisem treści. Duży lub pogrubiony tekst nie zastępuje elementu h1, h2 albo h3.
- Link powinien komunikować cel po samym swoim tekście lub po programowo powiązanym kontekście. „Czytaj więcej” i „kliknij tutaj” zwykle nie wystarczają.
- Jedna strona powinna mieć jasny temat główny, logiczną kolejność sekcji oraz działające punkty orientacyjne, takie jak header, nav, main i footer.
- Szybki audyt semantyki można zacząć od listy nagłówków, listy linków i testu klawiaturą, ale pełna ocena wymaga także testów kluczowych ścieżek z technologiami asystującymi.
- WCAGbot może wspierać komfort odbioru treści między innymi przez czytanie tekstu, zmianę kontrastu, powiększenie tekstu i narzędzia skupienia. Nie zastępuje jednak naprawy błędnej struktury HTML w kodzie źródłowym.
Dla zarządzającego
Semantyczne nagłówki i jasne linki ograniczają ryzyko, że użytkownik nie dotrze do produktu, kontaktu, koszyka lub informacji po zakupie. To niewielki zakres prac redakcyjnych i technicznych, który warto włączyć do stałego procesu publikacji oraz rozwoju sklepu.
Dla sprzedaży
Jeżeli klient pyta o dostępność strony, zacznij od konkretu: czy użytkownik może odnaleźć ofertę i wykonać kluczowe zadanie bez myszy oraz bez patrzenia na układ strony. WCAGbot jest szybkim pierwszym krokiem wspierającym odbiór treści, a semantykę nagłówków, linków i formularzy trzeba sprawdzić oraz poprawić w źródle.
Jeżeli użytkownik nie widzi układu strony, nie może ocenić na pierwszy rzut oka, gdzie zaczyna się opis produktu, jak przejść do dostawy ani który link prowadzi do kontaktu. Zamiast tego korzysta ze struktury odczytywanej przez czytnik ekranu: nagłówków, linków, przycisków, list, formularzy i punktów orientacyjnych strony. Dlatego nagłówki i linki nie są detalem redakcyjnym. Są częścią nawigacji.
Najważniejsze wnioski
- Buduj strukturę strony przy użyciu prawdziwych elementów HTML, nie tylko klas CSS i formatowania wizualnego.
- Traktuj nagłówki jak spis treści: po odsłuchaniu ich listy użytkownik powinien rozumieć temat strony i kolejność sekcji.
- Nazywaj linki według celu, a nie według czynności technicznej, takiej jak „kliknij”, „więcej” czy „tutaj”.
- Sprawdzaj szczególnie karty produktów, koszyk, dostawę, zwroty, reklamacje i formularze kontaktowe.
- Użyj widgetu jako wsparcia użytkownika, ale błędną semantykę naprawiaj w kodzie i treści.
Czy osoba niewidoma czyta stronę od początku do końca?
Zwykle nie musi i nie powinna. Czytnik ekranu pozwala przechodzić między elementami według ich typu: nagłówkami, linkami, formularzami, przyciskami lub landmarkami. To przypomina korzystanie ze spisu treści, indeksu i menu skrótów zamiast przewijania całego dokumentu linia po linii.
W badaniu WebAIM Screen Reader User Survey #10 nawigację po nagłówkach jako pierwszy sposób odnajdywania informacji na długiej stronie wskazało 71,6% respondentów. Wynik pochodzi z badania ankietowego, więc nie opisuje wszystkich użytkowników czytników ekranu. Jest jednak mocną wskazówką projektową: struktura nagłówków powinna pomagać w znalezieniu treści, a nie być wyłącznie ozdobą layoutu.
Jeśli lista nagłówków nie wyjaśnia, co znajduje się na stronie, użytkownik bez wzroku zaczyna wyszukiwanie od zgadywania.
Na stronie sklepu szczególne znaczenie mają sekcje, które wspierają decyzję zakupową i obsługę po zakupie: parametry produktu, warianty, dostępność, dostawa, zwroty, płatność, reklamacje oraz kontakt. Warto zestawić tę pracę z szerszą checklistą dostępności sklepu internetowego, zamiast ograniczać się do strony głównej.
Dlaczego nagłówki HTML działają jak spis treści?
Nagłówek zapisany jako <h1>, <h2> lub <h3> przekazuje programowo rolę elementu. Czytnik ekranu może poinformować użytkownika o poziomie nagłówka, a następnie umożliwić przejście do kolejnego nagłówka tego samego typu. W3C wskazuje, że nagłówki komunikują organizację treści i mogą służyć do nawigacji po stronie.
Duży font, pogrubienie lub klasa o nazwie „title” nie tworzą takiej informacji. Poniższy przykład może wyglądać jak tytuł sekcji, lecz technologii asystującej przekazuje tylko zwykły tekst:
<div class="title">Jak złożyć reklamację</div>Wersja semantyczna przekazuje rolę nagłówka:
<h2>Jak złożyć reklamację</h2>To praktyczne zastosowanie kryterium WCAG 1.3.1 „Info and Relationships”. Widoczna struktura, na przykład relacja między tytułem sekcji a jej treścią, powinna być możliwa do ustalenia programowo.
Jak ustawić H1, H2 i H3?
Najprostsza zasada brzmi: poziom nagłówka opisuje miejsce w strukturze, a nie jego wygląd. W typowym artykule lub opisie usługi główny temat jest oznaczony jako H1. Główne obszary tego tematu dostają H2. Podtematy wewnątrz konkretnego obszaru dostają H3.
H1: Buty trekkingowe Model X
H2: Najważniejsze cechy
H2: Rozmiary i dopasowanie
H3: Tabela rozmiarów
H3: Jak zmierzyć stopę
H2: Dostawa i zwroty
H2: Opinie klientówNie wybieraj H3 tylko dlatego, że w systemie CMS ma „ładniejszy” krój. Nie przeskakuj też arbitralnie z H2 do H4. Raport WebAIM Million 2025 wykrył pominięte poziomy nagłówków na 39% badanych stron głównych. Taka automatyczna analiza nie przesądza, że każda z tych stron jest nieużywalna, ale dobrze pokazuje, jak często struktura dokumentu wymaga weryfikacji.
Jeden H1 na główną treść strony jest prostą i bezpieczną praktyką redakcyjną. W nowoczesnym HTML możliwe są bardziej złożone struktury, ale w codziennym e-commerce jasny, jeden tytuł główny ułatwia pracę autorom, deweloperom i osobom testującym.
WCAGbot Accessibility Path dla nagłówków i linków
Jak pisać linki, aby od razu było wiadomo, dokąd prowadzą?
Link powinien opisywać rezultat przejścia. Użytkownik powinien móc usłyszeć sam tekst linku i przewidzieć, co stanie się po aktywacji. W WCAG 2.2 kryterium 2.4.4 wymaga, aby cel linku można było ustalić z jego tekstu albo z programowo określonego kontekstu.
| Cel | Słaby tekst linku | Lepszy tekst linku | Dlaczego |
|---|---|---|---|
| Informacja o dostawie | Czytaj więcej | Sprawdź terminy i koszty dostawy | Cel jest zrozumiały poza kartą produktu. |
| Tabela rozmiarów | Tutaj | Otwórz tabelę rozmiarów butów Model X | Użytkownik wie, czego dotyczy odnośnik. |
| Plik do pobrania | Pobierz | Pobierz instrukcję montażu (PDF) | Wskazuje treść i format pliku. |
| Reklamacje | Więcej | Dowiedz się, jak złożyć reklamację | Opisuje działanie i temat docelowej strony. |
| Kontakt | Kliknij tutaj | Przejdź do formularza kontaktowego | Nie wymaga domyślania się celu. |
Raport WebAIM Million 2025 wskazał puste linki na 45,4% badanych stron oraz niejednoznaczne teksty linków na 13,7% stron. Wyniki dotyczą problemów wykrywalnych automatycznie. Nie zastępują oceny kontekstu, ponieważ nawet technicznie poprawny link może być dla użytkownika niejasny.
Czy można zostawić „Czytaj więcej”?
Najlepiej zastąpić je opisową nazwą. Jeżeli projekt wymaga krótkiego widocznego tekstu, można uzupełnić nazwę linku tekstem dostępnym dla czytnika, ale trzeba zachować ostrożność: ukryta informacja nie powinna wprowadzać rozbieżności między tym, co widzi użytkownik, a tym, co słyszy osoba korzystająca z technologii asystującej.
<a href="/reklamacje">
Czytaj więcej
<span class="sr-only">o składaniu reklamacji</span>
</a>W wielu przypadkach prostsza i lepsza jest po prostu widoczna nazwa: „Zasady składania reklamacji”. Warto też pamiętać, że link i przycisk pełnią różne role. Link zwykle prowadzi do innej lokalizacji lub zasobu. Przycisk uruchamia działanie na aktualnej stronie, na przykład dodaje produkt do koszyka, rozwija opis lub wysyła formularz.
Po co listy i landmarki na stronie sklepu?
Semantyka nie kończy się na nagłówkach. Lista cech produktu zapisana jako <ul> daje użytkownikowi czytnika informację, że ma do czynienia z listą i ile pozycji ona zawiera. Seria zwykłych akapitów z myślnikami nie zawsze przekazuje tę relację równie czytelnie.
Landmarki, czyli punkty orientacyjne, pomagają szybciej przechodzić między głównymi obszarami strony. Najczęściej wystarczą natywne elementy HTML:
<header>dla nagłówka strony lub obszaru,<nav>dla nawigacji,<main>dla zasadniczej treści,<aside>dla treści uzupełniającej,<footer>dla stopki.
Nie trzeba dodawać ARIA tam, gdzie właściwy element HTML już opisuje rolę. ARIA może uzupełnić semantykę złożonego komponentu, lecz nie naprawi źle zaprojektowanej interakcji ani nie zastąpi poprawnego HTML. Temat atrybutów i wymagań technicznych warto widzieć szerzej niż same wytyczne WCAG — wyjaśnia to artykuł EN 301 549 dla e-commerce: wymagania poza samym WCAG.
Audyt nagłówków i linków w 10 minut: co sprawdzić?
Poniższy audyt jest szybkim przeglądem redakcyjno-technicznym, a nie pełnym audytem WCAG. Wybierz stronę główną, kartę produktu albo stronę dostawy. Następnie wykonaj zadania w kolejności.
- Otwórz listę nagłówków w narzędziu deweloperskim, rozszerzeniu lub czytniku ekranu. Sprawdź, czy z samych nazw rozumiesz zawartość strony.
- Znajdź H1. Czy opisuje konkretny temat strony, na przykład nazwę produktu albo nazwę usługi?
- Sprawdź kolejność H2 i H3. Czy podsekcje są rzeczywiście częścią sekcji nadrzędnej? Czy nie użyto poziomu tylko dla stylu?
- Otwórz listę linków. Czy „więcej”, „tutaj”, „kliknij” i identyczne nazwy nie ukrywają różnych celów?
- Sprawdź pliki oraz nowe okna. Czy link informuje o PDF, pobraniu lub otwarciu nowej karty, jeśli taka informacja jest potrzebna do przewidywalnego użycia?
- Przejdź stronę klawiszem Tab. Czy fokus jest widoczny, kolejność logiczna, a każdy link i przycisk można uruchomić?
- Skocz do treści głównej. Czy można ominąć rozbudowane, powtarzalne menu? Więcej o tym teście opisuje poradnik Nawigacja klawiaturą: test strony bez myszy w 15 minut.
Tekst wizualny a semantyczny nagłówek
Jeżeli wynik audytu wskazuje na problem, zapisz go w sposób możliwy do przekazania zespołowi: adres strony, element, obecny komunikat, oczekiwany komunikat oraz wpływ na zadanie użytkownika. Zamiast notatki „poprawić WCAG” napisz: „Na karcie produktu link ‘więcej’ prowadzi do tabeli rozmiarów; zmienić nazwę na ‘Otwórz tabelę rozmiarów produktu Model X’”.
WCAGbot Accessibility Path: od szybkiego wsparcia do naprawy źródłowej
W przypadku problemów z nagłówkami i linkami właściwą kolejnością działań jest: rozpoznać barierę, poprawić strukturę w systemie CMS lub kodzie, a następnie sprawdzić efekt na realnej ścieżce użytkownika. To właśnie porządkuje schemat WCAGbot Accessibility Path.
- Wybierz kluczową ścieżkę, na przykład: produkt → koszyk → płatność.
- Sprawdź strukturę nagłówków, listę linków, formularze i obsługę klawiatury.
- Popraw źródło: szablon, komponent, treść, nazwę linku albo etykietę formularza.
- Przetestuj zmianę na komputerze i telefonie, wskazując konkretną kombinację przeglądarki oraz czytnika.
- Dodaj funkcje wspierające dostępność dla użytkownika, takie jak większy tekst, czytanie treści, kontrast lub przewodnik do czytania.
WCAGbot można wdrożyć jedną linią kodu na WordPressie, Shopify i stronach własnych. Widget oferuje między innymi czytanie treści, czytanie zaznaczonego tekstu, zmianę kontrastu, powiększenie tekstu, czytelną czcionkę, podświetlanie nagłówków i linków oraz funkcje skupienia. Zobacz, jak działają kontrast, większy tekst i czytanie treści w WCAGbot.
Doświadczeniowe CTA: otwórz panel WCAGbot na swojej stronie testowej, zwiększ tekst, włącz podświetlanie nagłówków i linków oraz sprawdź, czy opisy nadal są jednoznaczne. Taki test pokaże, że funkcje wspierające odbiór treści są wartościowe, ale nie zmienią elementu <div> w poprawny nagłówek ani nie dopowiedzą celu niejasnego linku. Te bariery wymagają naprawy źródłowej.
Mini-scenariusz: karta produktu, którą można zrozumieć bez wzroku
Scenariusz ilustracyjny: sklep sprzedaje ekspres do kawy. Karta produktu zaczyna się od nagłówka H1 „Ekspres ciśnieniowy Aroma 400”. Dalej znajdują się H2: „Najważniejsze cechy”, „Specyfikacja techniczna”, „Dostawa i zwroty” oraz „Opinie”. W sekcji rozmiarów nie ma linku „więcej”, lecz „Otwórz wymiary ekspresu Aroma 400”.
Użytkownik czytnika ekranu otwiera listę nagłówków i przechodzi bezpośrednio do „Dostawa i zwroty”. Następnie otwiera listę linków i wybiera „Sprawdź warunki zwrotu ekspresu Aroma 400”. Dodaje produkt do koszyka przyciskiem, a po wykonaniu działania otrzymuje czytelny komunikat o aktualizacji koszyka. Nie musi zgadywać, czy aktywował link, przycisk czy dekoracyjny element.
W tym scenariuszu poprawne nagłówki i linki nie są dodatkiem do dostępności. Są podstawą wykonania zadania. W kolejnym kroku zespół powinien sprawdzić także etykiety pól, błędy walidacji i komunikaty w koszyku. Praktyczne wskazówki dotyczące całego standardu znajdziesz w artykule Cztery zasady WCAG na przykładzie sklepu internetowego.
Jakie są ograniczenia automatycznych narzędzi i widgetu?
Automatyczne skanery mogą wykryć część problemów, na przykład pusty link lub brak określonego języka dokumentu. Nie ocenią jednak wiarygodnie, czy nagłówek naprawdę opisuje następującą po nim treść albo czy nazwa linku jest zrozumiała w procesie zakupowym. Potrzebna jest ocena człowieka i test zadania.
Podobnie widget dostępności może wspierać użytkownika w indywidualnym odbiorze strony, lecz nie gwarantuje zgodności z WCAG, EN 301 549 ani Polskim Aktem o Dostępności. Nie zastępuje audytu WCAG, testów z użytkownikami, naprawy kodu, poprawy treści i weryfikacji komponentów. Uczciwe rozróżnienie tych ról omawia tekst Widget dostępności a zgodność z WCAG: uczciwe porównanie.
Jeżeli prowadzisz e-commerce, warto równolegle uporządkować informacje o dostępności usługi oraz sprawdzić, które wymagania dotyczą Twojej działalności. Pomocne będą materiały: Czy Polski Akt o Dostępności dotyczy sklepu online? oraz Informacja o dostępności usługi: co opisać w regulaminie sklepu?. Ten artykuł ma charakter informacyjny i nie stanowi porady prawnej.
Dostępna karta produktu w sklepie
Podsumowanie dla zarządzającego i sprzedaży
Najbardziej opłacalna zmiana to włączenie semantyki do zwykłego procesu publikacji i rozwoju strony. Autor treści powinien wiedzieć, kiedy użyć H2 i H3 oraz jak nazwać link. Projektant powinien nie wymuszać komunikacji opartej wyłącznie na położeniu lub kolorze. Deweloper powinien wdrożyć natywne elementy HTML, logiczny fokus i przewidywalne komponenty. Osoba odpowiedzialna za sprzedaż lub obsługę klienta powinna zweryfikować ścieżki, które prowadzą do zakupu, kontaktu, zwrotu i reklamacji.
To podejście poprawia zrozumiałość dla użytkowników czytników ekranu, ale też dla osób korzystających z klawiatury, telefonu, powiększenia czy złożonej strony w pośpiechu. Dodaj funkcje dostępności i przetestuj WCAGbot na własnym przykładzie: Dodaj funkcje dostępności.
FAQ: nagłówki i linki a dostępność strony
Czy na stronie może być więcej niż jeden nagłówek H1?
W nowoczesnym HTML są sytuacje, w których więcej niż jeden H1 może zostać użyty technicznie poprawnie. W praktyce redakcyjnej i e-commerce najczytelniejsze jest jednak jedno H1 opisujące główny temat widoku, na przykład nazwę produktu, kategorii albo artykułu.
Czy mogę używać nagłówka tylko po to, aby powiększyć tekst?
Nie. Nagłówek powinien oznaczać tytuł sekcji. Jeżeli potrzebujesz jedynie większego tekstu, zmień styl CSS zwykłego akapitu lub innego elementu, bez nadawania mu nieprawdziwej roli w strukturze dokumentu.
Czy pominięcie poziomu nagłówka zawsze łamie WCAG?
Nie każda przerwa w numeracji poziomów automatycznie oznacza niezgodność. Może jednak utrudniać zrozumienie hierarchii. Należy ocenić, czy nagłówki rzeczywiście opisują relacje między sekcjami i czy są użyte konsekwentnie.
Dlaczego „kliknij tutaj” jest problemem?
Taki tekst nie mówi, dokąd prowadzi link. W liście linków użytkownik może usłyszeć wiele identycznych komunikatów i nie rozpoznać celu. Lepiej nazwać zasób albo działanie, na przykład „Otwórz warunki dostawy”.
Czy link do PDF powinien zawierać informację o formacie?
Zwykle tak, szczególnie gdy użytkownik pobiera dokument lub może potrzebować dodatkowej aplikacji. Dobra nazwa to na przykład „Pobierz instrukcję montażu (PDF)”. Jeżeli rozmiar pliku ma znaczenie dla decyzji użytkownika, można podać go po uprzedniej weryfikacji.
Czy obrazek z tekstem „Czytaj więcej” może być jedynym linkiem?
Nie jest to dobre rozwiązanie. Link powinien mieć dostępną nazwę opisującą cel. Jeżeli obraz jest linkiem, jego tekst alternatywny musi komunikować cel przejścia, a nie tylko opisywać wygląd grafiki.
Czy landmarki ARIA są konieczne, jeśli używam header, nav i main?
Natywne elementy HTML często przekazują odpowiednie role bez dodatkowego ARIA. Najpierw wybieraj właściwy element HTML. ARIA stosuj wtedy, gdy rzeczywiście uzupełnia informację potrzebną dla złożonego komponentu lub niestandardowej struktury.
Jak sprawdzić, czy linki są zrozumiałe dla czytnika ekranu?
Otwórz listę linków w czytniku ekranu lub użyj narzędzia wspierającego taki przegląd. Przeczytaj same nazwy bez otaczających akapitów. Jeżeli nie umiesz przewidzieć celu każdego linku, popraw tekst lub jego programowo dostępny kontekst.
Czy WCAGbot poprawi błędne nagłówki na stronie?
WCAGbot oferuje funkcje wspierające dostępność, między innymi czytanie treści, podświetlanie nagłówków i linków, zmianę kontrastu oraz narzędzia typograficzne. Nie zastępuje jednak trwałej naprawy błędnej hierarchii HTML ani nie gwarantuje zgodności strony z WCAG.
Od której strony sklepu zacząć poprawę semantyki?
Zacznij od ścieżek o największym znaczeniu dla użytkownika: karty produktu, koszyka, płatności, kontaktu, dostawy, zwrotów i reklamacji. Następnie przejdź do kategorii, wyszukiwarki oraz treści poradnikowych.
Czy test klawiaturą wystarczy do oceny strony bez wzroku?
Nie. Test klawiaturą wykrywa ważne bariery dotyczące fokusu i obsługi elementów, ale nie zastępuje sprawdzenia informacji przekazywanych przez czytnik ekranu. Dla kluczowych zadań warto testować konkretne kombinacje, na przykład NVDA i Chrome albo VoiceOver i Safari.
