WCAG 2.5.1: Gesty wskaźnika

Co Oznacza Ta Zasada

WCAG 2.5.1 Pointer Gestures wymaga, aby każda funkcjonalność na stronie internetowej, która opiera się na gestach wielopunktowych (gesty z użyciem dwóch lub więcej jednoczesnych punktów dotyku, takich jak szczypnięcie dwoma palcami w celu powiększenia lub przesunięcie trzema palcami) lub gestach opartych na ścieżce (gesty, w których istotna jest trasa przebyta przez wskaźnik, takie jak przesunięcie, przeciągnięcie wzdłuż określonej trasy lub narysowany kształt), była również obsługiwana za pomocą pojedynczego wskaźnika w sposób, który nie wymaga gestu opartego na ścieżce. Pojedynczy wskaźnik to każde wejście działające w jednym punkcie — obejmuje to dotknięcie jednym palcem, kliknięcie myszą, stuknięcie rysikiem i podobne metody wprowadzania.

W praktyce, jeśli Twój karuzelowy komponent zmienia slajdy, gdy użytkownik przesuwa po nim palcem poziomo, musisz również zapewnić przyciski „dalej” i „wstecz”, które można aktywować pojedynczym stuknięciem lub kliknięciem. Jeśli niestandardowy widżet mapy reaguje na szczypnięcie dwoma palcami w celu powiększenia lub pomniejszenia, musisz również zapewnić kontrolki powiększania i pomniejszania, które wymagają tylko pojedynczego stuknięcia. Kryterium nie zabrania gestów wielopunktowych ani opartych na ścieżce — wymaga jedynie, aby zawsze istniała równoważna alternatywa oparta na pojedynczym wskaźniku.

Oficjalny wyjątek WCAG stanowi: wymaganie nie ma zastosowania, gdy gest wielopunktowy lub oparty na ścieżce jest niezbędny. Gest niezbędny to taki, którego usunięcie zasadniczo zmieniłoby informacje lub funkcjonalność, a tekst lub inna alternatywa nie mogą osiągnąć tego samego celu. Widżet odręcznego podpisu lub aplikacja do rysowania, w której narysowana ścieżka jest samym wynikiem, kwalifikowałyby się jako niezbędne. Jednak zdecydowana większość interakcji nawigacyjnych, karuzel, map i suwaków nie kwalifikuje się do tego wyjątku, ponieważ można je odtworzyć za pomocą prostych alternatyw stuknięcia/kliknięcia bez utraty informacji.

To kryterium ma zastosowanie do wszystkich wejść wskaźnika: ekranów dotykowych, myszy, rysików, wskaźników śledzących ruch gałek ocznych i każdego innego urządzenia wskazującego. Jest to wymaganie na poziomie A w WCAG 2.2, co oznacza, że jest uważane za podstawowy wymóg dostępności, który musi zostać spełniony dla minimalnej zgodności.

Poprawna implementacja zapewnia co najmniej jeden mechanizm do wykonania każdej funkcji zależnej od gestu za pomocą pojedynczego punktu, aktywacji nieopartej na ścieżce — zazwyczaj widocznego przycisku, linku lub innej kontrolki z fokusem. Niepoprawna implementacja opiera się wyłącznie na geście przesunięcia, szczypnięcia, rozsunięcia, obrotu lub narysowanej ścieżki do wykonania funkcji, bez zapewnienia równoważnej alternatywy opartej na pojedynczym wskaźniku.

Dlaczego To Ma Znaczenie

Niepełnosprawności ruchowe dotyczą znaczącej części światowej populacji. Schorzenia takie jak choroba Parkinsona, drżenie samoistne, porażenie mózgowe, hemiplegia poudarowa, różnice w budowie kończyn oraz urazy wynikające z przeciążenia mogą utrudniać lub uniemożliwiać użytkownikom wykonywanie precyzyjnych gestów wielopunktowych lub opartych na ścieżce w sposób niezawodny. Według Światowej Organizacji Zdrowia około 1,3 miliarda ludzi na całym świecie żyje z jakąś formą znaczącej niepełnosprawności, a niepełnosprawności ruchowe i mobilnościowe należą do najczęstszych kategorii. Gdy interfejsy internetowe opierają się wyłącznie na złożonych gestach, użytkownicy ci są całkowicie pozbawieni funkcjonalności, którą widzący, pełnosprawni użytkownicy uważają za oczywistą.

Rozważ konkretny scenariusz z rzeczywistości: użytkownik z drżeniem samoistnym przegląda turecką stronę e-commerce na tablecie. Galeria obrazów produktu używa wyłącznie gestu przesunięcia do przechodzenia między zdjęciami. Użytkownik nie jest w stanie niezawodnie wykonać czystego poziomego przesunięcia — jego drżenie powoduje przypadkowe stuknięcia, ruchy po przekątnej lub przypadkowe dotknięcia wieloma palcami. Bez przycisków poprzedni/następny nie może zobaczyć dodatkowych zdjęć produktu i może całkowicie zrezygnować z zakupu. Dodanie dwóch prostych przycisków strzałek kosztuje zespół deweloperski kilka minut, ale usuwa całkowitą barierę dla tego użytkownika.

Poza niepełnosprawnościami ruchowymi, to kryterium przynosi korzyści także użytkownikom z protezami kończyn górnych lub urządzeniami jednoprzyciskowymi, które emulują pojedynczy wskaźnik, użytkownikom obsługującym urządzenia zamontowane na wózkach inwalidzkich, gdzie obracanie lub multi-touch jest mechanicznie niepraktyczne, oraz starszym osobom, które uważają złożone gesty dotykowe za nieintuicyjne lub trudne do opanowania. Użytkownicy obsługujący urządzenie za pomocą myszy lub nietykalnego rysika są również bezpośrednio dotknięci — te metody wprowadzania są z natury oparte na pojedynczym wskaźniku i w ogóle nie mogą wykonywać gestów wielopunktowych.

Z perspektywy użyteczności i biznesu zapewnienie wyraźnych kontrolek opartych na pojedynczym wskaźniku (przyciski, linki) poprawia także wykrywalność dla wszystkich użytkowników, zmniejsza obciążenie poznawcze i może pozytywnie wpływać na wskaźniki ukończenia zadań oraz konwersji. Wyszukiwarki mogą również bardziej niezawodnie analizować i śledzić nawigację opartą na przyciskach niż interakcje oparte na gestach, co daje wtórne korzyści SEO dla wzorców nawigacji możliwych do zindeksowania.

Powiązane Zasady Axe-core

WCAG 2.5.1 wymaga testów manualnych, ponieważ narzędzia automatyczne nie mogą niezawodnie wykryć, czy zachowanie zależne od gestu ma alternatywę opartą na pojedynczym wskaźniku. Żadna automatyczna zasada axe-core nie mapuje się bezpośrednio na to kryterium. Powody, dla których wykrywanie automatyczne jest niewystarczające, są następujące:

• Wymagane testy manualne — wykrywanie gestów: Automatyczne skanery analizują statyczną strukturę DOM i obliczone style. Nie mogą obserwować zachowania nasłuchiwaczy zdarzeń JavaScript w czasie rzeczywistym w sposób, który rozróżnia, czy obsługa touchstart/touchmove/touchend implementuje zależne od ścieżki przesunięcie, czy jedynie stuknięcie. Skaner widzi, że zdarzenia dotykowe są obecne, ale nie może ustalić, czy wynikowa funkcjonalność jest również dostępna poprzez alternatywę opartą na pojedynczym wskaźniku. Wymaga to, aby tester-ludzki wchodził w interakcję z interfejsem zarówno za pomocą metod opartych na gestach, jak i pojedynczym wskaźniku oraz porównał dostępną funkcjonalność.
• Wymagane testy manualne — weryfikacja równoważności: Nawet jeśli narzędzie mogłoby oznaczyć, że istnieje nasłuchiwacz gestu wielopunktowego, nie może ocenić, czy dostarczony przycisk lub link osiąga funkcjonalnie równoważne rezultaty. Weryfikacja równoważności — że alternatywa wywołuje ten sam rezultat, że jest widoczna i osiągalna oraz że nie jest ukryta za dodatkowym krokiem — wymaga ludzkiej oceny, zgodnej z intencją kryterium.
• Wymagane testy manualne — wyjątek gestu niezbędnego: Ustalenie, czy gest kwalifikuje się do wyjątku „niezbędny”, wymaga kontekstowego zrozumienia celu aplikacji, którego żadne automatyczne reguły nie mogą wiarygodnie ocenić.

Testerzy powinni używać narzędzi deweloperskich przeglądarki do inspekcji dołączonych nasłuchiwaczy zdarzeń (w Chrome DevTools kliknij prawym przyciskiem element, wybierz „Inspect”, a następnie przejdź do zakładki „Event Listeners”) jako punktu wyjścia do identyfikacji elementów posiadających obsługę zdarzeń dotykowych lub wskaźnikowych, a następnie ręcznie zweryfikować obecność i równoważność alternatyw opartych na pojedynczym wskaźniku.

Jak Testować

1. Uruchom automatyczny skan jako punkt odniesienia: Użyj axe DevTools, Lighthouse lub wbudowanego audytu widżetu Accsible, aby przeskanować stronę. Chociaż żadna reguła nie mapuje się bezpośrednio na 2.5.1, wyniki skanowania mogą wskazać powiązane problemy (takie jak brakujące kontrolki z fokusem), które dostarczają kontekstu do przeglądu manualnego. Zanotuj wszystkie elementy interaktywne oznaczone jako pozbawione obsługi klawiatury lub wskaźnika.
2. Zidentyfikuj funkcjonalność zależną od gestów: Ręcznie eksploruj stronę na urządzeniu dotykowym (lub używając emulacji urządzenia w przeglądarce Chrome DevTools — przełącz pasek narzędzi urządzenia i wchodź w interakcję, używając symulowanego dotyku). Szukaj karuzel, suwaków, map, akordeonów, galerii obrazów, paneli przewijanych, interfejsów przeciągnij-i-upuść, narzędzi do rysowania i wszelkich innych komponentów reagujących na gesty dotykowe. Udokumentuj każdą funkcję, którą odkryjesz, a która jest wyzwalana przez przesunięcie, szczypnięcie, obrót lub inny gest oparty na ścieżce lub wielopunktowy.
3. Spróbuj użyć odpowiedników opartych na pojedynczym wskaźniku: Dla każdej zidentyfikowanej funkcji zależnej od gestu spróbuj wykonać tę samą funkcję, używając wyłącznie pojedynczych stuknięć (lub kliknięć myszą na komputerze stacjonarnym). Sprawdź, czy istnieją widoczne kontrolki, takie jak przyciski, strzałki lub linki, które wywołują ten sam rezultat. Spróbuj obsłużyć te kontrolki za pomocą myszy, klawiatury (Tab, aby ustawić fokus, Enter/Spacja, aby aktywować) oraz czytnika ekranu.
4. Weryfikacja z czytnikiem ekranu (NVDA + Firefox): Uruchom NVDA i Firefox. Nawiguj po komponentach interaktywnych za pomocą klawiszy Tab i strzałek. Zweryfikuj, że kontrolki oparte na pojedynczym wskaźniku (przyciski, linki) dla funkcji opartych na gestach są ogłaszane przez czytnik ekranu, są osiągalne za pomocą klawiatury i wywołują oczekiwany rezultat po aktywacji.
5. Weryfikacja z czytnikiem ekranu (VoiceOver + Safari na iOS): Włącz VoiceOver na iPhonie lub iPadzie. Przesuwaj w prawo jednym palcem, aby nawigować po elementach. Zweryfikuj, że wszystkie kontrolki zapewniające alternatywy oparte na pojedynczym wskaźniku dla gestów są osiągalne i możliwe do aktywacji za pomocą gestu stuknięcia VoiceOver oraz że wywołują prawidłowy rezultat.
6. Weryfikacja z czytnikiem ekranu (JAWS + Chrome): Użyj JAWS z Chrome w systemie Windows. Przechodź klawiszem Tab po komponentach interaktywnych i zweryfikuj, że kontrolki alternatywne dla gestów są fokusowalne, prawidłowo opisane i działają.
7. Oceń wyjątek niezbędności: Dla każdej funkcji zależnej od gestu, która nie ma alternatywy opartej na pojedynczym wskaźniku, ustal, czy gest jest naprawdę niezbędny dla treści lub funkcjonalności. Jeśli nie możesz uzasadnić wyjątku, odnotuj to jako błąd. Udokumentuj swoje ustalenia za pomocą zrzutów ekranu i kroków do odtworzenia.

Jak Naprawić

Karuzela obrazów z nawigacją wyłącznie przesunięciem — Niepoprawne

<!-- Carousel that only listens for touch swipe events, no button controls -->
<div id='carousel' class='carousel'>
  <div class='slides'>
    <img src='product-1.jpg' alt='Product view 1'>
    <img src='product-2.jpg' alt='Product view 2'>
    <img src='product-3.jpg' alt='Product view 3'>
  </div>
</div>
<!-- JavaScript only adds touchstart/touchend swipe detection -->
<script>
  // Only gesture-based: no keyboard or click alternative
  carousel.addEventListener('touchstart', handleSwipeStart);
  carousel.addEventListener('touchend', handleSwipeEnd);
</script>

Karuzela obrazów z nawigacją wyłącznie przesunięciem — Poprawne

<!-- Carousel with both swipe gesture support AND visible single-pointer button controls -->
<div id='carousel' class='carousel' role='region' aria-label='Product images'>
  <button id='prev-btn' aria-label='Previous image' onclick='prevSlide()'>
    &lsaquo; Previous
  </button>
  <div class='slides'>
    <img src='product-1.jpg' alt='Product view 1'>
    <img src='product-2.jpg' alt='Product view 2'>
    <img src='product-3.jpg' alt='Product view 3'>
  </div>
  <button id='next-btn' aria-label='Next image' onclick='nextSlide()'>
    Next &rsaquo;
  </button>
</div>
<!-- Swipe is retained as an enhancement; buttons provide the single-pointer alternative -->
<script>
  carousel.addEventListener('touchstart', handleSwipeStart);
  carousel.addEventListener('touchend', handleSwipeEnd);
  function prevSlide() { /* move to previous slide */ }
  function nextSlide() { /* move to next slide */ }
</script>

Mapa z wyłącznie szczypnięciem do powiększania — Niepoprawne

<!-- Map widget that only responds to two-finger pinch gestures for zoom -->
<div id='map' class='map-widget'></div>
<script>
  // Only multipoint pinch gesture is wired up; no zoom buttons provided
  map.addEventListener('touchstart', detectPinch);
  map.addEventListener('touchmove', handlePinchZoom);
</script>

Mapa z wyłącznie szczypnięciem do powiększania — Poprawne

<!-- Map widget with pinch-to-zoom PLUS visible zoom controls for single-pointer access -->
<div class='map-container' role='application' aria-label='Interactive map'>
  <div id='map' class='map-widget'></div>
  <div class='map-controls'>
    <!-- Single-pointer alternatives for zoom in and out -->
    <button type='button' aria-label='Zoom in' onclick='mapZoomIn()'>+</button>
    <button type='button' aria-label='Zoom out' onclick='mapZoomOut()'>&minus;</button>
  </div>
</div>
<script>
  map.addEventListener('touchstart', detectPinch);
  map.addEventListener('touchmove', handlePinchZoom);
  function mapZoomIn() { /* increase zoom level by one step */ }
  function mapZoomOut() { /* decrease zoom level by one step */ }
</script>

Suwak zakresu z gestem przeciągania po ścieżce — Niepoprawne

<!-- Custom price range slider that only works by dragging a thumb along a track -->
<div class='price-slider' id='priceSlider'>
  <div class='track'>
    <div class='thumb' id='sliderThumb'></div>
  </div>
</div>
<!-- No keyboard support, no input field, no increment/decrement buttons -->

Suwak zakresu z gestem przeciągania po ścieżce — Poprawne

<!-- Use the native <input type='range'> which provides built-in keyboard and single-pointer support -->
<label for='priceRange'>Maximum price: <span id='priceValue'>500</span> TL</label>
<input
  type='range'
  id='priceRange'
  name='priceRange'
  min='0'
  max='1000'
  value='500'
  step='10'
  aria-valuemin='0'
  aria-valuemax='1000'
  aria-valuenow='500'
  aria-label='Maximum price in Turkish lira'
  oninput='document.getElementById("priceValue").textContent = this.value'
>
<!-- Native range input supports click, tap, keyboard arrow keys, and touch drag --
     covering all single-pointer and path-based interaction needs natively -->

Typowe Błędy

• Zapewnianie karuzel obsługiwanych wyłącznie przesunięciem, bez jakichkolwiek przycisków poprzedni/następny: Wiele bibliotek karuzel domyślnie obsługuje tylko gesty; deweloperzy muszą jawnie skonfigurować i wyrenderować przyciski nawigacyjne, aby zapewnić alternatywę opartą na pojedynczym wskaźniku.
• Ukrywanie przycisków nawigacyjnych na urządzeniach dotykowych za pomocą zapytań medialnych CSS: Powszechny wzorzec ukrywa przyciski strzałek na ekranach, które są uznawane za urządzenia dotykowe (np. @media (pointer: coarse)), usuwając alternatywę opartą na pojedynczym wskaźniku dla użytkowników z niepełnosprawnościami ruchowymi, którzy polegają na niej nawet na ekranach dotykowych.
• Poleganie wyłącznie na geście szczypnięcia dwoma palcami do powiększania mapy bez oferowania przycisków powiększania: Osadzenia map firm trzecich (niestandardowe implementacje) często pomijają kontrolki powiększania, pozostawiając szczypnięcie jako jedyny mechanizm powiększania.
• Używanie wzorców „przesuń, aby usunąć” lub „przesuń, aby odsłonić” bez alternatywnego przycisku akcji: Elementy list w aplikacjach webowych, które odsłaniają opcje usunięcia lub akcji wyłącznie poprzez poziome przesunięcie, nie mają równoważnego mechanizmu opartego na stuknięciu dla użytkowników, którzy nie mogą niezawodnie przesuwać.
• Niestandardowe interfejsy przeciągnij-i-upuść, które nie mają alternatywy opartej na klawiaturze lub kliknięciu do zmiany kolejności: Interakcje przeciągania są z natury oparte na ścieżce; brak alternatywnego mechanizmu (takiego jak przyciski góra/dół lub model wytnij-i-wklej) narusza to kryterium.
• Widżety rysowania lub podpisu, które zakładają, że narysowana ścieżka sama w sobie nie jest wynikiem: Deweloperzy czasami błędnie powołują się na wyjątek „niezbędności” dla widżetów, które w rzeczywistości są tylko kontrolkami interfejsu użytkownika (np. wzorzec odblokowania gestem w celu odsłonięcia treści), a nie prawdziwymi narzędziami do odręcznego wprowadzania danych.
• Umieszczanie alternatywnych kontrolek opartych na pojedynczym wskaźniku poza widocznym obszarem widoku lub w stanie domyślnie zwiniętym: Jeśli równoważne przyciski istnieją w DOM, ale są wizualnie ukryte lub wymagają dodatkowej interakcji, aby je odsłonić, nie spełniają w pełni wymogu postrzegalnej i operowalnej alternatywy opartej na pojedynczym wskaźniku.
• Implementowanie bibliotek gestów, które przechwytują zdarzenia wskaźnika i zapobiegają domyślnemu zachowaniu: Biblioteki wywołujące event.preventDefault() na zdarzeniach dotykowych mogą nieumyślnie blokować własne interakcje i przewijanie przeglądarki oparte na pojedynczym wskaźniku, tworząc niezamierzone błędy wykraczające poza samo kryterium gestów.
• Zakładanie, że dodanie aria-label do strefy obsługiwanej wyłącznie gestem jest wystarczające: Oznaczenie obszaru przesunięcia nie zapewnia alternatywy opartej na pojedynczym wskaźniku — jedynie opisuje go użytkownikom czytników ekranu, którzy nadal nie mogą go obsłużyć bez wsparcia gestów.
• Brak testów na prawdziwych urządzeniach lub z symulacją dotyku: Deweloperzy testujący wyłącznie na komputerach stacjonarnych z myszą mogą nigdy nie odkryć, że funkcja jest obsługiwana wyłącznie gestami na urządzeniach mobilnych, ponieważ awaryjny mechanizm kliknięcia myszą działa na komputerze, ale ścieżka kodu tylko dla dotyku nie ma odpowiednika kliknięcia.

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

Prezydencki Okólnik Turcji 2025/10, opublikowany w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia obowiązkowe wymogi dostępności stron internetowych i aplikacji mobilnych dla szerokiego zakresu podmiotów publicznych i prywatnych działających w Turcji. Okólnik przyjmuje WCAG 2.2 jako normatywny standard techniczny, czyniąc wszystkie kryteria sukcesu na poziomie A — w tym WCAG 2.5.1 Pointer Gestures — prawnie obowiązującymi wymogami bazowymi.

Harmonogram zgodności określony w okólniku jest stopniowany: instytucje i organy publiczne są zobowiązane do osiągnięcia zgodności w ciągu jednego roku od wejścia okólnika w życie, podczas gdy podmioty sektora prywatnego objęte regulacją mają dwuletnie okno na osiągnięcie pełnej zgodności. Niezastosowanie się naraża objęte podmioty na kontrolę regulacyjną i działania egzekucyjne ze strony właściwych organów nadzorczych.

Podmioty objęte okólnikiem obejmują szeroki przekrój tureckich dostawców usług cyfrowych. Obejmują one instytucje publiczne na wszystkich szczeblach administracji i ich jednostki powiązane. W sektorze prywatnym okólnik ma zastosowanie do platform i rynków e-commerce, banków i instytucji finansowych, prywatnych szpitali i świadczeniodawców opieki zdrowotnej, firm telekomunikacyjnych z 200,000 lub większą liczbą abonentów, biur podróży, prywatnych firm przewozu pasażerskiego oraz szkół prywatnych działających na podstawie upoważnienia Ministerstwa Edukacji Narodowej (MoNE).

Dla tych organizacji WCAG 2.5.1 ma bezpośrednie i praktyczne konsekwencje. Tureckie strony e-commerce często używają galerii obrazów produktów sterowanych gestami, nawigacji po kategoriach opartej na przesunięciach oraz przeglądarek produktów z funkcją szczypnięcia do powiększania — wszystkie one muszą teraz mieć alternatywy oparte na pojedynczym wskaźniku. Aplikacje bankowe i finansowe, które używają wzorców uwierzytelniania opartych na gestach lub interfejsów transakcyjnych opartych na przeciąganiu, muszą zostać poddane audytowi i naprawione. Portale zdrowotne z wyszukiwarkami klinik opartymi na mapach z funkcją szczypnięcia do powiększania muszą zapewnić przyciski powiększania. Portale samoobsługowe firm telekomunikacyjnych z selektorami planów sterowanymi przesunięciami muszą dodać kontrolki oparte na stuknięciu.

Organizacjom działającym w Turcji zdecydowanie zaleca się natychmiastowe uwzględnienie WCAG 2.5.1 w listach kontrolnych audytów dostępności, ponieważ wzorce interakcji gestowych objęte tym kryterium są wszechobecne we współczesnym responsywnym projektowaniu stron i rozwoju zorientowanym na urządzenia mobilne — a mimo to często są pomijane, ponieważ wydają się działać poprawnie dla większości użytkowników. Proaktywne uwzględnienie tego kryterium jako części programu zgodności z WCAG 2.2 na poziomie A jest zarówno obowiązkiem prawnym wynikającym z Prezydenckiego Okólnika 2025/10, jak i istotnym krokiem w kierunku cyfrowej inkluzji tureckich użytkowników z niepełnosprawnościami ruchowymi.