Trafiłem dzisiaj na filmik Święte Wojny JavaScriptu – ile 'h1′ na stronie i dlaczego Kuba przespał ostatnie 10 lat?, poświęcony nagłówkowi h1.
Punktem wyjściowym dla dyskusji było pytanie o to, ile nagłówków h1 można stosować na stronie. Głównym argumentem, zarówno po jednej, jak i drugiej strony, było pozycjonowanie strony w wyszukiwarkach. Jak już jednak wielokrotnie wspominałem, to, że nagłówki służą do pozycjonowania, jest jedynie skutkiem ubocznym. Nagłówki służą do tworzenia struktury strony – co, na szczczęście, również zostało wspomniane w dyskusji.
Jednak samo stwierdzenie, że nagłówki służą do tworzenia struktury strony, jest niewystarczające. Należałoby zapytać, jaki jest tego skutek. Najważniejszym powodem, dla którego należy wykorzystywać poprawnie nagłówki, jest dostępność. Jeśli spojrzymy na wyniki najnowszej ankiety wśród użytkowników czytników ekranowych, zauważymy, że ponad 67% z nich używa nagłówków do nawigacji po stronie. Dodatkowo aż ponad 85% uważa, że poziomy nagłówków są pomocne, z czego ponad 52%, że są bardzo pomocne. Dodatkowo jedna z wcześniejszych ankiet wśród użytkowników czytników ekranowych, przeprowadzona w 2017 roku, zawierała pytanie na temat struktury nagłówków na stronie. Aż 60% osób wskazało, że najłatwiejsza w nawigacji jest struktura, w której nagłówek h1 zawiera tytuł danej podstrony. Inna ankieta, przeprowadzona wśród małej grupy (35 osób) użytkowników czytników ekranowych, potwierdza te wyniki.
Większość debat dotyczących stosowania więcej niż jednego elementu h1 ma swoje źródło w tzw. algorytmie outline’u, który zakładał, że dla każdej sekcji na stronie nagłówki będą liczone oddzielnie. Problem polega na tym, że ten algorytm nigdy nie został zaimplementowany w przeglądarkach. Tym samym stosowanie więcej niż jednego nagłówka h1 na stronie prowadzi do stworzenia płaskiej struktury treści. A taka jest trudniejsza w nawigacji, nie tylko dla użytkowników czytników ekranowych. Przy porównywaniu struktury nagłówków na stronie do spisu treści w książce warto pamiętać o jednym: strona internetowa nie jest odpowiednikiem strony w książce. Każda strona jest raczej odpowiednikiem całego rozdziału. Tak, jak rozdział, ma jeden główny tytuł (nagłówek h1) oraz liczne podrozdziały, podsekcje, itp. (nagłówki h2–h6. Przy takim spojrzeniu o wiele łatwiej dzielić treść przy pomocy nagłówków oraz zauważyć, że faktycznie jedno h1 ma sporo sensu.
W trakcie dyskusji pada też twierdzenie, że dokumentacje W3C
zwykle zawierają przykłady z jednym h1 i nie są aktualizowane od 10 lat. To twierdzenie jest błędne na kilku poziomach. Po pierwsze, nie istnieje oficjalna dokumentacja HTML-a od W3C, bo W3C nie rozwija już HTML-a. Teraz zajmuje się tym WHATWG. I oficjalna specyfikacja zawiera sporo przykładów, w których jest kilka elementów h1. Takie można znaleźć np. w podrozdziale poświęconym elementowi section. Sama specyfikacja jest z kolei aktualizowana praktycznie codziennie (kiedy piszę te słowa 15 grudnia, specyfikacja była zaktualizowana wczoraj, 14 grudnia 2021 roku).
Istnieje jednak problem ze specyfikacją i nagłówkami: eksperci dostępności od lat powtarzają, że specyfikacja niepoprawnie opisuje nagłówki, ponieważ zakłada istnienie algorytmu outline’u. A, jak wspominałem wyżej, on w rzeczywistości nie istnieje. Na szczęście MDN (czyli zasób, do którego trafi zdecydowanie więcej osób niż do specyfikacji) zawiera informację, dlaczego należy stosować tylko jeden nagłówek h1.
Nie mogę się zgodzić także ze stwierdzeniem, że nagłówki powstały w czasach, gdy HTML nie był semantyczny. HTML zawsze był semantyczny, bo semantyka to znaczenie elementów. A każdy element w HTML coś znaczy i zawsze poszczególne elementy miały jakąś przypisaną sobie rolę.
Smuci mnie, że pewne tematy w webdevie (nie tylko polskim) wałkowane są na nowo i nowo. I za każdym razem dyskusja zaczyna się od zera. A przecież problem z nagłówkami nie pojawił się wczoraj, istnieje od niemal samego momentu powstania HTML5. Przez to, że mamy do czynienia z tak długo istniejącym problemem, powstało naprawdę sporo materiałów go opisujących oraz mamy odpowiednie dane, by go zanalizować. Skoro takie materiały są dostępne, to wypada zadać sobie pytanie, czemu tego typu dyskusje nie są oparte na źródłach, a prawie zawsze wyłącznie na opiniach osób biorących w nich udział?
Duża część dostępnościowców ma obsesję na temat nagłówków. Zasadniczo zgadzają się, że powinien być jeden H1 na podstronie, ale wskazują wyjątki. Ja nabrałem dużego sceptycyzmu do tego tematu. Dla mnie nagłówki są przydatne, ale nie kluczowe. Ich obecność lub brak wpływa na semantykę i lepiej, jeżeli są. Jednak toczenie na ten temat wojen jest IMO głupie, gdy do rozwiązania są prawdziwe problemy. Nagłówki pomagają, jak to wykazało badanie WebAIM i sam ich używam. Bez nich jednak nadal można korzystać ze strony internetowej. Tymczasem – brak obsługi klawiaturą, brak napisów, elementy nawigacyjne bez etykiet tekstowych lub skoczna polka podczas przeglądania strony są prawdziwymi barierami. Tylko ich nie można wyłapać automatami…
Jak najbardziej się zgadzam – istnieją o wiele poważniejsze problemy z dostępnością niż nagłówki. Niemniej jeśli już dyskutujemy o nagłówkach, to uważam, że dobrze jest sięgnąć do źródeł, które powstały przez lata i pokazują, dlaczego jeden nagłówek h1 zwykle jest lepszym rozwiązaniem. Dyskusja o nagłówkach bez poruszania kontekstu dostępności jest dla mnie w dużej mierze dyskusją obok problemu.
Jak sam przyznajesz, specyfikacja zmienia się praktycznie codziennie oraz są w niej błędy w założeniach.
Wchodząc na stronę https://validator.w3.org/ i poddając tam Twój blog validacji [ https://www.webkrytyk.pl/ ], sypie błędami.
Tak jak strona nie może i nie powinna wygladać tak samo w każdej przeglądarce – bo jest to niemożliwe – tak samo nie zanosi się na jedno konkretne rozwiązanie w HTML i trzeba zachować tylko i wyłacznie złoty środek aby nie zwariować i sprawić aby nasze strony były użyteczne najbardziej jak się tylko da.
Nie rozumiem, co ma jedno do drugiego? I nie ma w niej błędów w założeniach (nie bardzo wiem, jakie założenia mógłby mieć HTML), tylko redaktorzy nie zgadzają się na usunięcie stworzonego lata temu algorytmu outline’u. Algorytmu, którego nikt nie chciał i ostatecznie nie zaimplementował.
Nie, nie ma ani jednego błędu, są co najwyżej ostrzeżenia – i to w większości związane z niepominięciem domyślnych wartości dla atrybutu [type]. Poza tym – nie rozumiem, co to ma udowadniać?
Myślę, że mieszasz tu dwie rzeczy. Tak, stron nie powinna wyglądać tak samo w każdej przeglądarce – czy to związku z jej różnym wsparciem dla ficzerów, czy choćby innym viewportem. Ale równocześnie: jeśli obydwie przeglądarki wspierają ficzery użyte do stworzenia strony i działają w takim samym środowisku (ta sama metoda inputu, ten sam viewport, te same ustawienia ograniczania ruchu czy ciemnego motywu itd.), to te strony _powinny_ wyglądać tak samo w tych przeglądarkach – bo po to mamy standaryzację.
Sporo problemów w HTML-u ma konkretne rozwiązania, które od lat są jedyne i niezmienne (np. oznaczanie tytułów dzieł przy pomocy cite, dane adresowe w address itd.). Dla sporej liczby pozostałych są stworzone dobre praktyki, zwykle oparte na gruntownym riserczu. Taki risercz jest zrobiony także w kwestii nagłówków i „złotym środkiem” jest właśnie stosowanie jednego h1 na stronę.