Wróć do wszystkich kryteriów

3.2.4 Spójna identyfikacja (ang.) Consistent Identification

Specjalizacje:

  • Designer
  • Deweloper

Elementy:

  • Formularze
  • Nawigacja
  • Przyciski i kontrolki

Poziomy:

  • AA

Spis treści

    Istota i cel kryterium

    To kryterium służy do budowania intuicyjnych, przyjaznych użytkownikowi systemów cyfrowych. Nadrzędnym celem jest sprawienie, aby powtarzalne elementy interfejsu działające w ten sam sposób były zawsze nazywane i oznaczane identycznie w obrębie całego serwisu. Wyeliminujesz dzięki temu dezorientację oraz drastycznie zmniejszysz zmęczenie psychiczne odbiorców, dając im pełne poczucie kontroli nad środowiskiem strony.

    Gdy użytkownik raz nauczy się, że dana ikona lub fraza wywołuje konkretną akcję, oczekuje tej samej logiki w każdym innym miejscu witryny. Chaos w nazewnictwie zmusza do ciągłego, ponownego analizowania interfejsu, co drastycznie obniża użyteczność serwisu.

    Definicja w j. angielskim

    Definicja dostępna pod adresem (link otworzy się w nowej karcie):
    https://www.w3.org/WAI/WCAG22/quickref/#consistent-identification

    Definicja w j. polskim

    Definicja dostępna pod adresem (link otworzy się w nowej karcie):
    https://www.w3.org/Translations/WCAG21-pl/#spojna-identyfikacja

    Słownik pojęć

    Komponenty
    –

    pojedyncze, interaktywne elementy struktury strony, takie jak przyciski, linki nawigacyjne, pola formularzy czy samodzielne ikony funkcjonalne.

    Spójna identyfikacja
    –

     jednolitość stosowanych etykiet wizualnych, opisów alternatywnych oraz nazw dostępnych dla technologii asystujących.

    Wpływ na dostępność (Kogo wspierasz?)

    • Wszyscy użytkownicy serwisu – wyrazistość bez kompromisów w interfejsie przyspiesza realizację zadań, minimalizuje ryzyko popełnienia błędu i zapobiega niepotrzebnej frustracji.
    • Użytkownicy czytników ekranu – osoby te polegają w pełni na nazwach programowalnych. Zmiana etykiety tego samego przycisku na kolejnych podstronach sprawia, że tracą oni orientację i nie wiedzą, czy dana funkcja nadal działa tak samo.
    • Osoby z niepełnosprawnościami poznawczymi, dysleksją lub zaburzeniami pamięci – spójne nazewnictwo zdejmuje z nich konieczność ciągłego uczenia się interfejsu na nowo. Buduje to ich samodzielność i pewność siebie podczas nawigacji.
    • Osoby starsze – seniorzy znacznie trudniej adaptują się do niespójnych i dynamicznych zmian w oprogramowaniu. Konsekwencja ułatwia im swobodne korzystanie z cyfrowych usług.
    • Osoby słabowidzące – użytkownicy korzystający z dużego powiększenia ekranu widzą jedynie mały wycinek strony. Stałe i przewidywalne etykiety oraz ikony ułatwiają im błyskawiczne skanowanie wzrokowe treści.

    Zasady wdrażania i wymagania techniczne

    • Zaimplementuj spójność na każdym poziomie kodu oraz warstwy wizualnej. Musisz zagwarantować, że powtarzalne elementy interfejsu zachowają identyczne właściwości w czterech kluczowych obszarach.
    • Zadbaj o etykiety tekstowe. Jeśli link prowadzący do koszyka na stronie głównej nosi nazwę „Koszyk”, nie zmieniaj go na „Twój koszyk” lub „Mój koszyk” na podstronach produktowych. Tekst widoczny dla oka musi być niezmienny.
    • Ujednolicaj nazwy programowalne. Wykorzystując atrybuty takie jak aria-labelczy aria-labelledby, pilnuj, by przekazywały technologiom asystującym dokładnie te same ciągi znaków dla tych samych funkcjonalności. Pamiętaj o ważnej zasadzie: jeśli dwa komponenty na tej samej stronie realizują funkcję tożsamą z komponentem na innej stronie zestawu, cała ta trójka musi być zidentyfikowana w sposób spójny.
    • Kontroluj teksty alternatywne. Samodzielne ikony graficzne (np. pliki SVG lub obrazy w znacznikach <img>) realizujące tę samą funkcję muszą posiadać identyczny atrybut alt.
    • Zsynchronizuj prezentację wizualną ikon. Jeśli określony piktogram oznacza wyszukiwarkę, używaj dokładnie tego samego kształtu i stylistyki w obrębie całego zestawu stron. Zmiana grafiki przy zachowaniu tej samej funkcji to poważny błąd projektowy.

    Wyjątki i sytuacje szczególne

    Zasada spójnej identyfikacji dopuszcza elastyczność tam, gdzie zmiana oznaczenia wynika bezpośrednio z modyfikacji funkcji elementu, logiki nawigacji lub kontekstu użycia.

    Pamiętaj, że dopuszczalna (a wręcz wymagana) jest zmiana oznaczenia, gdy komponent modyfikuje swoje działanie w czasie rzeczywistym. Doskonałym przykładem jest przycisk w trybie edycji danych: początkowo nosi etykietę „Edytuj”, lecz po jego kliknięciu i otwarciu formularza jego funkcja zmienia się na zapisanie wprowadzonych wartości – wtedy poprawnie przyjmuje nazwę „Zapisz zmiany”.

    Weź pod uwagę, że „spójny” nie zawsze oznacza „identyczny”. Przykładem są linki stronicowania (paginacji) wieloczęściowego artykułu. Jeśli strzałka nawigacyjna na pierwszej stronie odsyła do tekstu opisanego jako „Strona 2”, a na kolejnej jako „Strona 3”, etykiety te różnią się, ale zachowują pełną spójność logiczną i funkcjonalną.

    To samo dotyczy precyzowania kontekstu akcji. Ikona drukarki użyta w module zamówień może nosić etykietę „Drukuj paragon”, natomiast w sekcji księgowej „Drukuj fakturę”. Choć oba elementy technicznie wywołują proces drukowania, różnią się efektem końcowym, dlatego zróżnicowanie ich nazw jest w pełni poprawne.

    Kryterium nie blokuje również stosowania różnych nazw dla komponentów o odmiennych funkcjach, nawet jeśli są wizualnie podobne (np. przycisk „Usuń artykuł z koszyka” oraz „Usuń konto użytkownika” muszą się różnić, ponieważ wywołują zupełnie inne skutki).

    Przykłady implementacji

    Najczęstsze błędy

    • F31: Niezgodność z kryterium sukcesu wynikająca z zastosowania dwóch różnych etykiet, nazw programowalnych lub opisów alternatywnych dla komponentów realizujących dokładnie tę samą funkcję na różnych stronach w obrębie danego zestawu stron internetowych.
    • Używanie odmiennych opisów w atrybucie alt dla tej samej ikony graficznej pełniącej funkcję przycisku na różnych podstronach.
    • Stosowanie różnych nazw programowalnych w atrybucie aria-label dla identycznych funkcjonalnie ikon (np. aria-label="Szukaj" w nagłówku i aria-label="Wyszukaj" w sekcji wyników).
    • Zmiana widocznych etykiet tekstowych dla odnośników prowadzących do tego samego adresu URL na różnych etapach ścieżki użytkownika (np. żonglowanie nazwami „Koszyk”, „Mój koszyk” oraz „Twój koszyk”).
    • Niespójne nazywanie przycisków akcji w powtarzalnych formularzach (np. użycie napisu „Zapisz zmiany” w profilu, a „Aktualizuj” w ustawieniach prywatności, mimo tożsamego działania skryptu).

    Najlepsze praktyki

    • Wdrożenie kompletnego systemu projektowego ((ang.) design system) – twórz oprogramowanie z predefiniowanych, globalnych komponentów, co automatycznie wymusi spójność wizualną i techniczną w całym projekcie.
    • Centralne zarządzanie tłumaczeniami – w projektach wielojęzycznych pilnuj kontekstu lokalizacji, aby te same etykiety nie zostały przełożone na inne synonimy w różnych wersjach językowych (pamiętaj, że odmienne wersje językowe mogą tworzyć osobne zestawy stron).
    • Stworzenie słownika pojęć UX – opracuj i udostępnij całemu zespołowi (twórcom treści, projektantom, programistom) jeden autorytatywny spis zatwierdzonych nazw i etykiet dla elementów interaktywnych.
    • Regularne szkolenia zespołów deweloperskich – buduj świadomość wagi spójności interfejsu wśród wszystkich osób zaangażowanych w powstawanie produktu cyfrowego.
    • Testy z udziałem użytkowników – obserwuj realne zachowania ludzi wchodzących w interakcję z Twoją stroną, co pozwoli błyskawicznie wyłapać momenty zagubienia wywołane nazewnictwem.

    Metody testowania

    • Narzędzie deweloperskie (ang.) Developer Tools: Otwórz drzewo DOM przeglądarki i zweryfikuj w kodzie źródłowym różnych podstron, czy powtarzające się komponenty (np. przyciski akcji) posiadają dokładnie te same nazwy programowalne oraz identyczne atrybuty.
    • ANDI.JS: Wybierz moduł Istota i cel kryterium (ang.) „Graphics/Images”, aby sprawdzić, co dokładnie „widzi” technologia wspomagająca. Narzędzie podświetli każdy element graficzny i wyświetli tekst zastępczy, ułatwiając weryfikację spójności opisów ikon funkcyjnych w różnych miejscach serwisu.
    • NVDA: Uruchom czytnik ekranu i przejdź za pomocą klawiatury przez kluczowe, powtarzające się elementy witryny na różnych stronach zestawu, nasłuchując, czy komunikaty głosowe są niezmienne i przewidywalne na każdej podstronie.

    Sprawdź swoją wiedzę

    W linku poniżej znajduje się 6 makiet symulujących przejścia między różnymi podstronami tego samego serwisu. Twoim zadaniem jest sprawdzenie, czy powtarzające się elementy funkcjonalne (ikony, linki, przyciski) są oznaczane w sposób spójny.

    Jak to sprawdzić?

    1. Przełączaj się między zakładkami w każdym przykładzie.
    2. Zbadaj elementy za pomocą narzędzi deweloperskich (Zbadaj element).
    3. Sprawdź widoczne etykiety tekstowe oraz nazwy programowalne (np. aria-label, alt) dla elementów realizujących tę samą funkcję.
    4. Pamiętaj, że zmiana nazwy jest dozwolona i pożądana, jeśli funkcja lub kontekst elementu ulega zmianie.

    Notatka: Zanim zajrzysz do rozwiązania, przetestuj i zapisz swoje wnioski na kartce.
    Proponowane narzędzia: Klawiatura (Tab, Shift + Tab, Spacja, ), Myszka, Narzędzie deweloperskie (ang.) Developer Tools, NVDA

    Link: https://pdc.ambiscale.com/training/wcag-3-2-4/

    #1 BŁĄD

    Problem: Mimo identycznej ikony lupy, na stronie głównej przycisk ma aria-label="Szukaj", a na podstronie sklepu aria-label="Wyszukiwarka".
    Dlaczego: Jest to błąd opisany w technice F31. Zastosowano dwie różne nazwy programowalne dla komponentu realizującego tę samą funkcję. Użytkownik czytnika ekranu może uznać, że to dwie różne funkcjonalności.
    Naprawa: Ujednolic atrybut aria-label na wszystkich podstronach (np. wszędzie „Szukaj”).

    #2 BŁĄD

    Problem: Zmieniono widoczną etykietę tekstową linku prowadzącego do tego samego adresu URL z „Koszyk” na „Twój koszyk”.
    Dlaczego: Łamie to zasadę spójnej identyfikacji. Tekst widoczny dla oka musi być niezmienny, aby użytkownik nie musiał analizować, czy „Twój koszyk” to to samo co „Koszyk”.
    Naprawa: Używaj konsekwentnie jednej nazwy, np. „Koszyk”.

    #3 DOBRZE

    Dlaczego: Przyciski w formularzach na obu podstronach pełnią tę samą funkcję (zapisanie wprowadzonych danych na serwerze) i posiadają identyczną etykietę „Zapisz zmiany”. Jest to wzorcowe zachowanie.

    #4 DOBRZE

    Dlaczego: Choć oba przyciski używają ikony drukarki i inicjują proces drukowania, różnią się efektem końcowym (drukują inny dokument). Zróżnicowanie nazw programowalnych na „Drukuj podsumowanie” i „Drukuj fakturę” jest w pełni poprawne, ponieważ precyzuje kontekst akcji.

    #5 DOBRZE

    Dlaczego: Po kliknięciu „Edytuj dane” ten sam obszar przechodzi w tryb edycji (pole z etykietą + „Zapisz dane”). Zmiana etykiety jest poprawna, bo funkcja komponentu realnie się zmienia. Imię jest zapisywane w localStorage i od razu widać je w trybie odczytu.

    #6 BŁĄD

    Problem: Obie ikony mają identyczną nazwę programowalną aria-label="Usuń" i pełnią tę samą funkcję, ale użyto dla nich zupełnie innych grafik (kosz na śmieci vs. krzyżyk).
    Dlaczego: Spójna identyfikacja dotyczy również warstwy wizualnej. Zmiana grafiki przy zachowaniu tej samej funkcji to błąd projektowy, który dezorientuje widzących użytkowników.
    Naprawa: Zastosuj jedną, wybraną ikonę (np. kosz) w całym serwisie do akcji usuwania.

    Źródła

    Dodatkowe linki

    Wróć do wszystkich kryteriów