WCAG 3.2.6: Spójna pomoc

Co Oznacza Ta Zasada

Kryterium sukcesu WCAG 3.2.6 Consistent Help (Poziom AA, wprowadzone w WCAG 2.2) stanowi: „Jeśli strona internetowa zawiera którykolwiek z poniższych mechanizmów pomocy i mechanizmy te są powtarzane na wielu stronach internetowych, występują one w tej samej względnej kolejności względem pozostałej treści strony, chyba że zmiana została zainicjowana przez użytkownika.” Mechanizmy pomocy objęte tym kryterium to: dane kontaktowe do człowieka (takie jak numer telefonu, adres e‑mail lub godziny pracy), mechanizm kontaktu z człowiekiem (taki jak widżet czatu na żywo lub formularz kontaktowy), opcja samopomocy (taka jak strona z często zadawanymi pytaniami, centrum pomocy lub baza wiedzy) oraz w pełni zautomatyzowany mechanizm kontaktu (taki jak chatbot lub wirtualny asystent).

Kluczowym wymaganiem jest spójność względnej kolejności, a nie identyczne położenie w pikselach. Jeśli przycisk czatu na żywo pojawia się w prawym dolnym rogu strony głównej, musi pojawiać się w tym samym prawym dolnym położeniu na każdej innej stronie, na której jest wyświetlany. Jeśli link „Help” jest trzecim elementem w górnym pasku nawigacyjnym na jednej stronie, musi pozostać trzecim elementem — lub przynajmniej zachować ten sam względny związek z otaczającą treścią — na wszystkich innych stronach, na których ten pasek nawigacyjny się pojawia.

Strona spełnia to kryterium, gdy: (a) na stronie nie istnieje żaden mechanizm pomocy, lub (b) mechanizm pomocy istnieje tylko na jednej stronie, lub (c) wszędzie tam, gdzie mechanizm pomocy jest powtarzany na wielu stronach, pojawia się w tej samej względnej kolejności w układzie strony. Strona nie spełnia kryterium, gdy mechanizm pomocy obecny na wielu stronach zmienia swoje położenie w kolejności elementów strony z jednej strony na drugą bez zainicjowania tej zmiany przez użytkownika — na przykład widżet czatu, który na stronie listy produktów unosi się w prawym dolnym rogu, ale na stronie płatności przenosi się do lewego dolnego rogu.

Kryterium zawiera wyraźny wyjątek: kolejność może się zmienić, jeśli zmiana jest zainicjowana przez użytkownika. Na przykład, jeśli użytkownik przeciąga i zmienia położenie pływającego widżetu pomocy lub jeśli preferencja użytkownika przełącza panel pomocy z jednej strony na drugą, taka zmiana położenia jest zainicjowana przez użytkownika i nie stanowi naruszenia. Ten wyjątek odzwierciedla tę samą logikę inicjowaną przez użytkownika, która występuje w SC 3.2.2 (On Input).

Ważne jest, aby zauważyć, że to kryterium nie wymaga, aby każda strona miała mechanizm pomocy, ani nie wymaga, aby mechanizm pomocy był skuteczny lub łatwy w użyciu. Reguluje ono jedynie spójność położenia, gdy mechanizm jest obecny na wielu stronach.

Dlaczego To Ma Znaczenie

Spójne umiejscowienie pomocy ma przede wszystkim służyć użytkownikom z niepełnosprawnościami poznawczymi, w tym osobom z zaburzeniami pamięci, trudnościami z koncentracją, specyficznymi trudnościami w uczeniu się, takimi jak dysleksja, oraz schorzeniami takimi jak ADHD czy wczesne stadium demencji. Dla tych użytkowników odnalezienie znanego elementu interfejsu wymaga świadomego wysiłku poznawczego. Gdy przycisk pomocy lub link kontaktowy pojawia się w innym miejscu na każdej stronie, muszą oni ponawiać ten wysiłek, co zwiększa obciążenie poznawcze oraz ryzyko frustracji, dezorientacji lub porzucenia zadania.

Użytkownicy, którzy są nowi w internecie lub mają ograniczone kompetencje cyfrowe — co stanowi znaczną populację w Turcji i na całym świecie — również w dużym stopniu polegają na przewidywalnym umiejscowieniu. Według Światowej Organizacji Zdrowia ponad 1,3 miliarda osób na świecie żyje z jakąś formą niepełnosprawności, a schorzenia poznawcze i neurologiczne stanowią znaczną część tej populacji. Projektowanie pod kątem spójności położenia służy zatem szerokiej grupie odbiorców, znacznie wykraczającej poza osoby z klinicznie zdiagnozowanymi niepełnosprawnościami.

Rozważmy konkretny scenariusz: użytkowniczka z wczesnym stadium choroby Alzheimera próbuje dokończyć rezerwację lotu online. Pamięta, że na stronie linii lotniczej jest opcja czatu na żywo, z której może skorzystać, gdy się pogubi. Na stronie wyników wyszukiwania ikona czatu pojawia się w prawym dolnym rogu. Jednak gdy przechodzi do strony wyboru miejsca, widżet czatu został przeniesiony do prawego górnego rogu, do zwijanego panelu pomocy. Nie może go znaleźć, czuje się przytłoczona i całkowicie porzuca rezerwację. Jest to bezpośredne, możliwe do uniknięcia naruszenie SC 3.2.6.

Dla użytkowników z niepełnosprawnością ruchową, którzy nawigują za pomocą przełączników, oprogramowania śledzącego ruch gałek ocznych lub wskaźników nagłownych, zmiana położenia mechanizmu pomocy oznacza ponowne skanowanie i ponowne celowanie w nowy obszar ekranu — proces wymagający wysiłku i czasochłonny, którego spójne umiejscowienie pozwala uniknąć.

Użytkownicy czytników ekranu, którzy zapamiętali kolejność tabulacji lub strukturę nagłówków witryny, aby szybko dotrzeć do sekcji pomocy, są w równym stopniu dotknięci, gdy kolejność DOM tego mechanizmu zmienia się z jednej strony na drugą, nawet jeśli pozycja wizualna wygląda podobnie.

Poza dostępnością istnieje wyraźna korzyść użytecznościowa i biznesowa: użytkownicy, którzy mogą szybko znaleźć pomoc, rzadziej porzucają transakcję, co zmniejsza wskaźniki rezygnacji i koszty wsparcia. Spójne wzorce interfejsu użytkownika wzmacniają również zaufanie do marki i profesjonalizm.

Powiązane Reguły Axe-core

WCAG 3.2.6 jest sklasyfikowane jako wymagające wyłącznie testów manualnych i nie ma odpowiadającej mu zautomatyzowanej reguły axe-core, która mogłaby programowo wykrywać naruszenia. Jest to zamierzone, a zrozumienie przyczyn pomaga testerom lepiej pojąć naturę tego kryterium.

• Wymagana inspekcja manualna — brak dostępnej reguły axe: Narzędzia automatyczne, takie jak axe-core, Lighthouse czy IBM Equal Access Checker, analizują pojedynczą stronę w izolacji. Nie mają wrodzonego zrozumienia, czym jest „mechanizm pomocy”, nie potrafią porównać względnej pozycji elementu w DOM na wielu załadowaniach stron lub adresach URL ani określić, czy dany element pełni funkcjonalną rolę zapewniania pomocy. Widżet czatu, na przykład, może być zaimplementowany jako zwykły <div>, komponent shadow DOM, <iframe> lub skrypt wstrzykiwany przez podmiot trzeci — żaden z nich nie może być wiarygodnie zidentyfikowany jako „mechanizm pomocy” przez silnik reguł bez osądu człowieka. Aby to wykrywać, axe-core musiałby mieć świadomość stanu między stronami oraz rozpoznawanie intencji semantycznej, czyli możliwości wykraczające poza zakres statycznej analizy pojedynczej strony. Dlatego samo WCAG 2.2 oznacza 3.2.6 jako kryterium wymagające oceny przez człowieka poprzez ustrukturyzowane audyty manualne i porównania między stronami.

Jak Testować

1. Sporządź inwentarz mechanizmów pomocy: Przed testowaniem poszczególnych stron utwórz listę wszystkich mechanizmów pomocy obecnych w witrynie — widżetów czatu na żywo, numerów telefonów kontaktowych, linków e‑mail, linków do FAQ, launcherów chatbotów, formularzy kontaktowych i linków do centrum pomocy. Zanotuj, na których stronach pojawia się każdy mechanizm. Jeśli mechanizm pojawia się tylko na jednej stronie, jest poza zakresem tego kryterium.
2. Uruchom skan automatyczny dla kontekstu bazowego: Użyj axe DevTools (rozszerzenie przeglądarki) lub Lighthouse na reprezentatywnych stronach, aby uchwycić migawki kolejności DOM i zidentyfikować strukturalne położenie elementów związanych z pomocą. Chociaż żadna reguła axe nie jest bezpośrednio skierowana na SC 3.2.6, kolejność DOM raportowana przez te narzędzia można ręcznie porównać między stronami. Wyeksportuj lub wykonaj zrzut ekranu drzewa dostępności dla każdej strony zawierającej mechanizm pomocy.
3. Porównaj względne położenie między stronami: Otwórz dwie lub więcej stron, które współdzielą ten sam mechanizm pomocy, obok siebie (lub kolejno). Dla każdego mechanizmu zidentyfikuj jego położenie względem otaczających regionów orientacyjnych (<header>, <main>, <footer>, <nav>). Zapisz, czy mechanizm pojawia się w tym samym regionie orientacyjnym i w tej samej względnej kolejności (przed lub po sąsiednich elementach) na każdej stronie. Zmiana położenia stanowi potencjalne naruszenie.
4. Przetestuj nawigację klawiaturą (wszystkie przeglądarki): Przejdź przez każdą stronę zawierającą mechanizm pomocy za pomocą klawisza Tab. Policz liczbę kroków tabulacji potrzebnych, aby dotrzeć do mechanizmu pomocy od początku strony. Porównaj tę liczbę między stronami. Znacząca różnica — na przykład osiągalny w 5 krokach na stronie głównej, ale w 47 krokach na stronie płatności — wskazuje na zmianę kolejności DOM, nawet jeśli pozycja wizualna wydaje się podobna.
5. Przetestuj z NVDA + Firefox: Otwórz listę elementów NVDA (klawisz NVDA + F7) i przełącz się na widok Links lub Buttons. Zlokalizuj mechanizm pomocy na liście. Zanotuj jego położenie względem innych wymienionych elementów. Powtórz na każdej stronie, na której mechanizm się pojawia, i porównaj pozycje.
6. Przetestuj z VoiceOver + Safari (macOS/iOS): Użyj rotora VoiceOver (VO + U), aby otworzyć listę Links lub Form Controls. Przejdź do mechanizmu pomocy i zanotuj jego położenie na liście. Porównaj między stronami.
7. Przetestuj z JAWS + Chrome: Użyj listy linków JAWS (Insert + F7), aby zlokalizować mechanizm pomocy. Zanotuj jego pozycję porządkową i sąsiednie elementy. Powtórz na wielu stronach.
8. Sprawdź wyjątki inicjowane przez użytkownika: Jeśli witryna pozwala użytkownikom na zmianę położenia lub ukrywanie mechanizmów pomocy (np. przeciągany widżet czatu), zweryfikuj, że zmiana położenia jest wywołana wyraźnym działaniem użytkownika i że preferencja jest logicznie utrwalana. Udokumentuj to jako prawidłowy wyjątek w ramach kryterium.
9. Przejrzyj widoki mobilne: Układy responsywne czasami zmieniają kolejność elementów DOM przy różnych punktach przerwania. Przetestuj zarówno na widokach desktopowych, jak i mobilnych (szerokości 375px i 1440px jako minimum), aby potwierdzić, że mechanizm pomocy zachowuje spójne względne położenie przy wszystkich typowych rozmiarach ekranu.

Jak Naprawić

Pływający widżet czatu — Nieprawidłowo

<!-- Page A (homepage): chat button in bottom-right -->
<div class='chat-widget' style='position:fixed; bottom:20px; right:20px;'>
  <button>Chat with Us</button>
</div>

<!-- Page B (checkout): chat button moved to bottom-left -->
<div class='chat-widget' style='position:fixed; bottom:20px; left:20px;'>
  <button>Chat with Us</button>
</div>
<!-- FAIL: The widget changes its fixed position between pages,
     breaking consistent help placement. -->

Pływający widżet czatu — Prawidłowo

<!-- Both Page A and Page B: chat button consistently in bottom-right -->
<div class='chat-widget chat-widget--bottom-right'>
  <button type='button' aria-label='Open live chat support'>
    Chat with Us
  </button>
</div>
<!-- PASS: The widget appears in the same corner on every page.
     Use a CSS class defined in a shared stylesheet rather than
     inline styles, so the position is controlled centrally and
     applied consistently across all templates. -->

Link pomocy w nawigacji — Nieprawidłowo

<!-- Page A: Help is the 4th nav item -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/pricing'>Pricing</a></li>
    <li><a href='/help'>Help</a></li>
  </ul>
</nav>

<!-- Page B (product detail): Help link removed from nav,
     placed in a footer section instead -->
<footer>
  <a href='/help'>Help Center</a>
</footer>
<!-- FAIL: The Help link has moved from the main navigation
     to the footer, changing its relative order significantly. -->

Link pomocy w nawigacji — Prawidłowo

<!-- Both Page A and Page B share the same navigation template -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/pricing'>Pricing</a></li>
    <li><a href='/help'>Help</a></li>
  </ul>
</nav>
<!-- PASS: The Help link is the 4th item in the main nav
     on every page where the nav is present. Using a shared
     navigation component or server-side include ensures
     this is maintained automatically. -->

Warunkowe wyświetlanie pomocy — Nieprawidłowo

<!-- On logged-out pages: phone number in header -->
<header>
  <p>Need help? Call <a href='tel:+908501234567'>0850 123 45 67</a></p>
</header>

<!-- On logged-in pages: phone number removed from header,
     only available deep inside an account dropdown menu -->
<header>
  <nav aria-label='Account menu'>
    <details>
      <summary>My Account</summary>
      <ul>
        <li><a href='/orders'>Orders</a></li>
        <li><a href='/contact'>Contact: 0850 123 45 67</a></li>
      </ul>
    <details>
  </nav>
</header>
<!-- FAIL: The contact number changes its relative position
     dramatically depending on authentication state,
     making it unpredictable for returning users. -->

Warunkowe wyświetlanie pomocy — Prawidłowo

<!-- Both logged-out and logged-in pages: phone in the same header position -->
<header>
  <div class='header-support'>
    <a href='tel:+908501234567' aria-label='Call support: 0850 123 45 67'>
      <svg aria-hidden='true' focusable='false'><!-- phone icon --></svg>
      0850 123 45 67
    </a>
  </div>
  <nav aria-label='Account menu'>
    <!-- account links here -->
  </nav>
</header>
<!-- PASS: The contact mechanism is always in the same position
     within the header regardless of authentication state.
     Additional account-specific links can appear elsewhere
     without moving the help mechanism. -->

Najczęstsze Błędy

• Umieszczanie widżetu czatu w różnych rogach na różnych szablonach stron: Zespoły deweloperskie często stosują pozycjonowanie stałe widżetów czatu osobno dla każdego szablonu, zamiast przez globalny arkusz stylów, co powoduje, że widżet pojawia się w prawym dolnym rogu na stronach marketingowych, a w lewym dolnym rogu na stronach aplikacji. Użyj pojedynczego, globalnie dołączanego komponentu z klasą o stałym położeniu.
• Usuwanie linku pomocy z nawigacji na stronach płatności w celu zmniejszenia „bałaganu”: Niektóre wzorce UX celowo ograniczają nawigację na stronach płatności, aby zwiększyć konwersję. Jeśli mechanizm pomocy jest częścią tej nawigacji, usunięcie go z tego szablonu strony narusza spójność. Zamiast tego zachowaj link pomocy w minimalnym nagłówku nawet w uproszczonych przepływach płatności.
• Wstrzykiwanie mechanizmów pomocy przez skrypty podmiotów trzecich, które ładują się w nieprzewidywalnych pozycjach DOM: Wiele SDK czatu na żywo wstrzykuje swój widżet do DOM asynchronicznie, a punkt wstawienia może się różnić w zależności od kolejności ładowania skryptów. Może to powodować, że widżet pojawia się w innej pozycji w drzewie dostępności na różnych stronach. Skonfiguruj widżety podmiotów trzecich tak, aby zawsze były dołączane do stałego, znanego elementu kotwiczącego w DOM.
• Używanie CSS order lub zmiany kolejności flexbox/grid do wizualnego przenoszenia elementu pomocy bez zmiany kolejności DOM, a następnie zmienianie tego CSS na poszczególnych stronach: Chociaż pozycja wizualna może wydawać się spójna, nadpisania CSS per strona, które zmieniają wizualną kolejność mechanizmu pomocy, nadal zmieniają postrzeganą przez użytkownika kolejność i mogą dezorientować użytkowników czytników ekranu, których kolejność czytania podąża za DOM.
• Poleganie na narzędziach do testów A/B, które zamieniają położenie elementu pomocy między wariantami testu: Jeśli użytkownicy w wariancie A widzą przycisk pomocy w górnym pasku, a użytkownicy w wariancie B widzą go w stopce, ci użytkownicy doświadczą niespójnego umiejscowienia pomocy na stronach w ramach swojej sesji, gdy framework A/B zastosuje różne warianty na różnych stronach. Upewnij się, że testy A/B wpływające na położenie mechanizmu pomocy stosują wariant spójnie na wszystkich stronach w sesji.
• Traktowanie stanów uwierzytelnionych i nieuwierzytelnionych jako różnych „witryn” i stosowanie różnych układów pomocy: Użytkownicy, którzy logują się w trakcie sesji, nagle znajdą mechanizm pomocy w nowym miejscu. Zmiana stanu uwierzytelnienia nie jest zmianą zainicjowaną przez użytkownika w kontekście umiejscowienia pomocy, więc nadal stanowi naruszenie SC 3.2.6. Zastosuj spójny układ pomocy we wszystkich stanach uwierzytelnienia.
• Umieszczanie numeru telefonu pomocy tylko w gęstym tekście stopki na niektórych stronach, a w dedykowanym pasku nagłówka na innych: Nawet jeśli numer telefonu jest technicznie obecny na wszystkich stronach, znacząca zmiana jego względnego położenia (z pierwszego interaktywnego elementu w nagłówku na ukryty w stopce po setkach linków) jest naruszeniem spójnej kolejności.
• Zakładanie, że skoro ikona pomocy jest zawsze wizualnie „w rogu”, kryterium jest spełnione: Kryterium mierzy względną kolejność w treści strony, a nie tylko bezwzględne współrzędne pikseli. Ikona czatu, która jest zawsze wizualnie w prawym dolnym rogu, ale pojawia się w zupełnie innym miejscu w kolejności DOM na różnych stronach (np. bezpośrednio po tagu <body> na jednej stronie i tuż przed zamykającym tagiem </body> na innej), może nadal stanowić naruszenie dla użytkowników klawiatury i czytników ekranu.
• Zapominanie o audycie punktów przerwania responsywności: Mechanizm pomocy, który jest spójny przy szerokościach desktopowych, może być ukryty lub przeniesiony do mobilnego menu hamburgerowego przy węższych widokach, co skutkuje inną pozycją na urządzeniach mobilnych. Jeśli użytkownicy mobilni doświadczają innego względnego położenia niż użytkownicy desktopowi, należy to ocenić w kontekście kryterium — szczególnie jeśli urządzenia mobilne są główną metodą dostępu dla grupy docelowej.
• Brak dokumentowania lokalizacji mechanizmów pomocy w systemach projektowych: Bez udokumentowanego standardu określającego, gdzie muszą pojawiać się mechanizmy pomocy, poszczególni deweloperzy i projektanci będą podejmować niezależne decyzje, które z czasem doprowadzą do niespójności. Dodaj zasady umiejscowienia mechanizmów pomocy wprost do dokumentacji systemu projektowego lub biblioteki komponentów.

Związek z Przepisami Dotyczącymi Dostępności w Turcji

Turecka Okrężnica Prezydencka 2025/10, opublikowana w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia kompleksowe krajowe ramy dla dostępności cyfrowej. Okrężnica nakazuje zgodność z WCAG 2.2 Poziom AA jako podstawowym standardem dostępności dla szerokiego zakresu usług cyfrowych działających w Turcji. WCAG 3.2.6 Consistent Help, jako kryterium poziomu AA wprowadzone w WCAG 2.2, wchodzi bezpośrednio w zakres tego obowiązku prawnego.

Typy podmiotów objęte Okrężnicą Prezydencką 2025/10 obejmują: instytucje i agencje publiczne na szczeblu centralnym i lokalnym; banki i dostawców usług finansowych regulowanych przez Banking Regulation and Supervision Agency (BDDK); platformy e‑commerce i rynki internetowe; szpitale i świadczeniodawców opieki zdrowotnej oferujących usługi cyfrowe skierowane do pacjentów; firmy telekomunikacyjne z 200,000 lub większą liczbą abonentów; biura podróży z systemami rezerwacji online; prywatne firmy transportowe obsługujące regularne przewozy; oraz prywatne szkoły i instytucje edukacyjne upoważnione przez Ministry of National Education (MoNE). Dla wszystkich tych podmiotów pełen zestaw kryteriów WCAG 2.2 Poziom AA — w tym SC 3.2.6 — jest obowiązującym standardem.

Zgodność z WCAG 3.2.6 jest również warunkiem uzyskania Erişilebilirlik Logosu (Logotypu Dostępności) wydawanego przez tureckie Ministerstwo Rodziny i Usług Społecznych (Aile ve Sosyal Hizmetler Bakanlığı). Logo to stanowi oficjalne oznaczenie zgodności z wymogami dostępności i jest coraz częściej rozpoznawane przez tureckich konsumentów oraz osoby odpowiedzialne za zamówienia publiczne jako sygnał jakości. Organizacje ubiegające się o to logo muszą wykazać pełną zgodność z WCAG 2.2 Poziom AA we wszystkich swoich zasobach cyfrowych, co oznacza, że niespójne umiejscowienie pomocy — nawet pozornie drobne — może zdyskwalifikować wniosek.

Z praktycznego punktu widzenia zgodność z SC 3.2.6 ma szczególne znaczenie dla tureckich dostawców usług e‑commerce i finansowych, których witryny i aplikacje webowe na urządzenia mobilne zazwyczaj oferują widżety czatu na żywo, linki kontaktowe WhatsApp oraz sekcje FAQ jako główne kanały wsparcia klienta. Zapewnienie, że te mechanizmy pomocy pojawiają się w spójnych pozycjach na stronach list produktów, stronach koszyka, w przepływach płatności i sekcjach zarządzania kontem, jest zarówno obowiązkiem prawnym wynikającym z Okrężnicy, jak i dobrą praktyką UX w obsłudze zróżnicowanej bazy użytkowników internetu w Turcji — obejmującej dużą populację użytkowników po raz pierwszy korzystających z sieci i osób o niskich kompetencjach cyfrowych, które najbardziej korzystają z przewidywalnych wzorców interfejsu.

Organizacje objęte Okrężnicą, które nie przeprowadziły jeszcze audytu umiejscowienia mechanizmów pomocy, powinny nadać priorytet audytowi spójności między stronami jako części swojej mapy drogowej zgodności z WCAG 2.2. Ponieważ to kryterium wymaga testów manualnych, należy je uwzględnić zarówno w początkowych audytach zgodności, jak i w bieżących cyklach zapewniania jakości, szczególnie po większych przeprojektowaniach lub zmianach szablonów, które mogą nieumyślnie zmienić położenie elementów pomocy.