WCAG 1.3.6: Identyfikacja celu

Co oznacza ta zasada

\n

WCAG 1.3.6 — Identify Purpose (Identyfikacja celu) to kryterium poziomu AAA w ramach Zasady 1 (Postrzegalność), które rozszerza istniejące wymagania dotyczące struktury i semantyki na bardziej szczegółowy poziom. W szczególności wymaga, aby cel każdego komponentu interfejsu użytkownika, ikony, regionu oraz określonych pól wejściowych mógł być określony programowo — co oznacza, że informacje semantyczne są ujawnione w taki sposób, aby przeglądarki, rozszerzenia przeglądarek i technologie asystujące mogły je odczytać i na ich podstawie działać.

\n

Kryterium to bezpośrednio opiera się na 1.3.1 (Informacje i relacje) oraz 1.3.5 (Identyfikacja celu danych wprowadzanych przez użytkownika). Podczas gdy 1.3.5 koncentruje się na typowych polach wejściowych z danymi osobowymi (imię, e‑mail, telefon itp.), 1.3.6 rozszerza wymaganie na wszystkie regiony i komponenty interfejsu użytkownika, w tym znaczniki nawigacyjne, ikony, przyciski i interaktywne widżety. Główną ideą jest to, aby agent użytkownika lub narzędzie personalizacyjne mogło zastąpić domyślną prezentację — podmieniając tekstowe etykiety na symbole, upraszczając rozbudowaną nawigację lub wyróżniając najbardziej istotne kontrolki — na podstawie maszynowo odczytywalnych danych o celu osadzonych w znacznikach.

\n

W praktyce strona spełnia 1.3.6, gdy używa elementów znaczników HTML5 (takich jak <header>, <nav>, <main>, <aside>, <footer> i <section>), stosuje odpowiednie role znaczników ARIA tam, gdzie nie użyto elementów znaczników, ujawnia cel ikon i innych nietekstowych komponentów interfejsu za pomocą dostępnych nazw lub ról oraz — tam, gdzie ma to zastosowanie — używa standaryzowanych tokenów celu, takich jak te zdefiniowane w specyfikacji W3C Personalization Semantics (wcześniej znanej jako propozycja COGA Semantics), na przykład poprzez słownictwo atrybutów aui-.

\n

Strona nie spełnia wymagań, gdy jej regiony są zaimplementowane jako ogólne kontenery <div> lub <span> bez roli semantycznej, gdy ikony niosą znaczenie, ale nie mają dostępnej nazwy ani wspierającej semantyki, lub gdy komponenty interaktywne nie dostarczają żadnej programowej wskazówki co do swojej funkcji poza widocznym wyglądem. Obowiązuje oficjalny wyjątek: wymaganie dotyczy tylko treści zaimplementowanych przy użyciu technologii, które wspierają identyfikację oczekiwanego znaczenia. Jeśli dla danego typu komponentu w określonym stosie technologicznym nie istnieje żadna wspierająca technologia ani specyfikacja, kryterium nie może być w rozsądny sposób zastosowane do tego komponentu.

\n\n

Dlaczego to ma znaczenie

\n

Głównymi beneficjentami WCAG 1.3.6 są osoby z niepełnosprawnościami poznawczymi i trudnościami w uczeniu się, w tym z dysleksją, zaburzeniami koncentracji uwagi, ze spektrum autyzmu, z zaburzeniami pamięci oraz z niepełnosprawnością intelektualną. Według Światowej Organizacji Zdrowia około 1 na 6 osób na świecie — ponad miliard osób — żyje z jakąś formą znaczącej niepełnosprawności, a niepełnosprawności poznawcze stanowią jedną z największych i najbardziej niedostatecznie obsługiwanych grup. Wielu z tych użytkowników ma trudności ze złożonymi strukturami nawigacji, gęstymi tekstowymi menu oraz kontrolkami opartymi wyłącznie na ikonach, które nie zapewniają żadnego semantycznego punktu odniesienia.

\n

Rozważmy konkretny scenariusz: użytkownik z ciężką dysleksją polega na rozszerzeniu przeglądarki, które zastępuje standardowe etykiety nawigacyjne osobistymi zestawami symboli — ikonami obrazkowymi z tablicy komunikacyjnej, której używa na co dzień. Aby taka podmiana zadziałała, rozszerzenie musi być w stanie ustalić, że dany <div> jest w rzeczywistości znacznikiem nawigacyjnym, że ikona gwiazdki oznacza „dodaj do ulubionych”, a okrągła strzałka oznacza „odśwież”. Bez programowo określanego celu rozszerzenie nie ma się czego „zaczepić” i podmiana kończy się po cichu niepowodzeniem, pozostawiając użytkownika z interfejsem, którego nie jest w stanie zrozumieć.

\n

Użytkownicy z niepełnosprawnością ruchową, którzy polegają na narzędziach switch access lub sterowania głosem, również odnoszą znaczące korzyści, ponieważ narzędzia świadome celu mogą generować nakładki skrótów lub mapowania komend głosowych tylko dla kontrolek, których funkcja jest maszynowo odczytywalna. Osoby niewidome korzystające z czytników ekranu zyskują dzięki wyraźnie oznaczonym regionom znaczników, które pozwalają im przeskoczyć bezpośrednio do treści <main> lub pominąć powtarzalną nawigację. Użytkownicy słabowidzący, którzy stosują powiększenie przeglądarki lub własne arkusze stylów, korzystają ze struktury znaczników, ponieważ umożliwia ona przewidywalne przekształcanie (reflow) treści przez przeglądarkę.

\n

Poza dostępnością wdrożenie semantyki wymaganej przez 1.3.6 przynosi mierzalne korzyści SEO. Roboty wyszukiwarek używają znaczników landmark i schema do zrozumienia struktury strony, indeksowania hierarchii treści i generowania rozszerzonych wyników. Dobrze ustrukturyzowana strona z sensownymi regionami znaczników ma większą szansę na uzyskanie wyróżnionych fragmentów i wyższych ocen trafności. Istnieje także bezpośrednia dywidenda użyteczności: strony z przejrzystą strukturą semantyczną są łatwiejsze w utrzymaniu, testowaniu i rozbudowie przez zespoły deweloperskie, co zmniejsza dług techniczny w dłuższej perspektywie.

\n\n

Powiązane reguły Axe-core

\n

WCAG 1.3.6 wymaga ręcznego testowania oprócz wszelkich testów automatycznych. Narzędzia automatyczne mogą zweryfikować obecność znaczników semantycznych, ale nie są w stanie określić, czy te znaczniki dokładnie i kompletnie oddają cel każdego komponentu tak, jak zrobiłby to tester‑człowiek. Poniższe reguły axe-core są ściśle powiązane i pełnią rolę automatycznych substytutów dla wybranych aspektów tego kryterium:

\n

\n
• region — Sprawdza, czy cała treść na stronie jest zawarta w regionie znacznika. Oznacza treści, które znajdują się poza jakimkolwiek rozpoznanym elementem znacznika lub rolą znacznika ARIA. Choć ta reguła nie testuje dokładności identyfikacji celu, zapewnia, że strukturalna podstawa wymagana przez 1.3.6 jest obecna. Niepowodzenie oznacza, że istotna treść jest niewidoczna dla nawigacji opartej na znacznikach.
\n
• landmark-one-main — Weryfikuje, czy strona zawiera dokładnie jeden element <main> lub element z role='main'. Jest to fundamentalne dla 1.3.6, ponieważ główny obszar treści jest jednym z najważniejszych regionów, których cel musi być identyfikowalny. Wiele znaczników <main> lub ich brak uniemożliwia narzędziom personalizacji wyodrębnienie treści głównej.
\n
• landmark-complementary-is-top-level — Sprawdza, czy elementy <aside> lub regiony z role='complementary' nie są zagnieżdżone wewnątrz głównego obszaru treści w sposób, który zniekształca ich cel. Nieprawidłowe zagnieżdżenie wprowadza technologie asystujące w błąd co do relacji między regionami.
\n
• aria-allowed-role i aria-valid-attr-value — Oznaczają nieprawidłowe lub nieodpowiednie przypisania ról ARIA. Ponieważ 1.3.6 opiera się na poprawnej semantyce ról, użycie nieprawidłowej roli (np. role='navigation' w grupie przycisków) aktywnie podważa identyfikację celu i te reguły ujawnią takie niedopasowania.
\n
• button-name i link-name — Weryfikują, czy kontrolki interaktywne mają dostępne nazwy. Przyciski i linki oparte wyłącznie na ikonach, bez dostępnych nazw, są głównym trybem niepowodzenia dla 1.3.6, ponieważ nie można określić celu kontrolki, która nie ma nazwy. Te reguły oznaczają brak aria-label, aria-labelledby lub widocznego tekstu.
\n

\n

Ręczne testowanie jest wymagane, ponieważ narzędzia automatyczne nie są w stanie ocenić, czy wybrane tokeny celu lub role semantyczne dokładnie odzwierciedlają rzeczywistą funkcję komponentu w kontekście aplikacji. Przycisk może mieć dostępną nazwę i prawidłową rolę ARIA, a mimo to nie spełniać 1.3.6, jeśli nazwa jest myląca lub rola nie odzwierciedla tego, co kontrolka faktycznie robi.

\n\n

Jak testować

\n

\n
1. Uruchom automatyczne skanowanie za pomocą axe DevTools lub Lighthouse. Otwórz stronę w Chrome, włącz rozszerzenie axe DevTools i uruchom skan całej strony. Przefiltruj wyniki według wymienionych powyżej reguł: region, landmark-one-main, button-name i link-name. Zanotuj wszelkie naruszenia i ich poziomy wpływu. W Lighthouse uruchom audyt Accessibility i przejrzyj sekcje dotyczące znaczników i ARIA. Udokumentuj wszystkie niepowodzenia jako punkt odniesienia, pamiętając jednak, że reprezentują one tylko podzbiór zgodności z 1.3.6.
\n
2. Ręcznie sprawdź strukturę znaczników za pomocą narzędzi deweloperskich przeglądarki. Otwórz DevTools, przejdź do panelu Accessibility Tree (Chrome) lub Accessibility Inspector (Firefox) i zweryfikuj, że strona ujawnia spójną hierarchię znaczników: jeden <header> na najwyższym poziomie, jeden <main>, co najmniej jeden <nav> (z wyróżniającą etykietą, jeśli występuje ich więcej) oraz <footer>. Upewnij się, że żaden istotny region treści nie jest opakowany wyłącznie w ogólny <div> lub <span>.
\n
3. Przetestuj z NVDA i Firefox. Uruchom NVDA, otwórz stronę w Firefox i naciśnij D, aby przechodzić między znacznikami. Zweryfikuj, że każdy znacznik jest ogłaszany z sensowną rolą oraz — gdy istnieje wiele znaczników tego samego typu — unikalną etykietą. Przejdź do każdego przycisku opartego wyłącznie na ikonie za pomocą klawisza Tab i upewnij się, że NVDA ogłasza opisową dostępną nazwę — a nie pusty ciąg, nazwę pliku czy ogólną etykietę typu „button”.
\n
4. Przetestuj z VoiceOver i Safari (macOS/iOS). Włącz VoiceOver (Cmd+F5 na macOS). Użyj Rotor (Vo+U), aby otworzyć listę Landmarks i sprawdź, czy pojawiają się wszystkie oczekiwane regiony. Przechodź po kontrolkach interaktywnych klawiszem Tab i słuchaj sensownych opisów. Na iOS użyj przesunięcia trzema palcami, aby nawigować po nagłówkach i znacznikach, i upewnij się, że cel każdego regionu jest poprawnie ogłaszany.
\n
5. Przetestuj z JAWS i Chrome. Otwórz stronę w Chrome z uruchomionym JAWS. Naciśnij R, aby nawigować po regionach, i upewnij się, że rola i etykieta każdego regionu są poprawne. Użyj JAWS Virtual Cursor, aby odczytać przyciski z ikonami i zweryfikować, że ich cel jest przekazany. Użyj JAWS List of Links (Insert+F7), aby przeanalizować wszystkie nazwy linków pod kątem ich sensowności.
\n
6. Przetestuj semantykę personalizacji (jeśli jest zaimplementowana). Jeśli Twoja strona używa słownictwa W3C Personalization Semantics (np. atrybutów data-purpose lub aui-), użyj narzędzia testowego Personalization Semantics lub kompatybilnego rozszerzenia przeglądarki, aby zweryfikować, że tokeny celu są poprawnie zastosowane i maszynowo odczytywalne przez agentów użytkownika, którzy wspierają tę specyfikację.
\n
7. Przeprowadź audyt celu komponentów, komponent po komponencie. Dla każdego interaktywnego komponentu i ikony na stronie zadaj pytanie: czy cel tego komponentu można określić bez kontekstu wizualnego? Jeśli po usunięciu wszystkich arkuszy CSS i obrazów cel komponentu nadal jest jasny wyłącznie na podstawie DOM i atrybutów ARIA, komponent przechodzi test. Jeśli cel jest przekazywany tylko wizualnie, komponent nie spełnia wymagań.
\n

\n\n

Jak naprawić

\n\n

Ogólne regiony div bez znaczników — niepoprawne

\n

<div class='site-header'>\n  <div class='logo'>Accsible</div>\n  <div class='main-nav'>\n    <a href='/home'>Home</a>\n    <a href='/pricing'>Pricing</a>\n  </div>\n</div>\n<div class='main-content'>\n  <p>Welcome to our platform.</p>\n</div>\n<div class='sidebar'>\n  <p>Related articles</p>\n</div>\n<div class='site-footer'>\n  <p>© 2025 Accsible</p>\n</div>

\n\n

Ogólne regiony div bez znaczników — poprawne

\n

<!-- Use native HTML5 landmark elements so browsers and AT\n     can programmatically identify the purpose of each region -->\n<header>\n  <a href='/' aria-label='Accsible home'>\n    <img src='logo.svg' alt='Accsible' />\n  </a>\n  <nav aria-label='Primary navigation'>\n    <a href='/home'>Home</a>\n    <a href='/pricing'>Pricing</a>\n  </nav>\n</header>\n<main>\n  <p>Welcome to our platform.</p>\n</main>\n<aside aria-label='Related articles'>\n  <p>Related articles</p>\n</aside>\n<footer>\n  <p>© 2025 Accsible</p>\n</footer>

\n\n

Przycisk oparty wyłącznie na ikonie, bez dostępnej nazwy — niepoprawne

\n

<!-- An icon button whose purpose cannot be determined\n     programmatically — it has no accessible name at all -->\n<button class='btn-icon'>\n  <svg viewBox='0 0 24 24' width='24' height='24'>\n    <path d='M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z'/>\n  </svg>\n</button>

\n\n

Przycisk oparty wyłącznie na ikonie, bez dostępnej nazwy — poprawne

\n

<!-- aria-label gives the button a programmatically determinable\n     purpose; the SVG is hidden from AT since the label covers it -->\n<button class='btn-icon' aria-label='Add to favourites'>\n  <svg viewBox='0 0 24 24' width='24' height='24' aria-hidden='true' focusable='false'>\n    <path d='M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z'/>\n  </svg>\n</button>

\n\n

Wiele znaczników nawigacyjnych bez wyróżniających etykiet — niepoprawne

\n

<!-- Two nav elements with identical roles but no labels:\n     screen readers cannot distinguish their purpose -->\n<nav>\n  <a href='/home'>Home</a>\n  <a href='/about'>About</a>\n</nav>\n\n<nav>\n  <a href='/page1'>Chapter 1</a>\n\n
(Content truncated due to token limit — please retry this article.)