WCAG 3.2.4: Spójna identyfikacja

Co oznacza ta zasada

Kryterium sukcesu WCAG 3.2.4 — Spójna identyfikacja — stanowi, że komponenty mające tę samą funkcjonalność w obrębie zestawu stron internetowych muszą być identyfikowane w sposób spójny. Oznacza to, że za każdym razem, gdy element interaktywny lub obraz pełni tę samą funkcję, powinien mieć tę samą dostępną nazwę lub etykietę za każdym razem, gdy pojawia się w serwisie.

Termin „identyfikowane” w tym kontekście odnosi się do tego, jak komponent jest prezentowany technologiom asystującym i użytkownikom. Obejmuje to widoczny tekst etykiety, atrybut aria-label lub aria-labelledby, tekst alt na obrazie, atrybut title lub nazwę dostępną obliczoną przez drzewo dostępności przeglądarki. Jeśli przycisk wyszukiwania pojawia się na każdej stronie serwisu, zawsze musi nazywać się „Search” — a nie „Search” na stronie głównej, „Find” na stronie listy produktów i „Go” na stronie realizacji zamówienia.

Kryterium to dotyczy zestawu stron internetowych, który WCAG definiuje jako zbiór stron o wspólnym celu i wytworzonych przez tego samego autora. Obejmuje to całą witrynę, aplikację webową lub wieloetapowy formularz rozłożony na kilka adresów URL. Komponenty, które są jedynie wizualnie podobne, ale pełnią różne funkcje, nie muszą mieć tej samej nazwy — wymaganie dotyczy konkretnie identycznej funkcjonalności.

Co jest uznawane za spełnienie: Ikona nawigacji otwierająca menu hamburgerowe jest konsekwentnie oznaczona jako „Open navigation menu” (lub równoważnie) na wszystkich stronach. Ikona koszyka zakupowego zawsze ma tekst alternatywny lub nazwę dostępną „Shopping cart”. Przycisk wylogowania jest zawsze oznaczony jako „Log out”. Zmienność sformułowania dla tej samej funkcji stanowi naruszenie.

Co jest uznawane za naruszenie: Przycisk wysyłania oznaczony jako „Submit” w formularzu rejestracji, ale oznaczony jako „Send” w formularzu kontaktowym, gdy oba przyciski pełnią tę samą funkcję przesyłania danych wprowadzonych przez użytkownika. Przycisk ikonowy z lupą oznaczony jako „Search” na większości stron, ale „Ara” na jednej przetłumaczonej podstronie, bez spójnej strategii językowej.

Oficjalny wyjątek: WCAG wyraźnie zaznacza, że dopuszczalne jest posiadanie dwóch komponentów o tej samej nazwie dostępnej, jeśli pełnią różne funkcje — w takim przypadku to różna funkcja je rozróżnia. Kryterium jest naruszone tylko wtedy, gdy funkcja jest identyczna, ale nazewnictwo niespójne.

Dlaczego to ma znaczenie

Niespójna identyfikacja tworzy nieproporcjonalne obciążenie dla użytkowników polegających na nawigacji niewizualnej lub opartej na wzorcach. Grupy najbardziej dotknięte to użytkownicy czytników ekranu, osoby z niepełnosprawnościami poznawczymi oraz osoby z niepełnosprawnościami ruchowymi korzystające z oprogramowania sterowanego głosem.

Użytkownicy czytników ekranu budują mentalny model witryny, słuchając nazw elementów podczas przechodzenia klawiszem Tab lub przeglądania według regionów. Gdy przycisk, który na poprzedniej stronie pełnił tę samą funkcję, ma teraz inną nazwę, użytkownik musi się zatrzymać, zbadać sytuację i ponownie zorientować — to czasochłonne i frustrujące doświadczenie. Według Światowej Organizacji Zdrowia około 2,2 miliarda osób na świecie ma jakąś formę zaburzenia widzenia. Nawet ułamek tej populacji wchodzący w interakcję z niespójnie oznakowaną witryną napotka istotne bariery.

Użytkownicy z niepełnosprawnościami poznawczymi, w tym osoby z dysleksją, zaburzeniami uwagi lub zaburzeniami pamięci, w dużym stopniu polegają na przewidywalnym nazewnictwie, aby zmniejszyć obciążenie poznawcze. Napotkanie znanej ikony lub kontrolki pod inną nazwą wymusza ponowną naukę i wywołuje niepokój. Spójne etykietowanie zmniejsza wysiłek potrzebny do zbudowania pamięci proceduralnej podczas regularnego korzystania z serwisu.

Użytkownicy sterowania głosem (korzystający z narzędzi takich jak Dragon NaturallySpeaking lub Apple Voice Control) wypowiadają nazwę kontrolki, aby ją aktywować. Jeśli dostępna nazwa przycisku różni się od tego, czego oczekują na podstawie wcześniejszych doświadczeń z serwisem, ich komenda głosowa zakończy się cichą porażką — oprogramowanie po prostu nie znajdzie dopasowania. W danym momencie interfejs staje się w praktyce nieużywalny.

Konkretny scenariusz z rzeczywistości: Rozważ turecką platformę e-commerce sprzedającą odzież. Na stronie siatki produktów każdy element ma przycisk z ikoną serca, którego nazwa dostępna to „Add to favourites”. Na stronie szczegółów produktu ta sama ikona serca ma nazwę dostępną „Kaydet” (po turecku „Zapisz”). Użytkownik czytnika ekranu, który nauczył się aktywować przycisk z sercem po nazwie na stronie siatki, nie może teraz znaleźć równoważnej kontrolki na stronie szczegółów bez wyczerpującej eksploracji. Może całkowicie porzucić serwis.

Poza dostępnością, spójne etykietowanie przynosi korzyści SEO. Wyszukiwarki analizują nazwy dostępne i tekst linków, aby zrozumieć treść strony. Niespójne etykietowanie funkcjonalnie identycznych linków (np. „Read more”, „Continue reading”, „Learn more”, wszystkie prowadzące do stron ze szczegółami artykułów) rozmywa sygnały słów kluczowych i utrudnia robotom zrozumienie struktury serwisu.

Powiązane reguły Axe-core

WCAG 3.2.4 wymaga testów manualnych, ponieważ narzędzia automatyczne nie są w stanie określić intencji semantycznej między stronami ani wiedzieć, że dwa różnie nazwane komponenty pełnią tę samą funkcję. Żadna reguła axe-core nie odwzorowuje bezpośrednio tego kryterium. Oto dlaczego automatyzacja jest niewystarczająca i co muszą zrobić testerzy:

• Wymagane testy manualne — spójność między stronami: Axe-core ocenia pojedynczą stronę w izolacji. Nie ma mechanizmu porównania nazwy dostępnej przycisku „Search” na stronie głównej z przyciskiem „Find” na stronie produktu, ponieważ nie utrzymuje międzystronicowego spisu nazw komponentów. Tester musi ręcznie skatalogować powtarzające się elementy funkcjonalne i sprawdzić, czy ich nazewnictwo jest jednolite na wszystkich stronach, na których występują.
• Wymagane testy manualne — spójność tekstu alternatywnego ikon i obrazów: Narzędzia automatyczne mogą wykryć brakujący tekst alternatywny (za pomocą reguły image-alt), ale nie są w stanie określić, czy dwa obrazy pełniące tę samą funkcję mają ten sam tekst alternatywny na różnych stronach. Na przykład ikona drukarki na stronie z potwierdzeniem zamówienia i ta sama ikona drukarki na stronie faktury mogą mieć tekst alternatywny — ale jeśli jeden brzmi „Print”, a drugi „Print this page”, człowiek musi ocenić, czy stanowi to niespójność w rozumieniu 3.2.4.
• Wymagane testy manualne — spójność etykiet ARIA: Axe-core sprawdza, czy etykiety ARIA są obecne i niepuste, ale nie audytuje, czy wartości aria-label dla tego samego typu komponentu są spójne w całym zestawie stron. Tester musi przejrzeć drzewo dostępności na wielu stronach i porównać nazwy dla funkcjonalnie identycznych kontrolek.
• Wymagane testy manualne — etykiety pól formularzy: Reguły automatyczne, takie jak label, weryfikują, czy pola wejściowe są powiązane z etykietami, ale nie sprawdzają, czy pole „Username” na stronie logowania jest również oznaczone jako „Username” (a nie „Email” lub „User ID”) na stronie odzyskiwania konta, gdy oba pola przyjmują ten sam typ danych wejściowych i pełnią tę samą rolę funkcjonalną.

Jak testować

1. Automatyczny wstępny skan: Uruchom axe DevTools lub Lighthouse na każdej stronie, aby wykryć powiązane naruszenia, takie jak brakujące nazwy dostępne (image-alt, button-name, link-name). Najpierw je usuń — nie da się ocenić spójności nazewnictwa, jeśli nazwy są nieobecne. Zanotuj nazwy dostępne raportowane dla powtarzających się komponentów w wynikach skanowania.
2. Utwórz inwentarz komponentów: Ręcznie wypisz wszystkie komponenty funkcjonalne, które powtarzają się na stronach — menu nawigacyjne, pola wyszukiwania, przyciski wysyłania, przyciski ikonowe, linki w okruszkach nawigacyjnych, linki do mediów społecznościowych, przyciski drukowania/udostępniania oraz kontrolki paginacji. Zapisz nazwę dostępną każdej instancji, korzystając z panelu Accessibility przeglądarki (Chrome DevTools > Elements > Accessibility lub Firefox Accessibility Inspector).
3. Porównaj nazwy między stronami: Dla każdego typu komponentu w inwentarzu sprawdź, czy każda instancja ma tę samą nazwę dostępną. Oznacz wszelkie rozbieżności. Zwróć szczególną uwagę na komponenty pojawiające się w nagłówkach, stopkach i paskach bocznych, ponieważ to one najczęściej są niespójnie oznakowane między szablonami.
4. Testy z czytnikiem ekranu NVDA + Firefox: Przejdź na stronę główną, a następnie użyj listy elementów NVDA (Insert + F7), aby otworzyć listę przycisków i linków. Zanotuj nazwy powtarzających się kontrolek. Następnie przejdź na trzy lub cztery inne reprezentatywne strony i powtórz. Nasłuchuj wszelkich różnic w nazwach funkcjonalnie identycznych kontrolek.
5. Testy z czytnikiem ekranu VoiceOver + Safari (macOS/iOS): Użyj Rotor (VO + U), aby wyświetlić listę przycisków lub linków na każdej stronie. Porównaj nazwy powtarzających się elementów. Na iOS przechodź gestami po elementach interaktywnych na równoważnych stronach i zanotuj wszelkie różnice w nazewnictwie.
6. Testy z czytnikiem ekranu JAWS + Chrome: Użyj wirtualnego kursora JAWS oraz listy pól formularzy (Insert + F5) i linków (Insert + F7) na wielu stronach. Potwierdź, że identyczne kontrolki mają identyczne nazwy w całym serwisie.
7. Test sterowania głosem: Korzystając z Windows Voice Access lub Dragon NaturallySpeaking, wypowiedz nazwę powtarzającej się kontrolki na jednej stronie (np. „Click Search”). Przejdź na inną stronę i wypowiedz tę samą komendę. Jeśli nie zadziała, nazwy są niespójne z funkcjonalnego punktu widzenia.

Jak naprawić

Przycisk wyszukiwania z niespójnymi etykietami — niepoprawne

<!-- Homepage -->
<button type='submit' aria-label='Search'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Product listing page -->
<button type='submit' aria-label='Find products'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Blog page -->
<button type='submit' aria-label='Go'>
  <svg aria-hidden='true'>...</svg>
</button>

Przycisk wyszukiwania z niespójnymi etykietami — poprawne

<!-- Homepage, product listing page, and blog page all use the same label -->
<!-- Consistent aria-label across all pages ensures assistive technologies
     always announce the same name for this functionally identical button -->
<button type='submit' aria-label='Search'>
  <svg aria-hidden='true'>...</svg>
</button>

Ikona używana do tej samej akcji z różnym tekstem alt — niepoprawne

<!-- Order history page -->
<a href='/print/order/123'>
  <img src='/icons/print.svg' alt='Print order' />
</a>

<!-- Invoice page -->
<a href='/print/invoice/456'>
  <img src='/icons/print.svg' alt='Print this document' />
</a>

<!-- Receipt page -->
<a href='/print/receipt/789'>
  <img src='/icons/print.svg' alt='Yazdir' />
</a>

Ikona używana do tej samej akcji z różnym tekstem alt — poprawne

<!-- All print links across the site share the same alt text.
     The destination URL differentiates which document is printed;
     the control's accessible name remains consistent. -->
<a href='/print/order/123'>
  <img src='/icons/print.svg' alt='Print' />
</a>

<a href='/print/invoice/456'>
  <img src='/icons/print.svg' alt='Print' />
</a>

<a href='/print/receipt/789'>
  <img src='/icons/print.svg' alt='Print' />
</a>

Przycisk zamykania nawigacji z niespójną nazwą — niepoprawne

<!-- Mobile menu on homepage -->
<button aria-label='Close menu' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Mobile menu on product page (different developer implemented it) -->
<button aria-label='Dismiss navigation' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

Przycisk zamykania nawigacji z niespójną nazwą — poprawne

<!-- A shared component/template ensures the label is identical everywhere.
     Using a single reusable component or design token for the label
     eliminates the risk of developer-introduced inconsistencies. -->
<button aria-label='Close navigation menu' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

Linki do udostępniania w mediach społecznościowych z różnymi nazwami — niepoprawne

<!-- Article page -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Share on Twitter'>
  <svg aria-hidden='true'>...</svg>
</a>

<!-- Video page -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Tweet this'>
  <svg aria-hidden='true'>...</svg>
</a>

Linki do udostępniania w mediach społecznościowych z różnymi nazwami — poprawne

<!-- Both pages use the same accessible name for the functionally
     identical sharing action. The URL parameter carries the context;
     the control name stays uniform. -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Share on Twitter'>
  <svg aria-hidden='true'>...</svg>
</a>

Najczęstsze błędy

• Używanie różnych wartości aria-label w różnych szablonach dla tego samego komponentu: Gdy różni deweloperzy tworzą szablony stron niezależnie, bez wspólnej biblioteki komponentów, przyciski ikonowe, takie jak zamykanie, wyszukiwanie czy koszyk, często otrzymują doraźne etykiety. Ustal token systemu projektowego lub wspólny komponent dla każdego powtarzającego się elementu interaktywnego, aby nazwa dostępna była zdefiniowana raz i używana wszędzie.
• Niespójne tłumaczenie nazw dostępnych na stronach wielojęzycznych: Serwis może poprawnie oznaczyć przycisk wyszukiwania jako „Search” w języku angielskim, ale używać niespójnego tureckiego odpowiednika — czasem „Ara”, czasem „Arama Yap” — w zależności od tego, który szablon strony został zlokalizowany jako pierwszy. Utrzymuj pojedynczy klucz tłumaczeniowy na etykietę komponentu i egzekwuj go we wszystkich plikach językowych.
• Dodawanie kontekstowych sufiksów do w inny sposób identycznych kontrolek: Oznaczanie przycisków jako „Add to cart — Blue T-Shirt”, „Add to cart — Red Dress” itd., gdy podstawowa funkcja (dodanie do koszyka) jest ta sama, nie jest automatycznym naruszeniem 3.2.4 — WCAG dopuszcza doprecyzowanie — ale robienie tego niespójnie (czasem z sufiksem, czasem bez) powoduje zamieszanie. Wybierz jeden wzorzec i stosuj go konsekwentnie.
• Poleganie na widocznej etykiecie tekstowej jako nośniku spójności, gdy różnią się nadpisujące ją aria-label: Gdy przycisk wizualnie ma napis „Search”, ale jeden szablon dodaje aria-label='Search the site', a inny nie ma aria-label (więc nazwa dostępna jest wyprowadzana wyłącznie z widocznego tekstu), czytniki ekranu ogłoszą różne nazwy, mimo że przycisk wygląda tak samo. Audytuj pełne obliczanie nazwy dostępnej, a nie tylko widoczną etykietę.
• Pozwalanie redaktorom CMS na dowolną zmianę tekstu przycisków bez nadzoru dostępności: Systemy zarządzania treścią, które udostępniają etykiety przycisków jako edytowalne pola, pozwalają redaktorom zmieniać „Submit” na „Send” lub „Gönder” według osobistych preferencji. Ogranicz możliwość edycji etykiet dla funkcjonalnych komponentów interfejsu lub dodaj walidację, która ostrzega redaktorów, gdy proponowana etykieta odbiega od ustalonego standardu.
• Brak audytu widżetów zewnętrznych lub osadzonych komponentów: Widżety czatu, banery zgody na pliki cookie i ramki płatności wstrzykiwane przez podmioty trzecie często zawierają przyciski oznaczone inaczej niż konwencje serwisu. Przejrzyj i, jeśli to możliwe, skonfiguruj nazwy dostępne komponentów zewnętrznych tak, aby były zgodne z twoimi konwencjami nazewniczymi, lub udokumentuj odstępstwo jako znany wyjątek.
• Używanie tekstu podpowiedzi (title) jako jedynej nazwy dostępnej w niektórych instancjach, a aria-label w innych: Atrybut title nie jest niezawodnie odczytywany przez wszystkie technologie asystujące i jest uważany za słabe źródło nazwy dostępnej. Jeśli niektóre instancje powtarzającego się komponentu używają title, a inne aria-label, obliczone nazwy mogą się różnić ze względu na różnice w obsłudze przez przeglądarki i czytniki ekranu.
• Zakładanie, że kontrolki paginacji są zwolnione, ponieważ ich numery się różnią: Kontrolki „Next page” i „Previous page”, nawet jeśli zawierają numer strony w etykiecie (np. „Go to page 3”), muszą stosować spójny wzorzec. Mieszanie „Next” na niektórych stronach z „Next page” lub „İleri” na innych dla tej samej kontrolki paginacji narusza 3.2.4.
• Brak testowania komponentów nagłówka i stopki we wszystkich odrębnych szablonach stron: Serwisy często mają wiele szablonów stron (strona główna, strona kategorii, strona artykułu, strona płatności). Komponenty nagłówka i stopki mogą renderować się nieco inaczej w różnych szablonach. Testerzy, którzy sprawdzają tylko jeden lub dwa szablony, mogą przeoczyć niespójności wprowadzone przez nadpisania specyficzne dla szablonu.
• Mylenie 3.2.4 z 3.2.3 (Spójna nawigacja): Zespoły czasem zakładają, że jeśli kolejność nawigacji jest spójna (3.2.3), nazewnictwo również musi być spójne — ale są to odrębne wymagania. Pasek nawigacyjny w tym samym miejscu na każdej stronie (zgodność z 3.2.3) nadal może naruszać 3.2.4, jeśli jego linki są różnie oznaczone na poszczególnych stronach. Uwzględnij oba kryteria osobno w procesie QA.

Związek z tureckimi regulacjami dotyczącymi dostępności

Okrężnik Prezydencki Turcji 2025/10, opublikowany w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia wiążące wymagania w zakresie dostępności dla szerokiego zakresu publicznych i prywatnych usług cyfrowych. Okrężnik nakazuje zgodność z międzynarodowo uznanymi standardami dostępności — w praktyce zbieżną z WCAG 2.2 na poziomie AA — i wiąże tę zgodność z Logotypem Dostępności (Erişilebilirlik Logosu) wydawanym przez Ministerstwo Rodziny i Usług Społecznych (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 3.2.4 Spójna identyfikacja jest kryterium poziomu AA, co oznacza, że jest wymogiem obowiązkowym — a nie zaleceniem — dla organizacji, które chcą uzyskać lub utrzymać Erişilebilirlik Logosu. Brak wdrożenia spójnej identyfikacji w całej usłudze cyfrowej uniemożliwi pełną zgodność z poziomem AA, a w konsekwencji uniemożliwi uzyskanie logotypu.

Okrężnik wyraźnie obejmuje następujące typy podmiotów, z których wszystkie muszą uwzględnić WCAG 3.2.4 w swoich interfejsach webowych i mobilnych: instytucje publiczne i agencje rządowe; banki i dostawcy usług finansowych; szpitale i platformy opieki zdrowotnej; operatorzy telekomunikacyjni z 200,000 lub większą liczbą abonentów; platformy e-commerce; biura podróży i serwisy rezerwacyjne; prywatne firmy transportowe oraz szkoły prywatne upoważnione przez Ministerstwo Edukacji Narodowej (Milli Eğitim Bakanlığı).

Dla tych organizacji praktyczne implikacje są znaczące. Rozbudowane serwisy instytucjonalne — takie jak portal bankowości internetowej banku, system rezerwacji wizyt szpitala czy system informacji studenckiej uczelni — zazwyczaj obejmują setki stron i są budowane przez wiele zespołów deweloperskich na przestrzeni lat. Niespójne etykietowanie powtarzających się kontrolek (przyciski akcji na koncie, paski wyszukiwania, ikony nawigacji) na tych stronach jest częstym i łatwo przeoczanym źródłem naruszeń. Programy zgodności muszą uwzględniać audyty spójności między stronami jako osobną fazę testów, a nie jedynie automatyczne skany pojedynczych stron.

Tureckie organizacje ubiegające się o Erişilebilirlik Logosu powinny zintegrować kontrole WCAG 3.2.4 z zarządzaniem systemem projektowym, przepływami pracy w systemie zarządzania treścią oraz z pipeline’ami QA. W szczególności każda wielokrotnie używana kontrolka interfejsu użytkownika powinna mieć swoją nazwę dostępną zdefiniowaną jako nieedytowalną stałą na poziomie systemu projektowego, z kluczami tłumaczeń zarządzanymi centralnie, aby zapewnić, że tureckie i inne wersje językowe pozostają spójne na wszystkich stronach i w szablonach, w których komponent się pojawia.