WCAG 2.4.6: Nagłówki i etykiety

Co Oznacza Ta Zasada

WCAG 2.4.6 stwierdza: „Nagłówki i etykiety opisują temat lub cel.” W istocie kryterium to wymaga, aby każdy nagłówek (<h1> do <h6>) lub etykieta (<label>, aria-label, aria-labelledby), który pojawia się na stronie, był na tyle opisowy, by przekazać temat treści, którą wprowadza, lub cel kontrolki, którą identyfikuje.

Kryterium to nie wymaga, aby nagłówki lub etykiety w ogóle były obecne — ten obowiązek jest objęty innymi kryteriami sukcesu, takimi jak 1.3.1 (Informacje i relacje) oraz 2.4.2 (Tytuł strony). To, czym zajmuje się 2.4.6, to jakość nagłówków i etykiet, które już istnieją: jeśli je masz, muszą być znaczące. Nagłówek „Sekcja 1” lub etykieta „Pole” nie mówi użytkownikom niczego użytecznego o treści, która następuje, ani o wprowadzanych danych, które opisuje. Zestaw to z „Twój adres dostawy” lub „Miesięczne podsumowanie budżetu”, które natychmiast orientują użytkowników.

Etykiety w tym kontekście obejmują nie tylko element HTML <label> powiązany z kontrolkami formularza, ale także każdy programistyczny mechanizm etykietowania: aria-label, aria-labelledby, atrybut title używany jako nazwa dostępna oraz element legend dla fieldsetów. Każdy z nich, jeśli jest ujawniony technologiom asystującym, musi jasno opisywać cel powiązanej kontrolki.

Do niepowodzenia dochodzi, gdy nagłówek lub etykieta są tak ogólne, niejednoznaczne lub nieinformacyjne, że użytkownik nie może ustalić, czego dotyczy sekcja lub kontrolka, bez przeczytania otaczającego kontekstu. Na przykład formularz z trzema polami, z których każde jest oznaczone „Wpisz tutaj”, nie spełnia tego kryterium, podobnie jak strona, która używa powtarzających się nagłówków, takich jak „Więcej informacji” dla każdej podsekcji. Również nagłówek, który jest technicznie obecny w DOM, ale całkowicie wprowadza użytkownika w błąd — na przykład oznaczenie sekcji formularza kontaktowego nagłówkiem „Aktualności i nowości” — jest niepowodzeniem.

Istnieje jeden ważny oficjalny wyjątek: WCAG 2.4.6 ma zastosowanie tylko wtedy, gdy nagłówki i etykiety są używane. Jeśli strona w sposób uzasadniony nie ma nagłówków (na przykład bardzo krótki dokument z jednym tematem) lub kontrolka formularza nie ma widocznej ani programistycznej etykiety (co zostałoby wychwycone przez 1.3.1), samo 2.4.6 nie ma zastosowania. Zakres kryterium dotyczy ściśle opisowości, a nie obecności.

Dlaczego To Ma Znaczenie

Opisowe nagłówki i etykiety przynoszą korzyści niezwykle szerokiej grupie odbiorców, ale ich wpływ jest najbardziej odczuwalny dla osób z niepełnosprawnościami, które polegają na strukturze podczas nawigacji.

Użytkownicy czytników ekranu — głównie osoby niewidome lub z poważnymi ubytkami wzroku — rutynowo nawigują po stronach, przeskakując od nagłówka do nagłówka za pomocą klawiszy skrótów (H w NVDA/JAWS, Rotor w VoiceOver). Jeśli nagłówki są niejasne lub mylące, ta strategia nawigacji całkowicie się załamuje. Osoba niewidoma trafiająca na portal usług publicznych, który używa nagłówków „Sekcja A”, „Sekcja B” i „Sekcja C”, musi przeczytać każde słowo każdej sekcji po kolei, aby znaleźć to, czego potrzebuje, co eliminuje przewagę efektywności, jaką nagłówki powinny zapewniać. Według Światowej Organizacji Zdrowia około 2,2 miliarda ludzi na całym świecie ma jakąś formę upośledzenia wzroku, co stanowi znaczną populację globalną.

Osoby z niepełnosprawnościami poznawczymi, w tym z zaburzeniami uwagi, zaburzeniami pamięci lub trudnościami w uczeniu się, w dużym stopniu polegają na jasnych, przewidywalnych etykietach i nagłówkach, aby zmniejszyć obciążenie poznawcze. Gdy pole formularza jest oznaczone jedynie „Imię i nazwisko” na stronie, która zbiera zarówno nazwę firmy, jak i imię i nazwisko osoby kontaktowej, użytkownik z niepełnosprawnością poznawczą może nie być w stanie rozwiązać tej niejednoznaczności wyłącznie z kontekstu, co prowadzi do błędów i frustracji.

Użytkownicy z niepełnosprawnościami ruchowymi, którzy polegają na przełącznikach, oprogramowaniu do śledzenia wzroku lub sterowaniu głosem (takim jak Dragon NaturallySpeaking), odnoszą korzyści z opisowych etykiet, ponieważ mogą aktywować konkretne pole formularza, wypowiadając jego nazwę etykiety. Jeśli wiele pól ma tę samą treść etykiety, oprogramowanie do sterowania głosem nie może ich rozróżnić, zmuszając użytkownika do dodatkowych kroków, które są fizycznie obciążające.

Rozważ scenariusz z życia wzięty: osoba korzystająca z czytnika ekranu odwiedza stronę kasy w serwisie e-commerce. Strona zawiera trzy sekcje adresowe — adres rozliczeniowy, adres dostawy i adres obdarowanego — ale każda sekcja używa tego samego ogólnego nagłówka „Adres”, a każdy zestaw pól używa tych samych etykiet: „Ulica”, „Miasto”, „Kod pocztowy”. Bez unikalnych, opisowych nagłówków i etykiet użytkownik czytnika ekranu nie może ustalić, którą grupę pól wypełnia, co dramatycznie zwiększa ryzyko błędów przy zamówieniu i prawdopodobieństwo całkowitego porzucenia zakupu.

Poza dostępnością, opisowe nagłówki zapewniają znaczną wartość SEO. Wyszukiwarki używają struktury nagłówków jako silnego sygnału do zrozumienia treści strony i dopasowania jej do zapytań użytkowników. Znaczące nagłówki pomagają wyszukiwarkom dokładniej indeksować strony i mogą poprawić współczynniki klikalności w wynikach wyszukiwania, gdzie nagłówki są często prezentowane jako tekst podglądu. To bezpośrednio wyrównuje interesy biznesowe z wymaganiami dostępności.

Powiązane Reguły Axe-core

WCAG 2.4.6 wymaga testów manualnych, ponieważ żadne narzędzie automatyczne nie jest w stanie wiarygodnie określić, czy nagłówek lub etykieta są opisowe. Opisowość jest oceną semantyczną i kontekstową — nagłówek „Produkty” może być całkowicie opisowy na jednej stronie i zupełnie niejednoznaczny na innej. Skanery automatyczne mogą wykryć obecność lub brak nagłówków i etykiet, ale nie są w stanie ocenić, czy tekst tych nagłówków i etykiet jest znaczący bez interpretacji przez człowieka.

• Ręczny przegląd tekstu nagłówków: Axe-core oznaczy brakujące nagłówki lub nieprawidłowe zagnieżdżenie (za pomocą reguł takich jak heading-order), ale nie jest w stanie oznaczyć nagłówka „Kliknij tutaj” lub „Sekcja bez tytułu” jako naruszenia 2.4.6. Tester musi przeczytać każdy nagłówek w izolacji — tak, jak użytkownik czytnika ekranu napotkałby go, nawigując po nagłówkach — i ocenić, czy komunikuje on temat treści poniżej.
• Ręczny przegląd tekstu etykiet formularzy: Reguła label w axe-core weryfikuje, że każdy element formularza ma powiązaną etykietę, ale nie ocenia, czy tekst tej etykiety jest opisowy. Element label, który zawiera jedynie znak zastępczy, znak ikony lub ogólne słowo, takie jak „Wejście”, przejdzie testy automatyczne, a mimo to nie spełni 2.4.6. Ręczny przegląd wymaga przeczytania każdej etykiety i potwierdzenia, że dokładnie opisuje ona cel powiązanej kontrolki.
• Ręczny przegląd wartości aria-label i aria-labelledby: Podobnie, rodzina reguł axe-core aria-label-is-accessible potwierdza, że etykiety ARIA są składniowo poprawne i że istnieją elementy, do których się odwołują, ale nie ocenia, czy tekst etykiety jest semantycznie znaczący lub opisowy dla celu kontrolki.
• Wykrywanie zduplikowanych etykiet: Chociaż niektóre narzędzia mogą oznaczać zduplikowany tekst etykiet na stronie, nie są w stanie określić, czy duplikacja jest zamierzona i odpowiednia (dwa pola o tym samym celu w różnych wierszach tabeli), czy też stanowi rzeczywiste niepowodzenie w zakresie opisowości, gdzie wiele różnych kontrolek ma tę samą niejednoznaczną etykietę. Do rozróżnienia tych sytuacji potrzebny jest przegląd manualny.

Jak Testować

1. Najpierw uruchom skan automatyczny: Użyj axe DevTools (rozszerzenie przeglądarki) lub Lighthouse w Chrome DevTools, aby zidentyfikować wszelkie strukturalne problemy z nagłówkami lub etykietami, które narzędzia automatyczne mogą wychwycić, takie jak brakujące etykiety, pominięte poziomy nagłówków lub puste elementy nagłówków. Choć nie są to bezpośrednie naruszenia 2.4.6, wskazują obszary, które należy dokładniej zbadać podczas przeglądu manualnego. Zanotuj każdy nagłówek i oznaczoną kontrolkę, które zostały wskazane w raporcie.
2. Wyodrębnij listę nagłówków: Użyj rozszerzenia przeglądarki, takiego jak HeadingsMap (dostępne dla Firefox i Chrome) lub narzędzia WAVE, aby wygenerować płaską listę wszystkich nagłówków na stronie, pozbawioną otaczającej treści. Przeczytaj tę listę tak, jakby była spisem treści. Zadaj pytanie: czy użytkownik mógłby zrozumieć strukturę i główne tematy tej strony wyłącznie na podstawie nagłówków, bez czytania tekstu głównego? Jeśli którykolwiek nagłówek jest niejednoznaczny lub nieinformacyjny w izolacji, jest to niepowodzenie 2.4.6.
3. Testuj z NVDA i Firefox: Otwórz stronę i naciśnij H, aby nawigować po nagłówkach. Wysłuchaj zapowiedzi każdego nagłówka i oceń, czy opisuje on treść, która następuje. Następnie naciśnij F, aby przechodzić między polami formularza i wysłuchaj etykiety ogłaszanej dla każdego pola. Zanotuj każdy nagłówek lub etykietę, które nie opisują jasno swojego tematu lub celu.
4. Testuj z VoiceOver i Safari (macOS/iOS): Użyj Web Rotor (VO+U), aby otworzyć listę nagłówków i listę kontrolek formularza. Przejdź przez każdą listę i oceń opisowość każdego elementu niezależnie od kontekstu strony. Na iOS użyj przesunięcia trzema palcami, aby nawigować po nagłówkach w Rotorze.
5. Testuj z JAWS i Chrome: Naciśnij H, aby nawigować po nagłówkach, i użyj Forms Mode (F), aby przechodzić między kontrolkami formularza. Użyj okna dialogowego List of Headings w JAWS (Insert+F6), aby wyświetlić wszystkie nagłówki w płaskiej liście, co odzwierciedla sposób, w jaki użytkownik czytnika ekranu skanowałby strukturę strony.
6. Oceń etykiety formularzy w izolacji: Dla każdej kontrolki formularza zasłoń lub zignoruj cały otaczający kontekst i przeczytaj tylko programistyczną etykietę (widoczny tekst etykiety, aria-label lub element docelowy aria-labelledby). Potwierdź, że sama etykieta wystarcza, aby zrozumieć, jakie informacje należy wprowadzić lub jaką akcję wykonuje kontrolka.
7. Sprawdź zduplikowany tekst nagłówków lub etykiet: Wyszukaj na stronie powtarzający się tekst nagłówków (np. wiele nagłówków „Czytaj więcej” lub wiele sekcji „Dowiedz się więcej”). Jeśli ten sam tekst jest używany dla nagłówków lub etykiet odnoszących się do różnych tematów lub kontrolek, jest to niepowodzenie 2.4.6.

Jak Naprawić

Ogólne nagłówki sekcji — niepoprawne

<section>
  <h2>Section 1</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Section 2</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

Ogólne nagłówki sekcji — poprawne

<!-- Each heading now describes the actual topic of its section,
     enabling screen reader users to jump directly to what they need -->
<section>
  <h2>Enterprise Logistics Software Solutions</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Flexible User-Based Pricing</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

Niejednoznaczne etykiety formularzy — niepoprawne

<!-- A checkout form with two address blocks, both using identical labels -->
<fieldset>
  <legend>Address</legend>
  <label for='street1'>Street</label>
  <input type='text' id='street1'>
  <label for='city1'>City</label>
  <input type='text' id='city1'>
</fieldset>
<fieldset>
  <legend>Address</legend>
  <label for='street2'>Street</label>
  <input type='text' id='street2'>
  <label for='city2'>City</label>
  <input type='text' id='city2'>
</fieldset>

Niejednoznaczne etykiety formularzy — poprawne

<!-- Legends now distinguish the two fieldsets; labels remain short because
     the legend provides the distinguishing context programmatically -->
<fieldset>
  <legend>Billing Address</legend>
  <label for='billing-street'>Street</label>
  <input type='text' id='billing-street'>
  <label for='billing-city'>City</label>
  <input type='text' id='billing-city'>
</fieldset>
<fieldset>
  <legend>Shipping Address</legend>
  <label for='shipping-street'>Street</label>
  <input type='text' id='shipping-street'>
  <label for='shipping-city'>City</label>
  <input type='text' id='shipping-city'>
</fieldset>

Nieopisowa etykieta ARIA na przycisku z ikoną — niepoprawne

<!-- aria-label provides a label but it does not describe the button's purpose -->
<button aria-label='button'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

Nieopisowa etykieta ARIA na przycisku z ikoną — poprawne

<!-- aria-label now clearly communicates what activating the button will do -->
<button aria-label='Search products'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

Powtarzające się nagłówki lub linki „Czytaj więcej” — niepoprawne

<article>
  <h3>Latest News</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>Latest News</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

Powtarzające się nagłówki lub linki „Czytaj więcej” — poprawne

<!-- Each article has a unique, descriptive heading that identifies its topic -->
<article>
  <h3>Istanbul Metro Expands to Three New Districts</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>New Regulations Affect E-Commerce Platforms</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

Typowe Błędy

• Używanie pozycyjnych lub porządkowych nagłówków, takich jak „Krok 1”, „Krok 2”, „Sekcja A” bez jakiegokolwiek tekstu opisowego: takie nagłówki mówią użytkownikowi jedynie, gdzie znajduje się w sekwencji, a nie, czego dotyczy sekcja. Zawsze łącz wskaźniki sekwencji z opisowym wyrażeniem rzeczownikowym, np. „Krok 2: Zweryfikuj swój adres e-mail”.
• Nadawanie wszystkim kafelkom lub komponentom artykułów na stronie listy tego samego tekstu nagłówka (np. każda karta produktu ma <h3> z tekstem „Produkt”): nagłówek każdej karty musi jednoznacznie identyfikować konkretny produkt, wpis na blogu lub element.
• Używanie tekstu zastępczego jako dostępnej etykiety dla pola formularza (poleganie na atrybucie placeholder zamiast elementu <label> lub aria-label): tekst zastępczy znika po wprowadzeniu danych i nie jest wiarygodnie ogłaszany przez wszystkie czytniki ekranu jako nazwa dostępna. Nawet jeśli placeholder istnieje, wymagana jest osobna opisowa etykieta.
• Pisanie aria-label, które jedynie powtarza typ elementu, a nie jego cel, na przykład aria-label='input' na polu tekstowym lub aria-label='button' na przycisku: etykieta musi opisywać, co robi kontrolka lub jaką wartość zbiera, a nie jaki jest jej typ.
• Używanie tekstu dymka podpowiedzi lub atrybutu title jako jedynej etykiety kontrolki formularza i zakładanie, że spełnia to 2.4.6: etykiety oparte na title są często niedostępne dla użytkowników korzystających wyłącznie z klawiatury i nie są konsekwentnie ogłaszane przez czytniki ekranu. Zamiast tego polegaj na widocznych elementach <label> lub aria-label.
• Etykietowanie pól wyszukiwania jedynie jako „Szukaj” na stronie, na której istnieje wiele zakresów wyszukiwania (np. wyszukiwanie w całej witrynie i wyszukiwanie w tabeli danych): gdy dwie kontrolki wykonują różne wyszukiwania, każda etykieta musi określać zakres, np. „Szukaj wszystkich produktów” i „Szukaj w historii zamówień”.
• Stosowanie tego samego tekstu nagłówka w oknie modalnym, co w głównym nagłówku strony: nagłówki okien modalnych powinny opisywać konkretne zadanie lub treść okna (np. „Potwierdź anulowanie”), a nie dziedziczyć tytuł strony, co byłoby mylące dla użytkowników czytników ekranu nawigujących w obrębie okna modalnego.
• Pomijanie opisowego elementu <legend> dla grup przycisków opcji lub pól wyboru przy jednoczesnym zapewnieniu indywidualnych etykiet opcji: <legend> dostarcza istotnego kontekstu, który sprawia, że każda indywidualna etykieta jest znacząca. „Tak” i „Nie” jako samodzielne etykiety opcji są nieinformacyjne bez legendy, takiej jak „Czy zgadzasz się z regulaminem?”.
• Ucinanie tekstu nagłówka w DOM ze względów projektowych (np. nagłówek zawierający tylko ikonę lub jedno słowo, ponieważ pełny tekst znajduje się w sąsiednich elementach wizualnych): programistyczny nagłówek musi być w pełni opisowy, ponieważ użytkownicy czytników ekranu słyszą go bez widzenia otaczającego układu wizualnego.
• Zakładanie, że skoro etykieta jest widoczna dla użytkowników widzących, to jest wystarczająco opisowa dla wszystkich użytkowników: etykieta, która polega na położeniu przestrzennym (np. nagłówek kolumny w niestandardowej siatce, gdzie znaczenie etykiety zależy od zobaczenia jej relacji z otaczającymi komórkami), może być wizualnie jasna, ale nie przekazywać tych samych informacji programistycznie. Zawsze weryfikuj, że sama nazwa dostępna jest wystarczająca.

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 obowiązkowe wymogi dotyczące dostępności cyfrowej dla szerokiego zakresu podmiotów publicznych i prywatnych działających w Turcji. Okrężnica wprost odwołuje się do WCAG 2.1 na poziomie AA jako standardu technicznego dla zgodności, a wymagania poziomu AA w WCAG 2.2 — które są wstecznie kompatybilne z WCAG 2.1 na poziomie AA — są silnie zalecane i wymagane od podmiotów ubiegających się o oficjalne Logo Dostępności (Erişilebilirlik Logosu) wydawane przez Ministerstwo Rodziny i Usług Społecznych (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 2.4.6 jest kryterium na poziomie AA, co oznacza, że mieści się dokładnie w zakresie tego, czym muszą zająć się objęte podmioty, aby osiągnąć pełną zgodność. Okrężnica obejmuje następujące typy podmiotów: instytucje publiczne i agencje rządowe; platformy e-commerce; banki i instytucje finansowe; szpitale i świadczeniodawców opieki zdrowotnej; operatorów telekomunikacyjnych z 200,000 lub większą liczbą abonentów; biura podróży; prywatne firmy transportowe oraz szkoły prywatne upoważnione przez Ministerstwo Edukacji Narodowej (Millî Eğitim Bakanlığı).

Dla tych podmiotów brak opisowych nagłówków i etykiet wiąże się z konkretnym ryzykiem regulacyjnym. Portal rządowy z niejasnymi nagłówkami sekcji utrudnia obywatelom z niepełnosprawnościami dostęp do usług publicznych, co pozostaje w bezpośrednim konflikcie z deklarowanym celem Okrężnicy, jakim jest zapewnienie równego dostępu. Serwis e-commerce z niejednoznacznymi etykietami formularzy w procesie realizacji zamówienia może uniemożliwić osobom z niepełnosprawnościami wzroku lub poznawczymi finalizację zakupów, co stanowi barierę w uczestnictwie gospodarczym, którą Okrężnica ma na celu wyeliminować.

Podmioty ubiegające się o Erişilebilirlik Logosu muszą wykazać zgodność poprzez audyt dostępności, a 2.4.6 jest jednym z kryteriów, które audytorzy będą oceniać manualnie. Ponieważ kryterium to wymaga oceny przez człowieka — narzędzia automatyczne nie są w stanie ocenić opisowości — organizacje powinny uwzględnić ustrukturyzowany przegląd manualny wszystkich nagłówków i etykiet formularzy jako standardową część procesu audytu dostępności. Włączenie tego przeglądu do przepływów pracy systemów zarządzania treścią i systemów projektowych, zamiast traktowania go jako jednorazowego zadania audytowego, jest najskuteczniejszą strategią utrzymania ciągłej zgodności w miarę zmiany treści w czasie.