Wróć do wszystkich kryteriów

2.5.2 Anulowanie wskaźnika (ang.) Pointer Cancellation

Specjalizacje:

  • Designer
  • Deweloper

Elementy:

  • Dialogi i warstwy
  • Przyciski i kontrolki

Poziomy:

  • A

Spis treści

    Istota i cel kryterium

    To kryterium sukcesu ma na celu oddanie użytkownikowi pełnej i bezpiecznej kontroli nad aktywacją poszczególnych funkcjonalności za pomocą pojedynczego wskaźnika, bez względu na to, czy posługuje się on standardową myszą komputerową, palcem na ekranie smartfona, czy specjalistycznym rysikiem.

    Główna wytyczna wymaga, aby jakiekolwiek działanie zainicjowane przez urządzenie wskazujące nie było bezpowrotnie finalizowane w momencie samej inicjacji nacisku. Użytkownik musi otrzymać realną szansę na wycofanie się, anulowanie lub odwrócenie swojej decyzji, zanim system wywoła ostateczny, potencjalnie niechciany i szkodliwy skutek.

    Zapobiega to natychmiastowym konsekwencjom przypadkowych kliknięć, drastycznie zmniejsza zmęczenie psychiczne i eliminuje frustrację podczas codziennej nawigacji po stronach i aplikacjach.

    Definicja w j. angielskim

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

    Definicja w j. polskim

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

    Słownik pojęć

    Wskaźnik (ang.) pointer
    –

    dowolne urządzenie wejściowe operujące na współrzędnych ekranu, służące do wskazywania konkretnych elementów interfejsu (np. mysz, touchpad, rysik czy pojedynczy punkt dotyku).

    Zdarzenie w dół (ang.) down-event
    –

    techniczny moment naciśnięcia klawisza myszy lub pierwszego kontaktu fizycznego z powierzchnią ekranu dotykowego (np. natywne właściwości mousedown lub pointerdown).

    Zdarzenie w górę (ang.) up-event
    –

    moment zwolnienia przycisku myszy lub uniesienia palca bądź rysika znad powierzchni ekranu (np. właściwości mouseup, pointerup lub powszechnie stosowane click).

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

    • Osoby z niepełnosprawnościami wzrokowymi (w tym niedowidzące): Użytkownicy z powiększonym ekranem lub korzystający z programów powiększających często mają drastycznie ograniczone pole widzenia. Bardzo łatwo mogą stracić orientację na stronie i kliknąć niewłaściwy element, który akurat przesunął się pod ich wskaźnik.
    • Osoby z niepełnosprawnościami motorycznymi: Użytkownicy zmagający się z silnym drżeniem rąk, ograniczoną precyzją ruchów, a także osoby wykorzystujące alternatywne urządzenia wskazujące (np. myszy sterowane wzrokiem lub ustami) nagminnie generują przypadkowe kliknięcia. Możliwość bezskutecznego przesunięcia wskaźnika poza obszar elementu przed jego zwolnieniem to dla nich jedyna gwarancja bezpiecznej kontroli nad systemem.
    • Osoby z niepełnosprawnościami poznawczymi: Uczestnicy interakcji, którzy wykazują zachowania impulsywne lub mają trudności z przestrzenną koordynacją i celowaniem, zyskują niezbędny czas na natychmiastową korektę pomyłek. Redukuje to obciążenie poznawcze i niweluje stres wywołany obawą przed popełnieniem błędu.
    • Wszyscy użytkownicy interfejsów: Każdy człowiek doświadcza chwil nieuwagi, zmęczenia lub fizycznych zakłóceń podczas korzystania z urządzeń mobilnych w ruchu. Możliwość uniknięcia natychmiastowych, nieodwracalnych działań drastycznie podnosi ogólne poczucie stabilności interfejsu, chroniąc przed utratą danych, nieautoryzowanymi transakcjami finansowymi czy przypadkowym uruchomieniem destrukcyjnych funkcji.

    Zasady wdrażania i wymagania techniczne

    Aby skutecznie spełnić wymagania techniczne tego kryterium, każda funkcjonalność obsługiwana pojedynczym wskaźnikiem musi bezwzględnie realizować przynajmniej jeden z poniższych warunków:

    • Zasada braku zdarzenia w dół ((ang.) No Down-Event): Unikaj uruchamiania jakichkolwiek kluczowych akcji bezpośrednio na zdarzenie w dół. Prawidłowo zaprojektowany proces musi oczekiwać na zdarzenie w górę. Dzięki temu użytkownik, który zorientuje się o błędzie w trakcie dociskania przycisku lub ekranu, może swobodnie przesunąć kursor poza obszar aktywnego elementu i dopiero tam go zwolnić, co pozwala na bezinwazyjne anulowanie całej operacji.
    • Mechanizm przerwania lub cofnięcia ((ang.) Abort or Undo): Jeżeli funkcja opiera się na zdarzeniu w górę, Zadbaj o to, aby interfejs udostępniał jawny i intuicyjny mechanizm przerwania operacji przed jej sfinalizowaniem lub błyskawicznego odwrócenia jej skutków tuż po zakończeniu. Przykładowo, podczas operacji typu przeciągnij i upuść ((ang.) Drag and Drop), zwolnienie elementu poza strefą docelową lub naciśnięcie klawisza ESC musi natychmiastowo przywrócić stan wyjściowy. W przypadku akcji o poważnych skutkach wdróż widoczny przycisk „Cofnij”.
    • Odporność na przypadkowe aktywacje ((ang.) Tolerant): Upewnij się, że przypadkowe uruchomienie danej funkcji nie niesie za sobą negatywnych i nieodwracalnych konsekwencji. Doskonałym przykładem jest pole wyboru lista rozwijana <select> – nawet jeśli zostanie aktywowane pomyłkowo, użytkownik może je bez trudu zmienić, bez żadnego uszczerbku na realizowanym procesie.

    Wyjątki i sytuacje szczególne

    Standard WCAG przewiduje rygorystyczne zwolnienia z tej reguły, określając je jako warunki technicznie konieczne ((ang.) essential). Wyjątek od kryterium można uznać wyłącznie wtedy, gdy uruchomienie akcji na zdarzenie w górę bezpowrotnie zniszczyłoby fundamentalną istotę i cel funkcjonalności:

    • Gry wymagające refleksu: Wszelkie interaktywne aplikacje rozrywkowe, gdzie kluczowym elementem mechaniki jest natychmiastowa reakcja czasowa na naciśnięcie przycisku, są zwolnione z wymogu anulowania wskaźnika.
    • Symulatory klawiatury ekranowej: Wprowadzanie znaków na ekranowych klawiaturach pomocniczych powinno odbywać się w momencie naciśnięcia w celu precyzyjnej emulacji działania fizycznych klawiszy.
    • Wirtualne instrumenty muzyczne: Kliknięcie klawisza pianina na ekranie dotykowym musi wygenerować dźwięk natychmiast po dotknięciu (zdarzenie w dół), aby zachować naturalną responsywność instrumentu. Opóźnienie dźwięku do momentu podniesienia palca uniemożliwiłoby grę.

    Przykłady implementacji

    Najczęstsze błędy

    • F101: Uruchamianie głównego wyzwalacza akcji przycisku, linku lub innego komponentu interaktywnego bezpośrednio na zdarzenie w dół (mousedown lub pointerdown), co całkowicie uniemożliwia użytkownikowi rezygnację z akcji poprzez odsunięcie wskaźnika.
    • Uporczywe i bezpodstawne programowanie akcji destrukcyjnych na zdarzenie w dół: Wywoływanie operacji usunięcia, zatwierdzenia lub przejścia do nowej podstrony bez jakiejkolwiek możliwości cofnięcia decyzji przed zwolnieniem palca lub klawisza.
    • Zaniechanie testów na rzeczywistych urządzeniach dotykowych: Ignorowanie specyfiki ekranów mobilnych, gdzie brak precyzji wskaźnika objawia się najsilniej, i bezrefleksyjne przenoszenie skryptów obsługujących wyłącznie tradycyjne myszy komputerowe.
    • Całkowity brak implementacji funkcji „Cofnij” ((ang.) Undo): Pozostawienie użytkownika bez ratunku po uruchomieniu procesów o krytycznych lub destrukcyjnych konsekwencjach, które zostały zaprogramowane na zdarzenie w dół.
    • Nadużywanie i błędna interpretacja wyjątku „konieczności technicznej” ((ang.) Essential): Traktowanie standardowych komponentów formularzy lub tradycyjnego menu nawigacyjnego jako elementów rzekomo wymagających „błyskawicznej reakcji” i celowe pozbawianie ich mechanizmów bezpieczeństwa.
    • Brak jasnych wskazówek dotyczących anulowania: Sytuacja, w której interfejs wymusza na użytkowniku wykonanie akcji, ukrywając przed nim fakt, że przesunięcie wskaźnika poza element mogłoby zapobiec wywołaniu funkcji.

    Najlepsze praktyki

    • Preferuj natywne zdarzenia click, mouseup lub pointerup jako domyślne wyzwalacze akcji w kodzie JavaScript.
    • Unikaj bezwzględnie wiązania destrukcyjnych funkcji interfejsu ze zdarzeniami mousedown lub pointerdown.
    • Zadbaj o precyzyjne i jasne wskazówki wizualne podczas przeciągania elementów, aby użytkownik w ułamku sekundy wiedział, gdzie może bezpiecznie „porzucić” obiekt w celu przerwania operacji.
    • Zadbaj o to, aby interfejs momentalnie reagował na fizyczne naciśnięcie elementu (np. poprzez subtelną zmianę koloru, głębi czy efekt wciśnięcia przycisku CSS), dając użytkownikowi jasny sygnał: „Interakcja trwa, ale możesz ją jeszcze anulować, odsuwając wskaźnik”.
    • Pamiętaj, że mechanizmy anulowania muszą działać tożsamo na każdym poziomie interakcji – zapewnij, by operację przeciągania można było w każdej chwili przerwać powszechnym naciśnięciem klawisza ESC.
    • Twórz interfejsy intuicyjne na pierwszy rzut oka, w których kierunek ruchu wskaźnika potrzebny do przerwania akcji jest w pełni przewidywalny.
    • Dla każdej operacji edycyjnej, sortowania czy usuwania twórz bezwarunkowo widoczne i łatwo dostępne punkty powrotu do stanu poprzedniego.
    • Testuj interfejsy na tabletach, telefonach oraz z użyciem niestandardowych urządzeń wskazujących, eliminując nieoczekiwane zachowania skryptów dotykowych.

    Metody testowania

    • Narzędzie deweloperskie (ang.) Developer Tools: Otwórz zakładkę inspekcji kodu w przeglądarce i przeanalizuj sekcję (ang.) Event Listeners dla kluczowych elementów interaktywnych. Sprawdź, czy skrypty nie są powiązane ze zdarzeniami mousedown lub pointerdown. Upewnij się, że dominują zdarzenia click, mouseup lub pointerup.
    • Testowanie manualne: Wykonaj manualny test użytkownika za pomocą myszy oraz ekranu dotyczącego. Najedź na przycisk, naciśnij i przytrzymaj lewy klawisz myszy (lub dociśnij palec do ekranu), a następnie – bez zwalniania nacisku – przesuń kursor całkowicie poza obszar tego przycisku i dopiero wtedy puść. Jeśli akcja mimo to się wykonała, system zawiera krytyczny błąd dostępności.

    Sprawdź swoją wiedzę

    W linku poniżej znajduje się 5 modułów testowych. Twoim zadaniem jest sprawdzenie, czy w przypadku pomyłki system daje Ci możliwość wycofania się z wywołanej akcji przed jej finalizacją (czyli tzw. anulowanie przed zwolnieniem przycisku).

    Jak to sprawdzić?

    1. Najedź myszą (lub palcem) na oceniany przycisk/element.
    2. Naciśnij i przytrzymaj lewy klawisz myszy (zdarzenie down-event).
    3. Nie puszczając klawisza, wyjedź kursorem całkowicie poza obszar elementu (w puste tło obok).
    4. Dopiero tam puść klawisz myszy (up-event).
    5. Zadaj sobie pytanie: „Czy akcja i tak się wykonała?”. Jeśli tak – to prawdopodobnie natrafiłeś na potężny błąd dostępności.

    Notatka: Zanim zajrzysz do rozwiązania, przetestuj i zapisz swoje wnioski na kartce.
    Proponowane narzędzia: Mysz / Dotyk (Zasada: Wciśnij -> Przesuń -> Puść)

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

    #1 DOBRZE

    Dlaczego: To idealny i najbezpieczniejszy standard w sieci. Przycisk nasłuchuje na zdarzenie click. Dzięki temu, gdy naciśniesz go przypadkowo, możesz cały czas trzymając wciśnięty klawisz myszy „odjechać” na szare pole obok, i dopiero tam zwolnić nacisk. Zdarzenie kliknięcia zostanie przerwane, a akcja „Zapisz” zignorowana!

    #2 DOBRZE

    Dlaczego: Zwykła, natywna lista rozwijana <select> uruchamia wybór na zwolnienie wskaźnika („Up-Event”), ale nawet gdyby reagowała natychmiastowo, to nie jest błąd 2.5.2! Spełnia bowiem fundamentalny warunek WCAG oznaczający odwracalność decyzji – błędny wybór nie wywołuje żadnych destrukcyjnych zmian w systemie. Możesz w sekundę kliknąć jeszcze raz i poprawić swój błąd (odporność na pomyłki wskaźnika).

    #3 BŁĄD

    Problem: Programista podpiął krytyczną funkcję („Usuń konto”) pod zdarzenie mousedown (lub pointerdown).
    Dlaczego: Użytkownik z niedowładem, który przypadkowo opuścił palec na ten przycisk, nie ma żadnej szansy na ratunek. Akcja wykonuje się w milisekundzie naciśnięcia ekranu, bez możliwości wycofania i bez potwierdzenia (Błąd opisany techniką F101).
    Naprawa: Zawsze podpinaj główne akcje pod zdarzenie click, mouseup lub pointerup.

    #4 BŁĄD

    Problem: Zaprogramowano operację typu „Drag and Drop”, gdzie każde zwolnienie elementu (up-event) zatwierdza transakcję bez względu na okoliczności.
    Dlaczego: WCAG dopuszcza wyzwalanie akcji przy „up-event”, ale tylko pod warunkiem, że istnieje **mechanizm jej przerwania**. Tutaj, jeśli złapałeś klocek omyłkowo, nie masz jak go upuścić bez wywołania transakcji. Przeglądarka zmusza Cię do błędu.
    Naprawa: Skrypt powinien wywoływać transakcję TYLKO, gdy klocek zostanie zrzucony do specjalnej, oznaczonej „strefy zrzutu” na końcu. Puszczenie go gdziekolwiek indziej powinno powodować cofnięcie (Undo) na start.

    #5 DOBRZE

    Dlaczego: Wirtualne pianino wymaga natychmiastowej reakcji na dotyk. Odwrócenie tego i puszczanie dźwięku dopiero w momencie „up-event” (przy odrywaniu palca) zniszczyłoby poczucie rytmu i cały fundamentalny cel aplikacji muzycznej. To w pełni legalny wyjątek opisany w normie WCAG (tak jak zaawansowane gry akcji czy ekrany emulatora klawiatury).

    Źródła

    Dodatkowe linki

    Wróć do wszystkich kryteriów