WCAG 2.4.4: Cel linku (w kontekście)

Co Oznacza Ta Zasada

WCAG 2.4.4 — Cel linku (w kontekście) — to kryterium sukcesu na poziomie A w ramach zasady Operable. Mówi ono, że cel każdego linku musi być możliwy do ustalenia na podstawie samego tekstu linku lub tekstu linku w połączeniu z jego programowo określonym kontekstem linku. Jeśli żadne z tych źródeł nie jest wystarczające, link nie spełnia tego kryterium.

Wyrażenie „programowo określony kontekst linku” jest precyzyjnie zdefiniowane przez WCAG. Odnosi się do informacji, które można wywnioskować z tego samego zdania, akapitu, elementu listy lub komórki tabeli co link, albo z nagłówka poprzedzającego sekcję zawierającą link. Obejmuje także kontekst ujawniany poprzez relacje ARIA, takie jak aria-labelledby lub aria-describedby. Kluczowe jest, aby ten kontekst był programowo dostępny — czyli aby technologie asystujące mogły go odczytać automatycznie — a nie jedynie wizualnie sugerowany użytkownikom widzącym.

W praktyce następujące elementy i atrybuty HTML są bezpośrednio objęte tym kryterium: elementy kotwiczące <a href>, elementy <area> w mapach obrazów, elementy <button> wywołujące nawigację, elementy ostylowane lub oskryptowane tak, by zachowywały się jak linki przy użyciu ról ARIA, takich jak role='link', oraz elementy SVG <a>. Dostępna nazwa linku — wyliczona z jego tekstu wewnętrznego, aria-label, aria-labelledby lub atrybutu alt na obrazku potomnym — jest głównym nośnikiem informacji o jego celu.

Co uznaje się za spełnienie: Link spełnia kryterium, jeśli użytkownik może określić jego cel lub funkcję bez dodatkowego kontekstu (np. „Pobierz Raport Roczny 2024 w formacie PDF”) lub jeśli otaczający kontekst programowy jasno określa cel (np. link „Czytaj więcej” wewnątrz <li>, który zaczyna się od tytułu artykułu). Tekst linku nie musi być globalnie unikalny w obrębie całej strony; musi być jednoznaczny jedynie w swoim kontekście.

Co uznaje się za niespełnienie: Ogólnikowe teksty linków, takie jak „kliknij tutaj”, „czytaj więcej”, „tutaj”, „więcej” lub „link”, nie spełniają kryterium, gdy otaczający kontekst programowy nie rozstrzyga, dokąd prowadzą. Link obrazkowy z brakującym lub pustym atrybutem alt również nie spełnia kryterium, ponieważ dostępna nazwa w ogóle nie istnieje.

Oficjalny wyjątek: WCAG dopuszcza jeden wyjątek. Gdy cel linku jest celowo niejednoznaczny — to znaczy ujawnienie celu z góry zniweczyłoby jego użyteczność lub użyteczność otaczającej treści — kryterium nie ma zastosowania. Ten wyjątek jest niezwykle wąski i rzadko spotykany w rzeczywistych scenariuszach.

Dlaczego To Ma Znaczenie

Około 2,2 miliarda osób na świecie ma jakąś formę zaburzeń widzenia, według Światowej Organizacji Zdrowia. Wśród nich użytkownicy niewidomi, polegający na czytnikach ekranu, są najbardziej dotknięci niejednoznacznym tekstem linków. Oprogramowanie czytników ekranu, takie jak NVDA, JAWS i VoiceOver, pozwala użytkownikom nawigować po stronie, generując listę wszystkich linków wyodrębnionych z ich kontekstu. Gdy lista zawiera dziesiątki pozycji, które wszystkie brzmią „czytaj więcej” lub „kliknij tutaj”, użytkownicy niewidomi nie są w stanie ustalić, dokąd prowadzi który link, bez powrotu do każdego z nich i odczytania otaczającej treści — to czasochłonny i dezorientujący proces.

Użytkownicy z niepełnosprawnością ruchową, którzy nawigują wyłącznie za pomocą klawiatury, przełączników lub urządzeń śledzących ruch gałek ocznych, również odnoszą znaczące korzyści. Użytkownicy ci często przechodzą klawiszem Tab przez elementy interaktywne sekwencyjnie i polegają na etykiecie elementu w fokusie, aby zdecydować, czy go aktywować. Niejednoznaczny tekst linku wymusza dodatkowe kroki nawigacyjne, które zwiększają zmęczenie i liczbę błędów.

Użytkownicy z niepełnosprawnościami poznawczymi — w tym osoby z zaburzeniami koncentracji, problemami z pamięcią lub niską umiejętnością czytania — korzystają z jasnego, opisowego tekstu linków, ponieważ zmniejsza on obciążenie poznawcze potrzebne do zrozumienia struktury strony. Nie muszą utrzymywać informacji kontekstowych w pamięci roboczej podczas skanowania linków.

Konkretny scenariusz z życia: Rozważ stronę z listą produktów w serwisie e-commerce, która wyświetla dziesięć produktów, każdy z przyciskiem „Kup teraz” i linkiem „Dowiedz się więcej” wyrenderowanymi identycznie. Użytkownik niewidomy, nawigujący po liście linków, słyszy dziesięć kolejnych wystąpień „Dowiedz się więcej” bez wskazania, do którego produktu odnosi się każdy link. Aby kupić właściwy produkt, musi odczytać cały otaczający kontekst dla każdego linku — proces, który może zająć minuty zamiast sekund. Przy opisowym tekście linku, takim jak „Dowiedz się więcej o słuchawkach Sony WH-1000XM5”, to samo zadanie wymaga jednego gestu nawigacyjnego.

Poza dostępnością, opisowy tekst linków przynosi mierzalne korzyści SEO. Roboty wyszukiwarek używają tekstu kotwicy jako sygnału do zrozumienia treści strony docelowej. Opisowy, bogaty w słowa kluczowe tekst linku poprawia możliwość indeksowania i przeszukiwania zasobów, co pozytywnie wpływa na pozycjonowanie w wynikach wyszukiwania. Dodatkowo, jasny tekst linków zmniejsza współczynnik odrzuceń i liczbę zgłoszeń do działu wsparcia, ponieważ ustawia właściwe oczekiwania użytkowników przed nawigacją.

Powiązane Reguły Axe-core

• link-name: Ta reguła sprawdza, czy każdy element <a> z atrybutem href, każdy element z role='link' oraz każdy element <area> ma niepustą dostępną nazwę. Dostępna nazwa jest wyliczana zgodnie ze standardowym algorytmem ARIA: z tekstu wewnętrznego, aria-label, aria-labelledby lub atrybutu alt obrazka potomnego <img>. Axe zgłasza naruszenie, gdy wyliczona dostępna nazwa jest pusta, zawiera wyłącznie białe znaki lub całkowicie jej brakuje. Ta reguła wychwytuje najpoważniejszą formę naruszenia 2.4.4 — linki całkowicie nienazwane — ale nie jest w stanie wykryć linków, których nazwy są technicznie obecne, lecz semantycznie bezsensowne (np. „kliknij tutaj” lub „czytaj więcej”), ponieważ narzędzia automatyczne nie potrafią określić intencji na podstawie ogólnikowych ciągów znaków.
• duplicate-id-aria: Ta reguła sprawdza, czy żadne dwa elementy na stronie nie współdzielą tego samego atrybutu id, gdy to id jest referencją w atrybucie ARIA, takim jak aria-labelledby lub aria-describedby. Zduplikowane identyfikatory użyte w relacjach ARIA powodują, że przeglądarka rozwiązuje odwołanie w sposób nieprzewidywalny — zazwyczaj do pierwszego pasującego elementu w kolejności DOM — co może sprawić, że dostępna nazwa linku zostanie wyliczona na podstawie całkowicie niewłaściwego elementu. Na przykład, jeśli dwa linki używają aria-labelledby='product-title' i dwa elementy współdzielą to ID, czytniki ekranu mogą ogłaszać niewłaściwą nazwę produktu dla jednego lub obu linków, bezpośrednio naruszając 2.4.4. Axe oznacza to jako krytyczny problem, ponieważ wynikowa dostępna nazwa jest niewiarygodna.

Ważne jest zrozumienie ograniczeń testów automatycznych dla tego kryterium. Narzędzia takie jak axe-core mogą zweryfikować, że link ma dostępną nazwę, ale nie mogą zweryfikować, czy nazwa jest znacząca. Link nazwany „tutaj” automatycznie przechodzi regułę link-name, ponieważ ciąg nie jest pusty. Do oceny, czy ogólnikowy tekst linku narusza 2.4.4, potrzebna jest ludzka ocena. To sprawia, że testy manualne są niezbędnym uzupełnieniem skanowania automatycznego dla tego kryterium.

Jak Testować

1. Skan automatyczny z axe DevTools lub Lighthouse: Zainstaluj rozszerzenie przeglądarki axe DevTools (Chrome lub Firefox) lub uruchom audyt dostępności Lighthouse w Chrome DevTools. Uruchom skan całej strony i przefiltruj wyniki dla reguł link-name i duplicate-id-aria. Przejrzyj każdy oznaczony element: potwierdź, że wyliczona dostępna nazwa jest nieobecna lub pusta w przypadku naruszeń link-name, oraz zweryfikuj, że zduplikowane identyfikatory psują odwołania etykiet ARIA w przypadku naruszeń duplicate-id-aria. Zauważ, że zaliczenie tych testów automatycznych nie gwarantuje pełnej zgodności z 2.4.4 — przejdź do kroków manualnych.
2. Manualny przegląd listy linków: W NVDA z Firefoxem naciśnij kombinację klawiszy Insert+F7, aby otworzyć okno dialogowe Elements List i wybierz „Links”. Przejrzyj każdą pozycję na liście w oderwaniu od kontekstu wizualnego. Zapytaj: czy możesz ustalić, dokąd prowadzi każdy link, wyłącznie na podstawie jego tekstu? Powtórz w JAWS z Chrome, używając Insert+F7, aby otworzyć Links List. W VoiceOver z Safari na macOS naciśnij Control+Option+U, aby otworzyć Web Item Rotor i wybierz „Links”. Każdy link, którego cel jest niejednoznaczny w izolacji, powinien zostać sprawdzony w odniesieniu do jego programowego kontekstu.
3. Test nawigacji klawiaturą: Używając wyłącznie klawisza Tab, przejdź przez wszystkie elementy interaktywne na stronie. Za każdym razem, gdy fokus znajdzie się na linku, odczytaj tylko ogłaszany tekst (nie otaczającą treść wizualną). Jeśli nie możesz ustalić celu linku na podstawie tego, co jest ogłaszane, link prawdopodobnie nie spełnia 2.4.4. Zwróć szczególną uwagę na linki składające się wyłącznie z ikon (ikony mediów społecznościowych, przyciski strzałek) oraz linki obrazkowe.
4. Weryfikacja kontekstu: Dla linków, które polegają na otaczającym kontekście (np. „Czytaj więcej” wewnątrz elementu listy), sprawdź DOM, aby potwierdzić, że tekst kontekstowy znajduje się w tym samym zdaniu, akapicie, elemencie listy lub komórce tabeli co link. Kontekst, który jest jedynie wizualnie sąsiadujący, ale niepowiązany programowo, nie spełnia kryterium. Użyj narzędzi deweloperskich przeglądarki, aby sprawdzić wyliczone drzewo dostępności i potwierdzić relację.
5. Audyt etykiet ARIA: Przeszukaj kod źródłowy strony pod kątem wszystkich użyć aria-labelledby i aria-describedby na elementach linków. Zweryfikuj, że każde referencjonowane ID istnieje dokładnie raz w dokumencie i że referencjonowany element zawiera zamierzony tekst opisowy. Użyj panelu drzewa dostępności przeglądarki (dostępnego w Chrome DevTools w zakładce Accessibility), aby potwierdzić wyliczoną nazwę dla każdego linku.

Jak Naprawić

Link składający się wyłącznie z ikony, bez dostępnej nazwy — Niepoprawne

<!-- An icon link with no text and no aria-label -->
<a href='https://twitter.com/accsible'>
  <svg viewBox='0 0 24 24' width='24' height='24'>
    <path d='M23 3a10.9 10.9...' />
  </svg>
</a>

Link składający się wyłącznie z ikony, bez dostępnej nazwy — Poprawne

<!-- aria-label provides a descriptive accessible name for screen readers -->
<a href='https://twitter.com/accsible' aria-label='Accsible on Twitter'>
  <svg viewBox='0 0 24 24' width='24' height='24' aria-hidden='true' focusable='false'>
    <path d='M23 3a10.9 10.9...' />
  </svg>
</a>

Ogólne linki „Czytaj więcej” na liście kart — Niepoprawne

<!-- Multiple identical link texts with no distinguishing context -->
<ul>
  <li>
    <h3>Istanbul Accessibility Summit 2024</h3>
    <p>Join us for the annual summit on digital inclusion.</p>
    <a href='/events/istanbul-2024'>Read more</a>
  </li>
  <li>
    <h3>New WCAG 2.2 Guidelines Released</h3>
    <p>W3C has published the updated guidelines.</p>
    <a href='/news/wcag-22'>Read more</a>
  </li>
</ul>

Ogólne linki „Czytaj więcej” na liście kart — Poprawne

<!-- Option 1: Visually hidden text appended to the link -->
<ul>
  <li>
    <h3>Istanbul Accessibility Summit 2024</h3>
    <p>Join us for the annual summit on digital inclusion.</p>
    <a href='/events/istanbul-2024'>
      Read more
      <span class='sr-only'>about the Istanbul Accessibility Summit 2024</span>
    </a>
  </li>
  <li>
    <h3>New WCAG 2.2 Guidelines Released</h3>
    <p>W3C has published the updated guidelines.</p>
    <a href='/news/wcag-22'>
      Read more
      <span class='sr-only'>about the New WCAG 2.2 Guidelines</span>
    </a>
  </li>
</ul>

<!-- Option 2: Use aria-label to override the visible text entirely -->
<a href='/events/istanbul-2024' aria-label='Read more about the Istanbul Accessibility Summit 2024'>
  Read more
</a>

Link obrazkowy z pustym atrybutem alt — Niepoprawne

<!-- The image has an empty alt, making the link completely unnamed -->
<a href='/products/overlay-widget'>
  <img src='widget-logo.png' alt='' />
</a>

Link obrazkowy z pustym atrybutem alt — Poprawne

<!-- The alt attribute on the image provides the link's accessible name -->
<a href='/products/overlay-widget'>
  <img src='widget-logo.png' alt='Accsible Overlay Widget — product details' />
</a>

aria-labelledby odwołujące się do zduplikowanego ID — Niepoprawne

<!-- Two elements share the same ID; the second link resolves to the wrong label -->
<div>
  <span id='card-title'>Accsible SDK Documentation</span>
  <a href='/docs' aria-labelledby='card-title'>View</a>
</div>
<div>
  <span id='card-title'>Accsible Pricing Plans</span>
  <a href='/pricing' aria-labelledby='card-title'>View</a>
</div>

aria-labelledby odwołujące się do zduplikowanego ID — Poprawne

<!-- Each ID is unique; each link resolves to the correct label -->
<div>
  <span id='card-title-docs'>Accsible SDK Documentation</span>
  <a href='/docs' aria-labelledby='card-title-docs'>View</a>
</div>
<div>
  <span id='card-title-pricing'>Accsible Pricing Plans</span>
  <a href='/pricing' aria-labelledby='card-title-pricing'>View</a>
</div>

Typowe Błędy

• Używanie jako tekstu linku sformułowań „kliknij tutaj”, „tutaj”, „więcej” lub „czytaj więcej” bez żadnej dodatkowej dostępnej nazwy poprzez aria-label, aria-labelledby lub wizualnie ukryte elementy <span> — te ciągi są bezsensowne, gdy czytnik ekranu wyodrębni je z kontekstu wizualnego.
• Dodanie aria-label do linku, który zawiera inny tekst widoczny, bez zapewnienia, że etykieta zaczyna się od widocznego ciągu tekstowego — narusza to WCAG 2.5.3 (Label in Name) i powoduje dezorientację u użytkowników sterowania głosowego, którzy próbują aktywować link, wypowiadając jego widoczną nazwę.
• Ustawienie alt='' na obrazku, który jest jedyną treścią linku, co sprawia, że wyliczona dostępna nazwa linku jest pusta i powoduje naruszenie link-name — pusty alt jest poprawny dla obrazów dekoracyjnych, ale nie wtedy, gdy obraz jest jedyną treścią elementu interaktywnego.
• Zastosowanie aria-hidden='true' do jedynego węzła tekstowego wewnątrz linku, co usuwa dostępną nazwę z drzewa dostępności i pozostawia link nienazwany dla użytkowników czytników ekranu.
• Wielokrotne użycie tej samej wartości id w wielu elementach, do których odwołuje się aria-labelledby na różnych linkach, co powoduje, że czytniki ekranu wyliczają niewłaściwą dostępną nazwę dla jednego lub więcej linków z powodu nieprzewidywalnego rozwiązywania ID.
• Opakowanie całego komponentu karty (nagłówek, obraz, akapit i przycisk) w pojedynczy tag <a>, co powoduje, że czytniki ekranu odczytują całą treść karty jako dostępną nazwę linku — jest to rozwlekłe i dezorientujące — zamiast użycia krótkiej, opisowej etykiety.
• Poleganie wyłącznie na podpowiedzi atrybutu CSS title lub pseudoklasie :hover, aby dostarczyć kontekst linku — atrybut title jest niespójnie ujawniany przez czytniki ekranu i jest całkowicie niedostępny dla użytkowników korzystających wyłącznie z klawiatury, którzy nie mogą wywołać stanu hover.
• Używanie samego adresu URL jako tekstu linku (np. <a href='https://example.com/p?id=12345'>https://example.com/p?id=12345</a>), co jest nie do wymówienia przez czytniki ekranu i bezsensowne dla użytkowników z niepełnosprawnościami poznawczymi.
• Dynamiczne generowanie identyfikatorów linków lub wartości atrybutów ARIA za pomocą frameworków JavaScript bez zapewnienia ich unikalności — komponenty React, Vue i Angular renderowane w listach często produkują zduplikowane ID, jeśli nie zastosuje się jawnych strategii kluczy.
• Zapominanie o dodaniu focusable='false' do wbudowanych ikon SVG wewnątrz linków w Internet Explorerze i starszych wersjach Edge, co powoduje, że SVG otrzymuje własny punkt tabulacji i czytniki ekranu ogłaszają SVG oddzielnie od tekstu linku, rozdzielając wyliczanie dostępnej nazwy.

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

Prezydenckie Rozporządzenie Turcji 2025/10, opublikowane w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia obowiązkowe wymagania dotyczące dostępności cyfrowej zgodne z WCAG 2.2. WCAG 2.4.4 Cel linku (w kontekście) jest kryterium na poziomie A, co oznacza, że wchodzi w skład obowiązkowej podstawy, którą muszą spełnić wszystkie objęte podmioty.

Rozporządzenie ma zastosowanie do określonego zestawu typów podmiotów zarówno w sektorze publicznym, jak i prywatnym. Instytucje publiczne — w tym ministerstwa, agencje państwowe, gminy i uniwersytety publiczne — są zobowiązane do osiągnięcia pełnej zgodności z poziomem A w ciągu roku od publikacji rozporządzenia. Podmioty sektora prywatnego objęte rozporządzeniem mają dwuletnie okno na dostosowanie. Zakres sektora prywatnego jest szeroki i wyraźnie obejmuje platformy e-commerce, banki i instytucje finansowe, prywatne 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.

Dla wszystkich tych podmiotów niezgodny tekst linków stanowi bezpośrednie naruszenie regulacyjne. Rozważ turecką platformę e-commerce, która wyświetla strony listy produktów z powtarzającymi się linkami „Satın Al” (Kup teraz) lub „Devamını Oku” (Czytaj więcej) bez kontekstu programowego. Użytkownik niewidomy, polegający na TalkBack, NVDA lub VoiceOver, nie byłby w stanie ustalić, do którego produktu odnosi się każdy link, co stanowi naruszenie 2.4.4 i złamanie wymogów rozporządzenia. Podobnie, portal rezerwacji wizyt w publicznym szpitalu, który używa linków nawigacyjnych składających się wyłącznie z ikon, bez dostępnych nazw, narusza zarówno regułę axe link-name, jak i wymogi rozporządzenia.

Zgodność z 2.4.4 nie jest jedynie technicznym „odhaczeniem” wymogu. Rozporządzenie sygnalizuje szersze zaangażowanie rządu w inkluzję cyfrową około 8,5 miliona obywateli Turcji z niepełnosprawnościami. Dla podmiotów objętych zakresem proaktywne rozwiązywanie problemów z celem linków — poprzez standardy systemów projektowych, szkolenia deweloperów i automatyczne skanowanie w CI/CD — jest zarówno obowiązkiem prawnym, jak i rozsądną inwestycją w użyteczność oraz wyniki wyszukiwania. Niezastosowanie się w wyznaczonych terminach może skutkować działaniami regulacyjnymi ze strony właściwych organów nadzorczych wyznaczonych w rozporządzeniu.