Wróć do wszystkich kryteriów

2.5.4 Aktywacja ruchem (ang.) Motion Actuation

Specjalizacje:

  • Designer
  • Deweloper

Elementy:

  • Cała strona / widok
  • Przyciski i kontrolki

Poziomy:

  • A

Spis treści

    To kryterium ma na celu zapewnić, że każda funkcjonalność wyzwalana za pomocą fizycznego ruchu urządzenia (takiego jak potrząsanie, obracanie czy przechylanie) lub celowego ruchu samego użytkownika śledzonego przez czujniki (np. gesty dłonią czy głową rejestrowane przez kamerę) posiada swój pełnoprawny odpowiednik w tradycyjnym interfejsie graficznym.

    Należy dostarczyć alternatywne, standardowe mechanizmy sterowania, które pozwolą wykonać tę samą akcję bez polegania na sprawności fizycznej. Ponadto wytyczna kategorycznie nakazuje zapewnienie opcji całkowitego zablokowania reakcji na ruch, chroniąc użytkownika przed przypadkowym i niekontrolowanym uruchamianiem opcji systemowych.

    Definicja w j. angielskim

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

    Definicja w j. polskim

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

    Słownik pojęć

    Sterowanie ruchem (ang.) motion actuation
    –

    mechanizm aktywacji funkcji cyfrowych poprzez fizyczne przemieszczanie sprzętu w przestrzeni lub wykonywanie gestów interpretowanych przez sensory optyczne lub układy bezwładnościowe.

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

    • Osoby z ograniczeniami motorycznymi i ruchowymi: Użytkownicy zmagający się z drżeniem mięśniowym, ataksją, paraliżem czy niedowładem kończyn nie są w stanie precyzyjnie poruszać urządzeniem. Fizyczne potrząsanie smartfonem może być dla nich niewykonalne lub doprowadzić do wywołania niespodziewanych akcji. Zapewnienie tradycyjnych przycisków przywraca im pełną kontrolę nad aplikacją.
    • Osoby z silnymi, mimowolnymi ruchami ciała: Użytkownicy zmagający się ze spastycznością, tikami, pląsawicą czy zaawansowaną chorobą Parkinsona generują nagłe, niekontrolowane szarpnięcia. Jeśli aplikacja reaguje na ruch bez możliwości blokady, każdy taki odruch wywoła chaos w programie.
    • Użytkownicy sterujący urządzeniem za pomocą głosu ((ang.) Voice Control): Osoby korzystające z oprogramowania dyktującego nie mają możliwości potrząśnięcia telefonem. Takie programy potrzebują konkretnego, nazwanego komponentu interfejsu (np. przycisku z etykietą), aby użytkownik mógł wypowiedzieć komendę. Bez tradycyjnej kontrolki funkcja ruchowa staje się dla nich całkowicie nieuchwytna.
    • Użytkownicy korzystający z alternatywnych urządzeń wejściowych: Osoby z porażeniami czterokończynowymi (np. w przebiegu stwardnienia bocznego zanikowego – SLA) obsługują system za pomocą przełączników ((ang.) Switch Access) lub systemów śledzenia wzroku ((ang.) Eye Tracking). W ich przypadku smartfon lub tablet jest na stałe unieruchomiony na stojaku, co całkowicie wyklucza manipulację przestrzenną.
    • Osoby korzystające z wózków inwalidzkich: Telefony lub tablety zamontowane na sztywnych uchwytach przy wózkach są unieruchomione. Ich przechylenie bez demontażu jest niemożliwe, przez co aplikacje wymagające zmiany orientacji przestrzennej stają się barierą.
    • Osoby z trudnościami poznawczymi: Skomplikowane i abstrakcyjne sekwencje ruchowe bywają trudne do zapamiętania. Jasne, widoczne na ekranie ikony oraz przyciski drastycznie zmniejszają zmęczenie psychiczne i eliminują frustrację.
    • Użytkownicy w niesprzyjających warunkach środowiskowych oraz z czasowymi kontuzjami: Dynamiczne otoczenie, takie jak jazda trzęsącym się autobusem, niesienie zakupów, obsługa ekranu jedną ręką czy złamana ręka w gipsie, utrudnia wykonywanie precyzyjnych gestów przestrzennych.

    Zasady wdrażania i wymagania techniczne

    • Wdrażaj tradycyjne alternatywy: Dla każdego mechanizmu wyzwalanego ruchem zaimplementuj widoczny element sterujący w interfejsie. Jeśli potrząśnięcie cofa napisaną treść, obok pola tekstowego umieść standardowy przycisk wykonujący operację cofnięcia.
    • Zapewnij identyczny rezultat: Alternatywna ścieżka obsługi musi przynosić dokładnie taki sam skutek techniczny i funkcjonalny jak aktywacja ruchowa.
    • Umożliwiaj dezaktywację czujników: Dodaj w konfiguracji programu opcję wyłączenia obsługi gestów przestrzennych. Upewnij się, że Twoje oprogramowanie w pełni respektuje globalne ustawienia blokady ruchu.
    • Dbaj o niezależność funkcji: Wyłączenie sensorów nie może pogarszać stabilności ani wpływać negatywnie na dostępność klasycznych kontrolek.

    Wyjątki i sytuacje szczególne

    • Interfejsy wspierające dostępność: Reguła nie obowiązuje, gdy analiza ruchu jest realizowana bezpośrednio przez technologie wspomagające użytkownika ((ang.) Supported Interface).
    • Istotność funkcjonalna ((ang.) essential): Ruch uznaje się za dozwolony bez alternatyw, gdy jego usunięcie całkowicie zniszczyłoby sens i unieważniło wynik działania. Przykłady obejmują:
      • Krokomierze oraz aplikacje treningowe rejestrujące fizyczne przemieszczanie się w przestrzeni za pomocą modułu GPS.
      • Gry zręcznościowe bazujące na fizyce, np. symulatory lotu, gdzie sterowanie balansem ciała stanowi główną mechanikę rozgrywki.

    Przykłady implementacji

    Najczęstsze błędy

    • F106: Całkowity błąd wynikający z braku możliwości wyłączenia aktywacji ruchem przez użytkownika w ustawieniach aplikacji.
    • Blokowanie, nadpisywanie lub zakłócanie natywnych funkcji systemu operacyjnego, które pozwalają na globalną rezygnację z aktywacji ruchowej na poziomie urządzenia.
    • Uzależnienie wykonania kluczowej operacji wyłącznie od wykonania gestu przestrzennego, bez dodania klikalnego przycisku w strukturze DOM.

    Najlepsze praktyki

    • Prezentuj czytelne instrukcje: Wyraźnie poinformuj użytkownika o obecności funkcji ruchowych oraz wskaż, gdzie znajdują się ich tradycyjne, ekranowe zamienniki.
    • Personalizuj czułość sensorów: Wprowadź suwaki regulacji progu aktywacji, co pozwoli uchronić osoby z lekkimi drżeniami przed przypadkowym wyzwalaniem akcji.
    • Projektuj z myślą o widoczności: Rozmieszczaj alternatywne przyciski w łatwo dostrzegalnych, intuicyjnych obszarach ekranu, eliminując chaos nawigacyjny.
    • Przeprowadzaj testy użyteczności: Weryfikuj działanie aplikacji z udziałem osób o zróżnicowanej sprawności fizycznej oraz w realnych warunkach mobilnych.

    Metody testowania

    • Narzędzie deweloperskie (ang.) Developer Tools: Zweryfikuj w strukturze drzewa DOM, czy wszystkie interaktywne kontrolki posiadają poprawnie przypisane zdarzenia i opisy.
    • NVDA: Uruchom czytnik ekranu i przetestuj nawigację klawiaturową, aby upewnić się, że jesteś w stanie dotrzeć do alternatywnego przycisku bez poruszania urządzeniem.
    • (ang.) WAVE Evaluation Tool: Wykorzystaj narzędzie do zbadania struktury strony pod kątem obecności poprawnie powiązanych etykiet dla elementów interfejsu.

    Sprawdź swoją wiedzę

    W linku poniżej znajduje się 4 moduły symulujące zachowanie aplikacji mobilnych korzystających z akcelerometru lub żyroskopu. W środowisku testowym fizyczny ruch urządzenia symulujemy specjalnymi, fioletowymi przyciskami „Symuluj wstrząs / przechylenie”.

    Jak to sprawdzić?

    1. Sprawdź, czy do wywołania pożądanej akcji masz alternatywę w interfejsie (np. widoczny przycisk na ekranie zamiast konieczności potrząśnięcia).
    2. Zbadaj, czy możesz całkowicie wyłączyć czujniki ruchu w obrębie danego modułu (aby przypadkowe drżenie ręki nie psuło Ci pracy).
    3. Zastanów się, czy ruch w danym module nie jest czasem zdefiniowany jako wyjatek „Essential” (niezbędny do działania).

    Notatka: Zanim zajrzysz do rozwiązania, przetestuj i zapisz swoje wnioski na kartce.

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

    #1 DOBRZE

    Dlaczego: To modelowe wdrożenie. Funkcjonalność wyzwalana ruchem ma swoją konwencjonalną alternatywę w postaci widocznego na ekranie przycisku „Cofnij wpisywanie”. Dodatkowo użytkownik, który generuje mimowolne ruchy, może wyłączyć sensory za pomocą opcji „Reaguj na potrząśnięcie”, eliminując ryzyko zepsucia sobie pracy.

    #2 BŁĄD

    Problem: Aplikacja wymusza wykonanie potrząśnięcia do wylosowania nagrody. Nie ma żadnej opcji wyłączenia tego czujnika, a na ekranie brakuje alternatywnego przycisku (np. „Losuj”).
    Dlaczego: Użytkownik z niedowładem dłoni lub obsługujący sprzęt na sztywnym ramieniu wózka nigdy nie zagra w tę loterię. Jest to jawne złamanie dostępności.
    Naprawa: Należy dodać tradycyjny, klikalny przycisk „Wylosuj” tuż pod komunikatem oraz umożliwić deaktywację obsługi ruchu.

    #3 BŁĄD

    Problem: Teoretycznie aplikacja posiada alternatywę interfejsową (przyciski strzałek do zmiany zdjęć). Niestety, w module nigdzie nie ma ustawienia wyłączającego funkcję sterowania przechylaniem i nie respektuje on globalnych ustawień systemu operacyjnego.
    Dlaczego: Błąd opisany techniką F106. Jeśli osoba z drżeniem spastycznym używa aplikacji, każdy jej mimowolny odruch zmieni obraz na następny. Alternatywa GUI to nie wszystko – możliwość „wyciszenia” sensorów ruchu to twardy wymóg kryterium.
    Naprawa: Dodaj globalne lub lokalne ustawienie „Wyłącz akcelerometr” dla tej galerii, lub zadbaj o to, aby aplikacja poprawnie odczytywała i respektowała ustawienia systemu operacyjnego blokujące wyzwalanie ruchem.

    #4 DOBRZE

    Dlaczego: Jest to licznik kroków. Ruch fizyczny jest w tym przypadku podstawą (essential) działania i funkcjonalności aplikacji. Dodawanie na ekran przycisku „Wykonaj krok” albo wyłączanie czujników GPS/Akcelerometru zniszczyłoby fundamentalny cel oprogramowania. Zatem tutaj WCAG zezwala na sterowanie wyłącznie ruchem.

    Źródła

    Dodatkowe linki

    Wróć do wszystkich kryteriów