Information architecture: 7 błędów, które ograniczają dostępność

Architektura informacji określa, jak treści i funkcje są pogrupowane, nazwane oraz połączone w serwisie. Dostępność zależy od tego, czy użytkownik potrafi zrozumieć tę strukturę i przejść do celu bez polegania wyłącznie na wzroku, precyzyjnym klikaniu lub pamięci.

Menu, kategorie, nagłówki, wyszukiwarka i okruszki nawigacyjne tworzą wspólnie mapę serwisu. Osoba korzystająca z klawiatury potrzebuje widocznego fokusu, czyli oznaczenia elementu, który aktualnie przyjmuje działanie klawiatury, oraz przewidywalnej kolejności przejścia. Czytnik ekranu odczytuje nazwy i relacje zapisane w kodzie, dlatego samo wizualne wyróżnienie elementu nie zastępuje poprawnej struktury semantycznej.

WCAG 2.2 obejmuje kryteria dotyczące między innymi tytułów stron, kolejności fokusu, celu linków, nagłówków i etykiet, widocznego fokusu oraz lokalizacji użytkownika. Wymagania ocenia się na konkretnym interfejsie, a obecność menu sama w sobie nie potwierdza zgodności. Szerszy zakres oceny opisujemy w przewodniku po audycie WCAG.

Dostępna nawigacja wspiera wybór produktu, porównanie wariantów, kontakt i zakup. Z naszych wdrożeń wynika, że analizę warto prowadzić na rzeczywistych ścieżkach użytkownika, a nie tylko na stronie głównej. Zespołom, które chcą ustalić zakres problemów w całym serwisie, niezależna ocena ścieżek cyfrowych pomaga uporządkować bariery i plan napraw. Bariery na ścieżce zakupowej omawiamy także w artykule o dostępnym sklepie WooCommerce.

Nazwa kategorii powinna opisywać jej zawartość językiem klienta, a nie wewnętrznym kodem firmy. Etykieta "Akcesoria" jest mało pomocna, jeśli obejmuje części zamienne, środki czyszczące i wyposażenie podróżne.

Porównaj nazwy używane przez zespół z określeniami klientów z wyszukiwarki, zapytań do obsługi i filtrów sklepu. Nazwa "Rozwiązania" może być zrozumiała wewnętrznie, ale nie podpowiada nowej osobie, czy znajdzie usługę, produkt czy dokumentację. Nazwa "Części do odkurzaczy" precyzyjniej wskazuje zawartość.

Test sortowania kart sprawdza, czy użytkownicy przypisują treści do podobnych grup. Przygotuj karty z nazwami produktów lub tematów i poproś uczestników o samodzielne grupowanie. Zapisz nadane grupom nazwy, miejsca sporu i karty przypisane do różnych kategorii. Wynik pokazuje, jak ludzie organizują treści bez podpowiedzi gotowego menu.

Jeśli grupy są spójne, ale etykieta nie opisuje zawartości, zmień nazwę. Jeśli uczestnicy konsekwentnie rozdzielają produkty inaczej niż sklep, sprawdź strukturę kategorii, zamiast ograniczać poprawkę do tekstu etykiety.

Menu utrudnia nawigację, gdy użytkownik musi przejść przez zagnieżdżone poziomy albo nie potrafi przewidzieć, co znajduje się po rozwinięciu pozycji. Sama liczba poziomów nie przesądza o błędzie, ale każda kolejna decyzja wymaga czytelnych nazw i poprawnej obsługi klawiaturą.

Oceń najgłębszą ścieżkę od strony głównej do ważnej kategorii, powtarzające się pozycje i nazwy różniące się tylko wewnętrznym skrótem. Przejdź menu klawiszem Tab i sprawdź widoczność fokusu, otwieranie podmenu, możliwość jego zamknięcia oraz kolejność przechodzenia. Zachowanie strzałek zależy od zastosowanego wzorca, więc sprawdź je w konkretnym komponencie.

Tabela pomaga ocenić, które części drzewa wymagają przeglądu etykiet, struktury albo obsługi klawiaturą. Dla każdej ważnej ścieżki zanotuj liczbę poziomów i wynik próby klawiaturą.

Wniosek: zacznij od nazw i powtarzalności kategorii, a przebudowę drzewa rozważ, gdy użytkownicy inaczej grupują treści lub nie mogą odnaleźć ważnego celu.

Nagłówki powinny opisywać temat kolejnych części i odzwierciedlać ich hierarchię w kodzie. Tekst, który tylko wygląda jak tytuł, ale nie jest oznaczony semantycznie jako nagłówek, nie daje czytnikowi ekranu tej samej informacji.

Nagłówek H1 opisuje główny temat strony, a nagłówki kolejnych poziomów dzielą treść na części i podsekcje. Nie wybieraj poziomu nagłówka wyłącznie ze względu na rozmiar fontu. Przeskok z H2 do H4 bez uzasadnienia może zaburzyć strukturę dokumentu.

Kolejność w kodzie powinna odpowiadać sensownej kolejności czytania. Jeśli wizualny układ umieszcza cenę, opis i przycisk w innej kolejności niż odczyt dla technologii asystujących, użytkownik może otrzymać mylący przebieg informacji. W3C wyjaśnia, że semantyczne nagłówki pomagają orientować się w strukturze i nawigować po stronie.

W audycie przejrzyj listę nagłówków przy użyciu czytnika ekranu lub inspektora dostępności, a następnie porównaj ją z wizualnym układem. Zmiana CSS może poprawić wygląd, ale nie naprawi braku semantycznego nagłówka ani błędnej kolejności odczytu.

Nazwa linku lub przycisku powinna wyjaśniać jego cel bez konieczności zgadywania. Etykiety "więcej", "sprawdź" i "kliknij" nie wskazują, jaką treść użytkownik otworzy ani jakie działanie wykona.

W sklepie zastąp "więcej" nazwą opisującą cel, na przykład "Zobacz wszystkie ekspresy do kawy". W formularzu użyj przycisku z nazwą rezultatu, na przykład "Wyślij zapytanie o wycenę". Linki o tej samej nazwie powinny prowadzić do tego samego celu.

Sprawdź listę odnośników oferowaną przez czytnik ekranu lub inspektor dostępności. Jeśli po odczytaniu samych nazw nie da się ustalić, dokąd prowadzą odnośniki, doprecyzuj je. WCAG dopuszcza ocenę celu linku z uwzględnieniem kontekstu, ale opisowa nazwa ułatwia rozpoznanie także poza zdaniem.

Link prowadzi do zasobu lub miejsca, a przycisk wykonuje działanie, takie jak wysłanie formularza albo rozwinięcie filtra. Użycie niewłaściwego elementu HTML może utrudnić obsługę klawiaturą i zrozumienie funkcji.

Tytuł strony, aktywna pozycja nawigacji i okruszki powinny informować użytkownika o jego lokalizacji. Okruszki pokazują relację bieżącej strony do nadrzędnych poziomów serwisu, a nie przypadkowy ciąg linków.

Użytkownik może wejść z wyszukiwarki bezpośrednio na kartę produktu, poradnik lub stronę kategorii. Tytuł powinien nazywać temat strony, a okruszki, jeśli występują, powinny odwzorowywać rzeczywistą hierarchię. Bieżąca lokalizacja nie powinna wyglądać jak zwykły link prowadzący do tej samej strony bez wyraźnego powodu.

Wyróżnienie aktywnej sekcji nie może zależeć wyłącznie od koloru. Jeśli nawigacja przekazuje stan aktywnej pozycji, sprawdź, czy jest on również dostępny programowo. Przetestuj widoczność fokusu podczas przejścia klawiaturą. WCAG 2.2 opisuje lokalizację i tytuły stron jako elementy pomagające użytkownikom odnaleźć się w serwisie.

Gdy zmieniasz hierarchię kategorii, zaktualizuj również ścieżki w okruszkach. Użytkownik powinien móc przejść do kategorii nadrzędnej bez polegania wyłącznie na przycisku Wstecz przeglądarki.

Wyszukiwarka i filtry są dostępne, gdy użytkownik potrafi je nazwać, obsłużyć klawiaturą i zrozumieć rezultat zastosowania. Liczba wyników, aktywne kryteria oraz brak dopasowań powinny być przekazane w czytelny i programowo dostępny sposób.

Każde pole filtra powinno mieć etykietę, a grupy powiązanych opcji powinny mieć zrozumiałą nazwę. Po zastosowaniu filtra pokaż aktywne kryteria i umożliw usunięcie wybranego kryterium. Zapewnij także możliwość wyczyszczenia wszystkich filtrów i powrotu do pełnej listy.

Komunikat o liczbie wyników powinien aktualizować się po zmianie kryteriów. Jeśli lista przeładowuje się bez odświeżenia strony, informacja o zmianie powinna być dostępna dla technologii asystujących. Gdy lista jest pusta, podaj informację o braku dopasowań i sposób wyjścia z sytuacji, na przykład usunięcie filtra.

Tabela przedstawia scenariusze, które warto przejść klawiaturą i sprawdzić z czytnikiem ekranu. Każda zmiana kryterium powinna pozostawić użytkownika z jasną informacją o aktualnym wyniku.

Wniosek: dostępność filtrów ocenia się od wyboru kryterium do zrozumienia wyniku, a nie tylko po tym, czy kontrolki reagują na kliknięcie.

Audyt architektury informacji łączy przegląd struktury z testem zadań, obsługą klawiatury i kontrolą widoku mobilnego. Lista adresów URL nie pokazuje, czy użytkownik rozumie menu ani czy odzyska orientację po wejściu z wyszukiwarki.

Przeprowadź audyt w następującej kolejności:

1. Spisz najważniejsze typy stron, kategorie, elementy menu, okruszki, wyszukiwarkę i filtry.
2. Wykonaj test drzewa, czyli test odnajdywania celu w samej hierarchii bez graficznego menu.
3. Przejdź kluczowe zadania klawiaturą, sprawdzając kolejność Tab, widoczny fokus i zachowanie menu oraz filtrów.
4. Powtórz zadania na telefonie, także przy powiększeniu treści i w wąskim układzie.
5. Zapisz dowód problemu, barierę, zakres poprawki i metodę ponownego sprawdzenia.

Test drzewa odpowiada na pytanie, czy użytkownicy rozumieją hierarchię. Test sortowania kart pokazuje, jak samodzielnie grupują treści. Przejście klawiaturą sprawdza działający interfejs, więc żaden z tych testów nie zastępuje pozostałych.

Tabela łączy błąd, barierę i metodę kontroli, aby pomóc ustalić kolejność prac. Problem blokujący wybór produktu lub wysłanie formularza wymaga wcześniejszej reakcji niż niespójność etykiety, która nie uniemożliwia wykonania zadania.

Wniosek: zmień etykietę, gdy użytkownicy rozumieją strukturę, ale nie nazwę; przebuduj strukturę, gdy nie potrafią pogrupować lub odnaleźć treści. Jeśli potrzebujesz niezależnej oceny barier i priorytetów napraw, audyt cyfrowy obejmuje analizę ścieżek i rekomendacje dla zespołu.

Perspektywa KC Mobile: poprawki architektury informacji warto planować wspólnie z osobami odpowiedzialnymi za treść, projekt i wdrożenie. Zmiana nazwy może wymagać aktualizacji menu, filtrów, okruszków i odnośników, dlatego sprawdzamy ją w całej ścieżce użytkownika.

• WCAG accessibility in UX/UI: jak przełożyć zasady na interfejs
• Jak przygotować stronę internetową pod dostępność cyfrową WCAG
• Jak przygotować sklep Shoper do wymogów WCAG i Europejskiego Aktu o Dostępności
• Audyt stron produktowych w e-commerce: checklista i priorytety poprawek