WCAG 1.3.6: Identyfikacja celu

Wprowadzenie do Kryterium WCAG 1.3.6: Identyfikacja Celu

Kryterium sukcesu WCAG 1.3.6 „Identyfikacja celu” (Identify Purpose), na poziomie AA, wymaga, aby cel elementów interfejsu użytkownika, ikon i obszarów był możliwy do ustalenia programowo. Oznacza to, że nie tylko użytkownik wizualny powinien być w stanie zrozumieć przeznaczenie danego komponentu na podstawie jego wyglądu lub kontekstu, ale także technologie wspomagające (takie jak czytniki ekranu) muszą mieć dostęp do tych informacji w sposób, który mogą przekazać użytkownikowi.

Głównym celem tego kryterium jest zapewnienie, że osoby korzystające z różnych technologii wspomagających lub preferujące spersonalizowane wyświetlanie treści, mogą efektywnie nawigować i wchodzić w interakcje ze stroną lub aplikacją. Jest to kluczowe dla budowania elastycznych i adaptacyjnych interfejsów, które dostosowują się do potrzeb użytkownika.

Dlaczego Identyfikacja Celu jest Ważna?

Zapewnienie programowej identyfikacji celu komponentów interfejsu użytkownika ma znaczący wpływ na dostępność i użyteczność, pomagając szerokiej grupie użytkowników:

• Użytkownicy z niepełnosprawnością poznawczą: Jasno zdefiniowany cel komponentów zmniejsza obciążenie poznawcze i pomaga w przewidywaniu działania interfejsu. Użytkownicy mogą szybciej zrozumieć, do czego służy dany element, nawet jeśli jego wizualna reprezentacja jest niejasna lub wymaga interpretacji.
• Użytkownicy z dysleksją lub zaburzeniami percepcji wzrokowej: Mogą dostosować wyświetlanie treści, np. zmieniając ikony na etykiety tekstowe o większej czcionce lub wysokim kontraście, jeśli cel jest programowo dostępny. To ułatwia przetwarzanie informacji i orientację w interfejsie.
• Użytkownicy czytników ekranu (niewidomi lub słabowidzący): Czytniki ekranu mogą ogłosić cel elementu (np. „przycisk wyszukiwania”, „link nawigacyjny do strony głównej”), co ułatwia orientację, nawigację i efektywne korzystanie z interfejsu bez polegania na wskazówkach wizualnych.
• Użytkownicy sterujący głosem: Mogą wydawać polecenia takie jak „kliknij Szukaj” lub „przejdź do nawigacji”, jeśli elementy mają jasno określony cel. To umożliwia płynniejszą interakcję i zwiększa kontrolę nad aplikacją.
• Użytkownicy, którzy dostosowują interfejs: Mogą używać wtyczek przeglądarki lub własnych stylów CSS do zmiany wyglądu lub układu komponentów, bazując na ich programowo określonym celu. Pozwala to na personalizację interfejsu zgodnie z indywidualnymi preferencjami.

Wymagania Kryterium Sukcesu 1.3.6

To kryterium (należące do WCAG 2.1 na poziomie AA) wymaga, aby dla wszystkich komponentów interfejsu użytkownika, ikon i regionów na stronie internetowej, ich cel był możliwy do ustalenia programowo. Oznacza to, że muszą istnieć mechanizmy, które pozwalają technologiom wspomagającym zrozumieć, do czego służy dany element. Często osiąga się to poprzez:

• Użycie odpowiednich, semantycznych elementów HTML5.
• Stosowanie atrybutów ARIA (Accessible Rich Internet Applications), takich jak role, aria-label, aria-labelledby, aria-describedby.
• Zapewnienie dostępnych nazw dla ikon i obrazków, które pełnią funkcję lub przekazują istotne informacje.
• Identyfikację głównych regionów strony za pomocą ról punktów orientacyjnych (landmark roles), co ułatwia ogólną nawigację po stronie.

Praktyczne Wskazówki dla Zgodności

1. Używaj Semantycznego HTML5

Zawsze, gdy jest to możliwe, należy używać wbudowanych, semantycznych elementów HTML5, ponieważ dostarczają one domyślnych informacji o celu dla przeglądarek i technologii wspomagających, bez konieczności dodawania dodatkowych atrybutów ARIA.

• Nawigacja: Użyj elementu <nav> dla głównych sekcji nawigacyjnych.
• Główna zawartość: Użyj elementu <main> dla głównej zawartości dokumentu.
• Pasek boczny/treść uzupełniająca: Użyj elementu <aside> dla treści luźno związanych z główną zawartością.
• Nagłówek strony/sekcji: Użyj elementu <header>.
• Stopka strony/sekcji: Użyj elementu <footer>.
• Formularze: Użyj elementów <form>, <label>, <input>, <button> w prawidłowy sposób, aby zapewnić logiczne połączenie etykiet z polami.
• Listy: Użyj <ul>, <ol>, <li> do strukturyzowania list.

2. Stosuj Atrybuty ARIA (Accessible Rich Internet Applications)

Gdy semantyczny HTML nie wystarcza do wyrażenia celu (np. dla złożonych widżetów lub niestandardowych elementów interaktywnych), użyj atrybutów ARIA. Pamiętaj, że ARIA powinno uzupełniać, a nie zastępować semantyki HTML.

• Role punktów orientacyjnych (Landmark Roles): Użyj atrybutu role z wartościami takimi jak "search", "banner", "contentinfo", "complementary", "main", "navigation", "form", "region", aby identyfikować główne sekcje strony. Jest to szczególnie przydatne, gdy nie możesz użyć odpowiadających im elementów HTML5 lub chcesz doprecyzować ich rolę (np. wiele sekcji <nav> wymaga unikalnego aria-label lub role).
• aria-label: Użyj, aby nadać dostępną nazwę elementowi, gdy nie ma widocznego tekstu (np. dla przycisku z samą ikoną, linku „czytaj więcej” w kontekście, gdzie sam tekst nie jest wystarczająco opisowy).
• aria-labelledby: Łączy element z jego widoczną etykietą tekstową, gdy nie można użyć standardowego elementu <label> (np. dla złożonych formularzy, grup pól, lub do powiązania nagłówka z regionem).
• aria-describedby: Łączy element z opisem, który dostarcza dodatkowych informacji o celu, funkcji lub instrukcjach użytkowania elementu.
• aria-current: Wskazuje bieżący element w zestawie, na przykład aktualnie aktywną stronę w paginacji, bieżący element w menu nawigacyjnym lub aktualnie aktywną zakładkę.

3. Zapewnij Dostępne Nazwy dla Ikon

Jeśli używasz ikon bez towarzyszącego im tekstu, upewnij się, że ich cel jest programowo dostępny dla technologii wspomagających.

• Ikony w przyciskach/linkach: Użyj aria-label na elemencie interaktywnym (<button>, <a>) lub wizualnie ukrytego tekstu (np. <span class="sr-only">Szukaj</span>). Ikona sama w sobie powinna być ukryta przed czytnikami ekranu za pomocą aria-hidden="true", jeśli jej cel jest już określony przez tekst lub aria-label.
• Ikony jako elementy dekoracyjne: Jeśli ikona nie ma funkcji ani nie przekazuje istotnej informacji (jest czysto dekoracyjna), powinna być ukryta przed technologiami wspomagającymi (np. aria-hidden="true", role="presentation" lub puste alt="" dla elementu <img>).

Przykłady Implementacji

Poprawne Implementacje

<header>
  <nav aria-label="Główna nawigacja">
    <ul>
      <li><a href="/" aria-current="page">Strona główna</a></li>
      <li><a href="/#">Produkty</a></li>
      <li><a href="/kontakt">Kontakt</a></li>
    </ul>
  </nav>
  <form role="search" action="/search" method="get">
    <label for="search-input" class="sr-only">Wyszukaj</label>
    <input type="search" id="search-input" name="q" placeholder="Wyszukaj...">
    <button type="submit" aria-label="Rozpocznij wyszukiwanie">
      <span class="icon-search" aria-hidden="true"></span>
    </button>
  </form>
</header>

Wyjaśnienie: Element <nav> automatycznie informuje o nawigacji. Dodanie aria-label="Główna nawigacja" daje unikalny identyfikator, szczególnie przydatny, gdy na stronie jest wiele sekcji nawigacyjnych. Atrybut aria-current="page" jednoznacznie identyfikuje aktywny element. Formularz wyszukiwania używa role="search" do programowego określenia jego celu, a przycisk z ikoną lupy ma aria-label, aby programowo zidentyfikować jego funkcję.

<button type="button" aria-label="Dodaj do koszyka">
  <span class="icon-cart" aria-hidden="true"></span>
</button>

<!-- Alternatywnie, ukryty wizualnie tekst -->
<style>
  .sr-only {
    position: absolute;
    width: 1px;
    height: 1px;
    padding: 0;
    margin: -1px;
    overflow: hidden;
    clip: rect(0, 0, 0, 0);
    white-space: nowrap;
    border-width: 0;
  }
</style>
<button type="button">
  <span class="icon-heart" aria-hidden="true"></span>
  <span class="sr-only">Dodaj do ulubionych</span>
</button>

Wyjaśnienie: Zarówno aria-label, jak i wizualnie ukryty tekst, zapewniają dostępną nazwę dla przycisku, który w innym przypadku miałby tylko ikonę. Ikona jest ukryta za pomocą aria-hidden="true", aby czytniki ekranu nie próbowały jej interpretować.

<aside role="complementary" aria-labelledby="related-posts-title">
  <h3 id="related-posts-title">Powiązane artykuły</h3>
  <ul>
    <li><a href="#">Artykuł A</a></li>
    <li><a href="#">Artykuł B</a></li>
  </ul>
</aside>

Wyjaśnienie: Element <aside> jest semantyczny i sugeruje treść uzupełniającą. Dodanie role="complementary" wzmacnia jego rolę jako treści uzupełniającej, a aria-labelledby łączy go z nagłówkiem h3, dostarczając czytnikom ekranu kontekstu i dostępnej nazwy dla całego regionu.

Niepoprawne Implementacje

<div class="nav-menu">
  <div class="menu-item"><a href="/">Start</a></div>
  <div class="menu-item"><a href="/onas">O nas</a></div>
</div>

<div class="search-box">
  <input type="text" placeholder="Szukaj...">
  <span class="icon-search"></span>
</div>

Problem: Czytnik ekranu nie otrzyma informacji o tym, że .nav-menu to nawigacja, ani że .search-box to formularz wyszukiwania. Ikona lupy jest dla niego niezauważalna jako element interaktywny, ponieważ nie znajduje się w elemencie interaktywnym i nie ma dostępnej nazwy.

<button type="button">
  <span class="icon-delete" aria-hidden="true"></span>
</button>

Problem: Dla użytkownika czytnika ekranu ten przycisk zostanie ogłoszony jako „przycisk” bez żadnej dodatkowej informacji o jego funkcji. Użytkownik nie będzie w stanie zrozumieć, do czego służy, co prowadzi do frustracji i niemożności interakcji.

Najlepsze Praktyki i Częste Pułapki

Najlepsze Praktyki

1. Preferuj natywne HTML: Zawsze używaj semantycznych elementów HTML, gdy tylko są dostępne. Są one domyślnie dostępne i zrozumiane przez wszystkie technologie wspomagające, a także zapewniają wbudowaną obsługę klawiatury i prawidłowe stany.
2. Używaj ARIA strategicznie: ARIA powinno być używane do uzupełniania, a nie zastępowania, natywnych semantycznych elementów HTML. Stosuj ARIA, gdy natywny HTML nie oferuje odpowiedniej semantyki lub potrzebujesz dostarczyć dodatkowe stany czy właściwości (np. aria-expanded dla elementów rozwijanych).
3. Zawsze zapewniaj dostępną nazwę: Każdy interaktywny element, a także istotne obszary strony (np. główne regiony landmark), powinny mieć programowo dostępną nazwę, która jednoznacznie określa ich cel.
4. Testuj z technologiami wspomagającymi: Regularnie testuj swoje strony i aplikacje za pomocą czytników ekranu (np. NVDA, JAWS, VoiceOver), aby upewnić się, że programowo określone cele są prawidłowo interpretowane i ogłaszane. Testowanie manualne jest niezastąpione.
5. Konsekwencja: Utrzymuj spójność w identyfikacji celów. Jeśli ten sam typ komponentu (np. przycisk „zamknij” w oknie modalnym) pojawia się w różnych miejscach, jego cel powinien być identycznie określony programowo.

Częste Pułapki

1. Nadmierne lub nieprawidłowe użycie ARIA: Nie używaj ARIA tam, gdzie wystarczy zwykły HTML. Na przykład, tworzenie elementu <div role="button"> jest gorsze niż <button>, ponieważ nie dziedziczy wbudowanej semantyki, obsługi klawiatury i stanów bez dodatkowej pracy deweloperskiej.
2. Brak etykiet dla ikon: Zapominanie o dostarczeniu aria-label lub ukrytego tekstu dla ikon, które pełnią funkcję interaktywną (np. przyciski z ikonami), co sprawia, że są one niezrozumiałe dla czytników ekranu.
3. Brak ról punktów orientacyjnych: Nieoznaczanie głównych regionów strony (np. nawigacji, treści głównej, stopki) za pomocą semantycznych elementów HTML5 lub ról ARIA, co utrudnia nawigację użytkownikom czytników ekranu, którzy często skaczą między tymi regionami.
4. Zakładanie, że wizualna informacja wystarczy: Błędne przekonanie, że jeśli element jest wizualnie zrozumiały, to jest też dostępny programowo. To nie zawsze prawda, szczególnie dla użytkowników polegających na technologiach wspomagających, które bazują na kodzie.
5. Złożone widżety bez odpowiedniej semantyki ARIA: Tworzenie niestandardowych elementów interfejsu (np. rozwijanych menu, zakładek, suwaków) bez użycia odpowiednich ról, stanów i właściwości ARIA do opisania ich funkcjonalności i celu.

Podsumowanie

Kryterium WCAG 1.3.6 „Identyfikacja celu” jest fundamentalne dla zapewnienia dostępności interfejsu użytkownika. Poprzez programowe określanie celu komponentów, ikon i regionów, umożliwiamy szerszej grupie użytkowników efektywne korzystanie z treści, bez względu na ich preferencje czy używane technologie wspomagające. Stosowanie semantycznego HTML5 oraz, w razie potrzeby, odpowiednich atrybutów ARIA, jest kluczowe dla spełnienia tego wymogu i budowania bardziej inkluzywnych, użytecznych i dostępnych środowisk cyfrowych.