WCAG 2.5.1: Gesty wskaźnika

Kryterium sukcesu WCAG 2.1 na poziomie A, 2.5.1 Gesty wskaźnika, dotyczy projektowania interakcji w taki sposób, aby unikać wymagania od użytkowników wykonywania skomplikowanych gestów. Celem jest zapewnienie, że wszystkie funkcje dostępne za pomocą złożonych gestów wskaźnika (takich jak gesty wielopunktowe czy ścieżkowe) mogą być również obsługiwane w prostszy sposób, na przykład za pomocą pojedynczego kliknięcia, dotknięcia lub prostego przesunięcia, chyba że sam gest jest kluczową częścią funkcjonalności.

Czym są Gesty Wskaźnika i dlaczego to kryterium jest ważne?

Gesty wskaźnika to działania wykonywane za pomocą myszy, panelu dotykowego, ekranu dotykowego lub innego urządzenia wskazującego. Kryterium 2.5.1 skupia się na dwóch głównych typach złożonych gestów:

• Gesty wielopunktowe (Multipoint Gestures): Wymagają jednoczesnego użycia dwóch lub więcej punktów styku (np. szczypanie, aby powiększyć na ekranie dotykowym, które wymaga użycia dwóch palców).
• Gesty ścieżkowe (Path-Based Gestures): Wymagają przeciągnięcia wskaźnika wzdłuż określonej ścieżki (np. rysowanie kształtu, przesunięcie elementu do konkretnego miejsca docelowego, odblokowanie ekranu za pomocą wzoru).

Dlaczego unikanie skomplikowanych gestów jest kluczowe dla dostępności?

Wymaganie skomplikowanych gestów może stwarzać znaczące bariery dla wielu grup użytkowników:

• Osoby z niepełnosprawnościami motorycznymi: Trudności z precyzyjnym kontrolowaniem dłoni, drżenie, ograniczony zakres ruchu mogą uniemożliwiać wykonanie gestów wielopunktowych lub ścieżkowych. Mogą one używać alternatywnych metod wprowadzania danych, które nie emulują złożonych gestów.
• Osoby z niepełnosprawnościami poznawczymi: Mogą mieć trudności z zapamiętaniem lub prawidłowym wykonaniem złożonych sekwencji gestów.
• Osoby korzystające z technologii wspomagających: Niektóre technologie wspomagające (np. sterowanie wzrokiem, nakładki dotykowe) mogą nie obsługiwać lub mieć trudności z emulacją skomplikowanych gestów.
• Osoby korzystające z urządzeń w trudnych warunkach: Korzystanie z małych ekranów, w rękawiczkach, w transporcie publicznym lub w innych okolicznościach, gdzie precyzja jest ograniczona, może utrudniać wykonanie złożonych gestów.

Zapewnienie alternatywnych, prostszych metod interakcji jest fundamentalne dla zapewnienia inkluzywności i użyteczności dla wszystkich.

Kryterium sukcesu WCAG 2.5.1: Gesty wskaźnika (Poziom A)

Oficjalne brzmienie kryterium 2.5.1:

Wszystkie funkcje, które wymagają gestów wielopunktowych lub opartych na ścieżce, mogą być również obsługiwane za pomocą pojedynczego wskaźnika bez gestu opartego na ścieżce LUB dostępny jest mechanizm do osiągnięcia funkcjonalności za pomocą pojedynczego dotknięcia, kliknięcia lub prostego przesunięcia, chyba że gest wielopunktowy lub oparty na ścieżce jest niezbędny.

Kluczowe wymagania:

• Alternatywy dla gestów wielopunktowych: Jeśli funkcja wymaga np. gestu szczypania (pinch-to-zoom), musi być dostępna alternatywa, taka jak przyciski powiększania/pomniejszania (+/-).
• Alternatywy dla gestów ścieżkowych: Jeśli funkcja wymaga przeciągania elementu wzdłuż skomplikowanej ścieżki lub rysowania wzoru, musi być dostępna alternatywa, taka jak przycisk, menu kontekstowe lub proste przesunięcie, które nie wymaga precyzyjnego podążania ścieżką.
• „Niezbędny” gest: Gest jest uznawany za niezbędny, jeśli jego usunięcie uniemożliwiłoby osiągnięcie funkcji, lub jeśli funkcjonalność jest naturalnie definiowana przez dany gest (np. pisanie odręczne, podpisywanie dokumentu cyfrowo, granie w gry, gdzie gest jest integralną częścią rozgrywki). W takich przypadkach alternatywa nie jest wymagana.

Praktyczne wytyczne i przykłady zgodności

Aby spełnić kryterium 2.5.1, należy zawsze dążyć do zapewnienia prostych alternatyw dla złożonych gestów.

1. Zapewnij proste alternatywy dla gestów wielopunktowych

Jeśli Twoja aplikacja lub strona internetowa używa gestów, które wymagają więcej niż jednego punktu styku (np. dwa palce), upewnij się, że ta sama funkcjonalność jest dostępna również za pomocą pojedynczego wskaźnika.

Przykład (Powiększanie/Pomniejszanie):

<div class="image-viewer">
  <img src="large-image.jpg" alt="Duży obraz do powiększania" class="zoomable-image">
  <div class="zoom-controls">
    <button aria-label="Powiększ">+</button>
    <button aria-label="Pomniejsz">-</button>
  </div>
</div>

.image-viewer {
  position: relative;
  width: 100%;
  max-width: 600px;
  overflow: hidden;
}
.zoomable-image {
  max-width: 100%;
  height: auto;
  transform-origin: 0 0;
  transition: transform 0.2s ease-out;
}
.zoom-controls {
  position: absolute;
  bottom: 10px;
  right: 10px;
  background: rgba(0,0,0,0.5);
  padding: 5px;
  border-radius: 5px;
}
.zoom-controls button {
  background: #eee;
  border: 1px solid #ccc;
  padding: 5px 10px;
  margin: 0 2px;
  cursor: pointer;
}

// Przykładowa logika JS dla powiększania/pomniejszania
const image = document.querySelector('.zoomable-image');
const zoomInBtn = document.querySelector('.zoom-controls button:first-child');
const zoomOutBtn = document.querySelector('.zoom-controls button:last-child');
let currentScale = 1;

zoomInBtn.addEventListener('click', () => {
  currentScale = Math.min(currentScale + 0.2, 3); // Max 3x zoom
  image.style.transform = `scale(${currentScale})`;
});

zoomOutBtn.addEventListener('click', () => {
  currentScale = Math.max(currentScale - 0.2, 1); // Min 1x zoom
  image.style.transform = `scale(${currentScale})`;
});

// Tutaj dodać obsługę gestów szczypania, jeśli jest wymagana, ale alternatywy są dostępne.
// np. za pomocą biblioteki Hammer.js lub podobnej.

<div class="image-viewer">
  <img src="large-image.jpg" alt="Duży obraz do powiększania" class="zoomable-image">
  <!-- Brak przycisków + / - -->
</div>

// Logika JS obsługuje tylko gesty szczypania dla powiększania.
// Brak obsługi kliknięć dla alternatywnych kontrolek.
// NIESPÓJNE z WCAG 2.5.1

2. Zapewnij proste alternatywy dla gestów ścieżkowych

Jeżeli interakcja wymaga przeciągnięcia elementu po skomplikowanej ścieżce lub specyficznym wzorze, zawsze udostępnij alternatywną metodę, która wymaga tylko pojedynczego kliknięcia, dotknięcia lub prostego przeciągnięcia (bez specyficznej ścieżki).

Przykład (Przenoszenie elementów metodą „przeciągnij i upuść”):

<div class="draggable-item" tabindex="0" role="button" aria-label="Element do przeniesienia">
  Element 1
  <!-- Ukryte menu kontekstowe lub przyciski akcji dla dostępności -->
  <div class="context-menu">
    <button class="move-option" data-target="box2">Przenieś do Box 2</button>
    <button class="move-option" data-target="box3">Przenieś do Box 3</button>
  </div>
</div>
<div class="drop-target" id="box2">Box 2 (miejsce docelowe)</div>
<div class="drop-target" id="box3">Box 3 (miejsce docelowe)</div>

// Logika JS dla drag-and-drop (uproszczona)
const draggableItem = document.querySelector('.draggable-item');
const contextMenu = draggableItem.querySelector('.context-menu');
const moveOptions = contextMenu.querySelectorAll('.move-option');

draggableItem.addEventListener('contextmenu', (e) => {
  e.preventDefault();
  contextMenu.style.display = 'block';
});

moveOptions.forEach(option => {
  option.addEventListener('click', () => {
    const targetId = option.dataset.target;
    const targetBox = document.getElementById(targetId);
    if (targetBox) {
      targetBox.appendChild(draggableItem);
      console.log(`Przeniesiono do: ${targetId}`);
    }
    contextMenu.style.display = 'none';
  });
});

// Dodatkowa logika dla obsługi standardowego drag-and-drop
// np. draggableItem.setAttribute('draggable', 'true');
// draggableItem.addEventListener('dragstart', ...);
// dropTarget.addEventListener('dragover', ...);
// dropTarget.addEventListener('drop', ...);

<div class="draggable-item">Element 1</div>
<div class="drop-target" id="box2">Box 2 (miejsce docelowe)</div>
<!-- Brak mechanizmów alternatywnych -->

// Logika JS obsługuje tylko przeciąganie i upuszczanie.
// Brak obsługi klawiatury ani menu kontekstowego do przenoszenia.
// NIESPÓJNE z WCAG 2.5.1

3. Zrozumienie, kiedy gest jest „niezbędny”

Kryterium dopuszcza wyjątek, jeśli gest jest „niezbędny”. Oznacza to, że sama funkcja jest zdefiniowana przez gest, a jej usunięcie zniekształciłoby jej podstawowy cel.

• Przykłady niezbędnych gestów:
  • Podpis elektroniczny: Wymaga narysowania unikalnego podpisu.
  • Gry wideo: Gdzie gesty są integralną częścią rozgrywki (np. cięcie mieczem w grze).
  • Aplikacje do rysowania/malowania: Gdzie tworzenie sztuki polega na swobodnym ruchu wskaźnika.
• Ważne: Wyjątek „niezbędny” nie oznacza, że twórcy mogą dowolnie decydować o złożoności gestów. Zawsze należy dążyć do upraszczania i oferowania alternatyw, chyba że jest to absolutnie niemożliwe bez zmiany podstawowej natury funkcjonalności.

Najlepsze praktyki i częste pułapki

Najlepsze praktyki:

• Projektuj z myślą o prostocie: Zawsze stawiaj na proste interakcje, takie jak pojedyncze dotknięcia, kliknięcia i proste przesunięcia.
• Domyślnie udostępniaj alternatywy: Nie zakładaj, że użytkownicy będą w stanie wykonywać skomplikowane gesty. Zawsze oferuj alternatywne metody interakcji.
• Testuj z różnymi użytkownikami: Przeprowadzaj testy użyteczności z osobami korzystającymi z różnych technologii wspomagających i mającymi różne zdolności motoryczne.
• Jasne instrukcje: Jeśli musisz użyć gestu, upewnij się, że instrukcje są jasne i łatwe do zrozumienia. Pamiętaj jednak, że instrukcje nie zastępują dostępnych alternatyw.
• Używaj standardowych komponentów: W miarę możliwości korzystaj ze standardowych kontrolek HTML, które domyślnie są dostępne i obsługują interakcje klawiaturą oraz myszą.

Częste pułapki:

• Całkowite poleganie na gestach dotykowych: Tworzenie interfejsów, które obsługują wyłącznie złożone gesty dotykowe, bez alternatyw dla użytkowników klawiatury, myszy lub technologii wspomagających.
• Zakładanie sprawności motorycznej: Błędne przekonanie, że wszyscy użytkownicy są w stanie precyzyjnie wykonywać gesty wielopunktowe lub ścieżkowe.
• Niewystarczające alternatywy: Oferowanie alternatywy, która sama w sobie jest zbyt skomplikowana lub trudna do znalezienia/użycia.
• Ukrywanie alternatyw: Umieszczanie alternatywnych kontrolek w trudno dostępnych miejscach lub wymaganie wielu kroków, aby do nich dotrzeć.
• Niejasne komunikaty o błędach: Jeśli gest się nie powiedzie, brak jasnej informacji o tym, jak go poprawić lub jaka jest alternatywna metoda.

Zgodność z WCAG 2.5.1 to nie tylko spełnienie wymogów technicznych, ale przede wszystkim projektowanie z empatią, pamiętając o różnorodności potrzeb użytkowników. Zapewniając proste i elastyczne metody interakcji, tworzymy bardziej dostępny i użyteczny internet dla wszystkich.