WCAG 2.4.10: Nagłówki sekcji

Co Oznacza Ta Zasada

WCAG 2.4.10 — Nagłówki sekcji (poziom AAA) stanowi: „Nagłówki sekcji są używane do organizowania treści.” Oznacza to, że gdy strona internetowa lub dokument jest podzielony na wiele odrębnych sekcji, każda sekcja musi mieć programowo rozpoznawalny nagłówek, który opisuje jej temat lub cel. Intencją nie jest jedynie posiadanie wizualnie wystylizowanego tekstu, który wygląda jak nagłówek, lecz użycie rzeczywistego znacznika nagłówka, który przekazuje strukturę hierarchiczną zarówno przeglądarkom, jak i technologiom asystującym.

W HTML oznacza to odpowiednie używanie natywnych elementów nagłówków <h1> do <h6>. Strona z głównym tematem powinna zawierać <h1>, główne sekcje powinny używać <h2>, podsekcje w ich obrębie — <h3> i tak dalej. Poziom nagłówka powinien odzwierciedlać logiczną głębokość treści, a nie być wybierany arbitralnie ze względów czysto wizualnych. Gdy używane jest ARIA, dopuszczalne jest również połączenie role="heading" z aria-level, choć natywne elementy HTML są zawsze preferowane.

Spełnienie tego kryterium oznacza, że każda odrębna sekcja treści na stronie ma nagłówek, który dokładnie opisuje to, co następuje, że nagłówek jest oznaczony semantycznie (a nie tylko wizualnie wystylizowany jako pogrubiony lub duży tekst) oraz że hierarchia nagłówków logicznie odzwierciedla organizację treści dokumentu. Niespełnienie ma miejsce, gdy sekcje treści nie mają w ogóle nagłówka, gdy poziomy nagłówków są pomijane arbitralnie (przeskok z <h1> do <h4> bez logicznego powodu) lub gdy do oznaczania sekcji używany jest zwykły wystylizowany tekst zamiast właściwych elementów nagłówków.

Ważne jest, aby zauważyć oficjalny wyjątek WCAG: to kryterium ma zastosowanie tylko wtedy, gdy sama strona zawiera sekcje. Bardzo krótkie strony z jednym, spójnym tematem — takie jak proste formularze logowania bez wyraźnie odrębnych sekcji — nie muszą mieć wielu nagłówków. Wymóg jest uruchamiany przez obecność wielu odrębnych obszarów treści, które odnoszą korzyść z etykietowania. Dodatkowo, to kryterium nie narzuca konkretnej struktury hierarchii nagłówków poza logiczną organizacją; kluczowym wymaganiem jest to, aby nagłówki istniały i były używane w sposób znaczący wszędzie tam, gdzie istnieją sekcje.

To kryterium jest sklasyfikowane jako poziom AAA, co oznacza, że nie jest wymagane do podstawowej zgodności z WCAG 2.2, ale reprezentuje najlepsze praktyki w zakresie dostępności, które znacząco poprawiają doświadczenie szerokiej grupy użytkowników.

Dlaczego To Ma Znaczenie

Użytkownicy czytników ekranu polegają na nagłówkach jako swoim podstawowym sposobie nawigacji po długich dokumentach i stronach internetowych. Według ankiety WebAIM dotyczącej użytkowników czytników ekranu, zdecydowana większość użytkowników czytników ekranu regularnie nawiguję za pomocą nagłówków — jest to konsekwentnie klasyfikowane jako jedna z najczęściej używanych metod nawigacji. Gdy nagłówki są nieobecne lub nieprawidłowo zbudowane, użytkownik czytnika ekranu musi wysłuchać każdej treści sekwencyjnie od góry strony, co jest odpowiednikiem zmuszenia użytkownika widzącego do przeczytania całej książki bez spisu treści lub tytułów rozdziałów.

Rozważmy przykład z rzeczywistości: turecka strona e-commerce sprzedająca elektronikę może mieć stronę szczegółów produktu z sekcjami obejmującymi specyfikację produktu, opinie klientów, informacje o wysyłce i politykę zwrotów. Jeśli żadna z tych sekcji nie ma elementu nagłówka, niewidomy użytkownik nawigujący za pomocą NVDA w Firefoxie nie może przeskakiwać między nimi. Musi albo wysłuchać całą treść, albo stosować strategię prób i błędów w wyszukiwaniu, co znacząco zwiększa obciążenie poznawcze i czas wykonania zadania. Przy odpowiednich nagłówkach <h2> dla każdej sekcji ten sam użytkownik może nacisnąć klawisz H, aby w ciągu kilku sekund natychmiast przeskakiwać z sekcji do sekcji.

Znacząco korzystają również użytkownicy z niepełnosprawnościami poznawczymi. Jasne nagłówki działają jak drogowskazy, pozwalając osobom z zaburzeniami uwagi, trudnościami w czytaniu lub zaburzeniami pamięci szybko się zorientować po utracie koncentracji. Światowa Organizacja Zdrowia szacuje, że około 1,3 miliarda ludzi na świecie żyje z jakąś formą niepełnosprawności, a schorzenia poznawcze i neurologiczne stanowią dużą i rosnącą część tej populacji.

Użytkownicy z niepełnosprawnościami ruchowymi, którzy polegają na nawigacji wyłącznie za pomocą klawiatury lub urządzeń przełącznikowych, również odnoszą korzyści, ponieważ struktura nagłówków jest używana przez wiele technologii asystujących do tworzenia możliwości pomijania nawigacji, co zmniejsza wysiłek fizyczny potrzebny do dotarcia do pożądanego obszaru treści.

Poza dostępnością dla osób z niepełnosprawnościami, prawidłowa struktura nagłówków ma istotne korzyści SEO. Wyszukiwarki używają hierarchii nagłówków do zrozumienia struktury tematycznej strony, co może wpływać na pozycjonowanie i sposób prezentowania treści w wynikach wyszukiwania. Dobrze zbudowany zarys nagłówków sygnalizuje jakość treści zarówno użytkownikom, jak i robotom indeksującym. To sprawia, że biznesowy argument za wdrożeniem tego kryterium AAA jest przekonujący nawet dla organizacji, które nie są prawnie zobowiązane do jego spełnienia.

Powiązane Reguły Axe-core

WCAG 2.4.10 wymaga testów manualnych i nie może być w pełni zautomatyzowane. Oto dlaczego narzędzia automatyczne zawodzą oraz co mogą, a czego nie mogą wykryć:

• Wymagane testy manualne — kompletność strukturalna: Narzędzia automatyczne, takie jak axe-core, mogą wykryć obecność lub brak elementów nagłówków na stronie oraz zgłosić problemy, takie jak pominięte poziomy nagłówków (np. przeskok z <h1> do <h3>). Nie są jednak w stanie określić, czy treść strony została logicznie podzielona na sekcje ani czy nagłówek dokładnie opisuje sekcję, którą wprowadza. Narzędzie może zobaczyć poprawną hierarchię nagłówków i zaliczyć kontrolę, podczas gdy strona faktycznie ma cztery odrębne sekcje treści, z których trzy nie mają żadnego nagłówka. Semantyczna adekwatność umiejscowienia nagłówków wymaga recenzenta-ludzi, który rozumie cel i strukturę treści.
• Reguła axe-core — heading-order: Ta reguła zgłasza przypadki, w których poziomy nagłówków są pomijane w sposób, który łamie logiczny zarys dokumentu (na przykład przejście bezpośrednio z <h1> do <h4>). Choć jest to powiązany sygnał jakości, spełnienie tej reguły nie gwarantuje zgodności z 2.4.10, ponieważ reguła sprawdza jedynie względną kolejność istniejących nagłówków — nie jest w stanie określić, czy nagłówek brakuje w sekcji, która go potrzebuje.
• Reguła axe-core — page-has-heading-one: Ta reguła sprawdza, czy strona zawiera co najmniej jeden element <h1>, co jest podstawowym wymogiem strukturalnym. Ponownie, spełnienie tego wymogu jest pozytywnym sygnałem, ale nie potwierdza pełnej zgodności z 2.4.10, ponieważ strona może mieć <h1>, a mimo to zawierać wiele nieoznaczonych sekcji poniżej.
• Dlaczego pełna automatyzacja jest niemożliwa: Określenie, czy dany fragment treści stanowi „sekcję”, która wymaga nagłówka, wymaga zrozumienia semantyki i celu treści — zadania, które obecnie wymaga osądu człowieka. Algorytm nie może niezawodnie odróżnić spójnego akapitu, który naturalnie kontynuuje to, co go poprzedza, od rzeczywiście nowego obszaru tematycznego, który zasługuje na własny, oznaczony nagłówek. Dlatego 2.4.10 jest zawsze wymieniane jako wymagające oceny manualnej w każdym kompleksowym audycie.

Jak Testować

1. Automatyczne skanowanie za pomocą axe DevTools lub Lighthouse: Zainstaluj rozszerzenie przeglądarki axe DevTools (dostępne dla Chrome i Firefox) i uruchom skan całej strony. Przejrzyj wszelkie problemy związane z heading-order i page-has-heading-one. Zauważ, że czysty wynik skanowania automatycznego nie potwierdza zgodności z WCAG 2.4.10 — usuwa jedynie automatyzowalny podzbiór kontroli. Lighthouse w Chrome DevTools również pokazuje problemy związane z nagłówkami w audycie Accessibility; szukaj ostrzeżeń „Heading elements are not in a sequentially-descending order”.
2. Manualny przegląd treści — zarys dokumentu: Użyj rozszerzenia przeglądarki, takiego jak HeadingsMap (dostępne dla Chrome i Firefox), aby wygenerować wizualny zarys wszystkich elementów nagłówków na stronie. Krytycznie przeanalizuj ten zarys: czy dokładnie odzwierciedla strukturę treści strony? Czy każda odrębna sekcja jest reprezentowana przez nagłówek? Czy istnieją sekcje treści widoczne na stronie, które nie pojawiają się w zarysie? Jeśli tak, tym sekcjom brakuje nagłówków i strona nie spełnia 2.4.10.
3. Nawigacja czytnikiem ekranu z NVDA i Firefoxem: Otwórz stronę w Firefoxie z uruchomionym NVDA. Naciśnij H, aby przeskakiwać do przodu między nagłówkami, oraz Shift+H, aby przechodzić wstecz. Gdy trafiasz na każdy nagłówek, zanotuj, czy ogłoszony nagłówek dokładnie opisuje treść, która po nim następuje. Zwróć też uwagę, czy napotykasz jakieś znaczące bloki treści, które nigdy nie są ogłaszane jako znajdujące się pod nagłówkiem. Otwórz listę elementów NVDA (NVDA+F7), wybierz kartę Headings i przejrzyj pełną listę nagłówków, aby wykryć brakujące lub błędnie oznaczone sekcje.
4. Nawigacja czytnikiem ekranu z VoiceOver i Safari (macOS/iOS): W macOS włącz VoiceOver (Command+F5) i otwórz stronę w Safari. Użyj VO+Command+H, aby nawigować po nagłówkach. W iOS użyj rotora (przeciągnij dwoma palcami, aby ustawić go na Headings), a następnie przeciągaj w dół, aby przechodzić między nagłówkami. Zweryfikuj, że wszystkie sekcje treści są osiągalne za pomocą nawigacji po nagłówkach.
5. Nawigacja czytnikiem ekranu z JAWS i Chrome: W JAWS naciśnij H, aby przechodzić między nagłówkami, oraz otwórz listę nagłówków za pomocą Insert+F6. Przejrzyj listę pod kątem kompletności i logicznej hierarchii. Potwierdź, że nagłówki nie są używane wyłącznie do stylowania — jako nagłówki powinny pojawiać się tylko rzeczywiste etykiety sekcji.
6. Kontrola nawigacji wyłącznie klawiaturą: Używając wyłącznie klawiatury, spróbuj nawigować po wszystkich głównych sekcjach strony bez używania nagłówków. Zwróć uwagę, ile razy musisz nacisnąć Tab, aby dotrzeć do każdej sekcji. Daje to wyobrażenie o obciążeniu nakładanym na użytkowników klawiatury, gdy brakuje prawidłowej struktury nagłówków.

Jak Naprawić

Sekcje oznaczone wyłącznie wystylizowanym tekstem — Niepoprawne

<div class='section'>
  <p class='section-title'>Product Specifications</p>
  <p>Screen size: 15.6 inches</p>
  <p>RAM: 16 GB</p>
</div>

<div class='section'>
  <p class='section-title'>Customer Reviews</p>
  <p>This product exceeded my expectations.</p>
</div>

Sekcje oznaczone wyłącznie wystylizowanym tekstem — Poprawne

<!-- Using semantic heading elements makes sections navigable by screen readers -->
<section>
  <h2>Product Specifications</h2>
  <p>Screen size: 15.6 inches</p>
  <p>RAM: 16 GB</p>
</section>

<section>
  <h2>Customer Reviews</h2>
  <p>This product exceeded my expectations.</p>
</section>

Pomijanie poziomów nagłówków ze względów stylistycznych — Niepoprawne

<h1>Annual Report 2024</h1>
<!-- h4 used here because it looks smaller visually, skipping h2 and h3 -->
<h4>Financial Overview</h4>
<p>Revenue grew by 12% this year...</p>
<h4>Regional Performance</h4>
<p>The Istanbul region led growth...</p>

Pomijanie poziomów nagłówków ze względów stylistycznych — Poprawne

<h1>Annual Report 2024</h1>
<!-- h2 used for major sections; CSS controls visual size, not heading level -->
<h2>Financial Overview</h2>
<p>Revenue grew by 12% this year...</p>
<h2>Regional Performance</h2>
<p>The Istanbul region led growth...</p>

Brak nagłówka dla głównej sekcji strony — Niepoprawne

<main>
  <h1>Contact Us</h1>
  <form>
    <label for='name'>Name</label>
    <input type='text' id='name' name='name'>
    <label for='message'>Message</label>
    <textarea id='message' name='message'></textarea>
    <button type='submit'>Send</button>
  </form>
  <!-- This office locations section has no heading -->
  <div>
    <p>Istanbul Office: Levent Mah. No:5</p>
    <p>Ankara Office: Kızılay Mah. No:12</p>
  </div>
</main>

Brak nagłówka dla głównej sekcji strony — Poprawne

<main>
  <h1>Contact Us</h1>
  <section>
    <h2>Send Us a Message</h2>
    <form>
      <label for='name'>Name</label>
      <input type='text' id='name' name='name'>
      <label for='message'>Message</label>
      <textarea id='message' name='message'></textarea>
      <button type='submit'>Send</button>
    </form>
  </section>
  <!-- Office locations section now has a descriptive heading -->
  <section>
    <h2>Our Offices</h2>
    <p>Istanbul Office: Levent Mah. No:5</p>
    <p>Ankara Office: Kızılay Mah. No:12</p>
  </section>
</main>

Rola nagłówka ARIA użyta bez aria-level — Niepoprawne

<!-- role=heading without aria-level defaults to level 2, which may be wrong -->
<div role='heading'>Shipping Policy</div>
<p>Orders are shipped within 2 business days...</p>

Rola nagłówka ARIA użyta bez aria-level — Poprawne

<!-- Native HTML is strongly preferred; if ARIA is used, aria-level must be explicit -->
<!-- Preferred: -->
<h2>Shipping Policy</h2>
<p>Orders are shipped within 2 business days...</p>

<!-- Acceptable when native heading cannot be used: -->
<div role='heading' aria-level='2'>Shipping Policy</div>
<p>Orders are shipped within 2 business days...</p>

Typowe Błędy

• Używanie klas CSS, takich jak .title lub .section-header na elementach <p> lub <div> zamiast rzeczywistych elementów <h1>–<h6>: Samo stylowanie wizualne nie komunikuje struktury technologiom asystującym. Nagłówek musi być rzeczywistym elementem nagłówka lub mieć prawidłową rolę ARIA heading z określonym poziomem.
• Dobieranie poziomów nagłówków na podstawie rozmiaru czcionki, a nie hierarchii dokumentu: Wybranie <h4> dlatego, że renderuje się w pożądanym rozmiarze wizualnym, gdy logicznie powinien to być <h2>, łamie zarys dokumentu i dezorientuje użytkowników czytników ekranu, którzy słyszą „heading level 4” bez poprzedzających poziomów 2 lub 3.
• Stosowanie nadpisań font-size lub font-weight w celu wizualnego zmniejszenia <h1> zamiast użycia nagłówka niższego poziomu: Tworzy to rozbieżność między hierarchią wizualną a semantyczną; używaj CSS do kontrolowania rozmiaru, a natywnych poziomów nagłówków do przekazywania struktury.
• Pomijanie nagłówków w dynamicznie ładowanych sekcjach treści (np. panele kart, okna modalne lub wyniki ładowane przez AJAX): Gdy nowa treść jest wstrzykiwana na stronę, często brakuje jej struktury nagłówków. Każda dynamicznie renderowana sekcja powinna zawierać odpowiedni nagłówek, aby użytkownicy nawigujący po nagłówkach nie byli uwięzieni w nieoznaczonej wyspie treści.
• Używanie tylko jednego <h1> dla tytułu strony i brak dalszych nagłówków na stronie z pięcioma lub więcej odrębnymi sekcjami treści: Istnienie <h1> spełnia kontrole automatyczne, ale nie wypełnia 2.4.10, jeśli kolejne główne sekcje są nieoznaczone.
• Zagnieżdżanie nagłówków wewnątrz elementów <button> lub <a>: Umieszczanie nagłówka wewnątrz elementu interaktywnego tworzy konflikt ról dla technologii asystujących i jest nieprawidłowym HTML. Nagłówki powinny oznaczać sekcje treści, a nie kontrolki interaktywne.
• Używanie role='heading' bez określenia aria-level: Domyślny poziom ARIA to 2, co może nie odpowiadać zamierzonej strukturze dokumentu i po cichu spowoduje nieprawidłowy zarys, jeśli sekcja jest na innym poziomie.
• Dodawanie dekoracyjnych lub powtarzających się nagłówków — np. powtarzanie tytułu strony jako <h2> wewnątrz każdej karty treści — które tworzą „szum nagłówków” bez realnej wartości nawigacyjnej: Nagłówki powinny w sposób unikalny i dokładny opisywać sekcję, którą wprowadzają; nadmiarowe nagłówki osłabiają użyteczność nawigacji po nagłówkach dla użytkowników czytników ekranu.
• Ukrywanie nagłówków wizualnie za pomocą display:none lub visibility:hidden w próbie zapewnienia struktury tylko dla czytników ekranu: Te właściwości CSS również ukrywają element przed technologiami asystującymi. Użyj standardowej techniki „visually-hidden” (position:absolute; width:1px; height:1px; overflow:hidden; clip:rect(0,0,0,0);), jeśli nagłówek ma być obecny w drzewie dostępności, ale niewidoczny na ekranie.
• Brak aktualizacji struktury nagłówków, gdy treść strony jest reorganizowana podczas redesignu: Nagłówki dodane podczas początkowego rozwoju są często pozostawiane w niezmienionej formie, gdy sekcje treści są przestawiane, scalane lub zastępowane. Audyty nagłówków powinny być częścią każdego cyklu przeglądu treści lub projektu, a nie jednorazową poprawką dostępności.

Związek z Tureckimi Regulacjami Dotyczącymi Dostępności

Turecka Okrężnica Prezydencka 2025/10, opublikowana w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia kompleksowe obowiązki w zakresie dostępności cyfrowej dla szerokiego zakresu podmiotów działających w Turcji. Okrężnica przyjmuje WCAG 2.2 jako standard techniczny dla zgodności z wymogami dostępności cyfrowej i ma zastosowanie do instytucji publicznych, platform e-commerce, banków i instytucji finansowych, szpitali i świadczeniodawców opieki zdrowotnej, firm telekomunikacyjnych z 200,000 lub większą liczbą abonentów, biur podróży, prywatnych firm transportowych oraz szkół prywatnych upoważnionych przez Ministerstwo Edukacji Narodowej (MoNE).

WCAG 2.4.10 — Nagłówki sekcji jest kryterium poziomu AAA. Oznacza to, że nie należy do minimalnych prawnie wymaganych kryteriów w ramach okrężnicy, która nakazuje zgodność na poziomach A i AA dla objętych podmiotów. Jednak szerszą intencją okrężnicy jest zapewnienie znaczącego dostępu cyfrowego dla wszystkich użytkowników, a kryteria poziomu AAA, takie jak 2.4.10, są wyraźnie uznawane za reprezentujące najlepsze praktyki w zakresie dostępności.

Dla objętych podmiotów — w szczególności instytucji publicznych, banków, szpitali i dużych dostawców usług telekomunikacyjnych — wdrożenie WCAG 2.4.10 pokazuje zaangażowanie w dostępność wykraczające poza minimum regulacyjne. W praktyce dobrze zbudowane hierarchie nagłówków są również warunkiem wstępnym dla kilku kryteriów sukcesu na poziomie AA (takich jak 1.3.1 Informacje i relacje oraz 2.4.6 Nagłówki i etykiety), co oznacza, że organizacje dążące do pełnej zgodności na poziomie AA naturalnie zbliżą się do spełnienia 2.4.10 w ramach tego wysiłku.

Wyspecjalizowane usługi skierowane do użytkowników z niepełnosprawnościami lub usługi cyfrowe oferowane przez instytucje publiczne obsługujące zróżnicowane populacje obywateli, w tym osoby starsze, osoby z niepełnosprawnościami poznawczymi lub użytkowników technologii asystujących, w szczególności skorzystają z pełnego wdrożenia 2.4.10. Rosnący nacisk Turcji na usługi e-administracji (e-devlet) oraz rozwój e-commerce sprawiają, że solidna struktura treści jest nie tylko wymogiem dostępności, ale także priorytetem w zakresie użyteczności i zarządzania ryzykiem prawnym.

Organizacje w Turcji, które dobrowolnie certyfikują się na poziomie WCAG 2.2 AAA — w tym 2.4.10 — pozycjonują się jako liderzy w dziedzinie dostępności, co wspiera zaufanie do marki, zmniejsza ryzyko sporów sądowych i poszerza ich potencjalną grupę odbiorców o szacowane 8.5 miliona osób z niepełnosprawnościami w Turcji, zgodnie z danymi Tureckiego Instytutu Statystycznego (TÜİK).