Uruchamianie ruchem

Co oznacza to kryterium

Potrząśnięcie telefonem może być skrótem do pokazania adresu. Ta sama funkcja musi być dostępna przez kontrolkę, a reakcję na ruch trzeba móc wyłączyć. Obie części chronią osoby, które nie mogą poruszyć urządzeniem lub poruszają nim mimowolnie. Dwa ścisłe wyjątki dotyczą interfejsu wspierającego dostępność i ruchu niezbędnego do samej funkcji.

Korzystanie w stabilnym uchwycie także bez niepełnosprawności jest dodatkową korzyścią. Nie przypisujemy automatycznie kategorii słuchu, barw ani poznawczej; nie wykonano testu konkretnej technologii asystującej.

Przykłady błędów i poprawek

Ten sam punkt, zamówienie, adres i wspólna akcja _show; początkowo wynik jest ukryty. Good/bad różnią się obecnością przycisku, good/no-disable obecnością wyłącznika. Dane i obsługa sygnału są wspólne. Warianty nie zawierają etykiet oceny we wejściu badanej aplikacji.

Bariera → poprawka: z bad dodaj standardowy przycisk tej samej funkcji, z no-disable dodaj osiągalny wyłącznik i warunek w odbiorniku. Wyłączenie nie może usuwać działania przycisku ani tylko ukrywać animacji po już wykonanej akcji. Dodatkowy przycisk „Wyślij sygnał testowy” należy do narzędzi debug Simulatora i emituje zastępczy sygnał do handlera. Przy włączonej reakcji także pokazuje adres, zatem w tej instrumentowanej wersji może stanowić drogę UI do tego samego wyniku. Nie twierdzimy, że jego techniczne przejście przez kanał odbiera mu tę właściwość. bad demonstruje brak zwykłej kontrolki użytkowej w modelu, lecz uruchomiona wersja debug nie dowodzi normatywnego FAIL braku wszelkiej alternatywy. Ocena tej części bez narzędzia testowego wymaga fizycznego wejścia lub zewnętrznej injekcji; na fizycznym urządzeniu narzędzie nie jest dostępne.

Wybrano istniejący Flutter/Cupertino oraz sekwencję stanów z dziennikiem: widoczny ekran wyjaśnia kontrolki, ale potwierdzenie blokady wymaga dowodu, że sygnał dotarł po wyłączeniu i nie zmienił stanu. Native simulate emituje wiadomość shake z source=native-simulator-fixture, numerem sekwencji i czasem monotonicznym. Dart zapisuje odbiór, accepted i licznik przed/po. Ta symulacja pomija wykrywanie ruchu i callback UIKit motionEnded; testuje kanał i bramkę od zdarzenia semantycznego dalej. Zmiana orientacji ani tap narzędzia testowego nie jest fizycznym shake.

Kiedy obowiązuje i gdzie są wyjątki

Wymaganie normatywne ma dwie części łącznie: równoważną obsługę komponentami UI oraz możliwość wyłączenia reakcji zapobiegającą przypadkowemu uruchomieniu. Przycisk „Pokaż adres” przy stale aktywnym shake nie spełnia drugiej części. Sam wyłącznik bez alternatywy pozostawia osobę niemogącą potrząsnąć urządzeniem bez funkcji. Komponent to odrębna kontrolka postrzegana przez użytkownika, nie dowolny callback lub klasowy widget. Równoważność dotyczy działania i wyniku, nie identycznego ruchu ani wyglądu.

Wyjątek interfejsu wspierającego dostępność: np. ruch głowy przekształcony przez odpowiednią technologię asystującą w standardowe wejście. Nie należy wyłączać jedynej drogi wejścia tej osoby. Sama obecność czujnika, UIKit lub opis „accessible” nie dowodzi wyjątku; trzeba potwierdzić współpracę użytej konfiguracji z technologią asystującą. Żaden wariant demonstracji nie powołuje się na ten wyjątek.

Wyjątek niezbędności: usunięcie ruchu musi fundamentalnie zmienić funkcję/informację, bez równoważnego zgodnego sposobu jej zachowania; zastąpienie go unieważniałoby czynność. Pomiar rzeczywistych kroków krokomierzem może spełniać ten warunek. Wpisywanie wymyślonej liczby kroków nie jest równoważnym pomiarem. Wyjątek dotyczy pomiaru, nie całej aplikacji: start, historia czy ustawienia nadal wymagają właściwej obsługi. Pokazanie adresu, cofnięcie tekstu lub przejście do następnej karty nie staje się niezbędne ruchowo przez decyzję projektanta. Ocena wyjątków jest tu interpretacją edukacyjną; praktycznego testu krokomierza/AT nie wykonano.

Understanding rozróżnia wejście celowym ruchem od samego przemieszczania się w przestrzeni odczytywanego przez geolokalizację, skierowania kamery na QR/dokument oraz obserwowania otoczenia. Dotykowe swipe, drag i pinch należą do wejścia wskaźnikiem, a nie automatycznie do 2.5.4. Zwykłe obracanie układu wraz z ekranem nie jest samo w sobie funkcją uruchamianą ruchem. Gdy autor interpretuje przechylenie jako komendę przejścia karty, warunek może już wystąpić. Nie utożsamiamy ustawienia Reduce Motion, które dotyczy prezentowanej animacji, z wyłączaniem własnego wejścia czujnikowego.

Techniki pomocnicze: G213 pokazuje konwencjonalną kontrolkę i ustawienie aplikacji; F106 opisuje błąd braku deaktywacji. Nie są dodatkowymi normatywnymi warunkami ani rankingiem częstości usterek. Systemowe wyłączenie może wystarczyć, jeśli rzeczywiście blokuje badaną reakcję i aplikacja go respektuje. Nie zakładamy, że iOS Shake to Undo obejmuje dowolny własny shake, a brak zgody na czujnik/czujnika podczas testu nie potwierdza istnienia właściwego wyłącznika. Własna kontrolka demonstracji wyłącza skutki we wspólnym handlerze, bez deklaracji zatrzymania czujnika.

Zalecenie implementacyjne: zachowywać wybór po nawigacji/restarcie, unikać samoczynnego ponownego włączenia i testować zdarzenia już oczekujące w kolejce. To nie wymyślony czas obowiązkowego wyłączenia. Demonstracja ma wybór na czas widoku, a świadomy reset/cykl przywraca dane demonstracji; trwałości preferencji po restarcie nie implementowano ani nie zweryfikowano.

Platformy

Warunek wspólny: ruch jest interpretowany jako wejście uruchamiające funkcję. WCAG2ICT dla WCAG 2.2, Group Note 2025-12-11, stosuje 2.5.4 bez zmiany brzmienia do oprogramowania i dokumentów poza webem. To interpretacja, nie osobna norma ani ustalenie obowiązku prawnego. Brak czujnika w tej próbie nie wyłącza platformy.

Nie ustalano podstawy prawnej ani mapowania EN 301 549. Wariant control nie uruchamia warunku w funkcji pokazywania adresu, bo tylko przycisk zmienia jej stan; nie jest wyjątkiem niezbędności ani wyłączeniem platformy.

Rozwiązania w technologiach

Najprostsza opcja produkcyjna: zostawić wyłącznie przycisk, jeśli wejście ruchowe nie jest potrzebne. Jeśli pozostaje, obie drogi muszą korzystać z tej samej funkcji, z kontrolą w odbiorniku ruchu, także dla spóźnionych zdarzeń. Nie dodawaj własnego detektora shake do samej prezentacji poprawki; w produktach dobierz go do realnego wejścia i sprzętu.

import 'package:flutter/cupertino.dart';
import 'package:flutter/services.dart';

final motion = MethodChannel('eu.clearship.research/motion');
// initState:
motion.setMethodCallHandler((call) async {
  if (call.method == 'shake' && motionEnabled) {
    setState(showAddress);
  }
});
// build:
CupertinoButton(onPressed: () => setState(showAddress), child: Text('Pokaż adres'));
CupertinoSwitch(
  value: motionEnabled,
  onChanged: (value) => setState(() => motionEnabled = value),
);
// dispose:
motion.setMethodCallHandler(null);

import androidx.compose.material3.Button
import androidx.compose.material3.Switch
import androidx.compose.material3.Text
import androidx.compose.foundation.layout.Column
import androidx.compose.runtime.*
import kotlinx.coroutines.flow.Flow
import kotlinx.coroutines.flow.collect
import androidx.compose.ui.semantics.semantics
import androidx.compose.ui.semantics.contentDescription

@Composable
fun Address(shakes: Flow<Unit>, showAddress: () -> Unit) {
    var enabled by remember { mutableStateOf(true) }
    val enabledNow by rememberUpdatedState(enabled)
    val showNow by rememberUpdatedState(showAddress)
    LaunchedEffect(shakes) {
        shakes.collect { if (enabledNow) showNow() }
    }
    Column {
        Button(onClick = showAddress) { Text("Pokaż adres") }
        Text("Reaguj na potrząśnięcie")
        Switch(checked = enabled, onCheckedChange = { enabled = it },
            modifier = androidx.compose.ui.Modifier.semantics {
                contentDescription = "Reaguj na potrząśnięcie"
            })
    }
}

import SwiftUI
import Combine

struct Address: View {
    let shakes: AnyPublisher<Void, Never>
    let showAddress: () -> Void
    @State private var enabled = true
    var body: some View {
        VStack {
            Button("Pokaż adres", action: showAddress)
            Toggle("Reaguj na potrząśnięcie", isOn: $enabled)
        }
        .onReceive(shakes) { _ in
            if enabled { showAddress() }
        }
    }
}

import React, { useEffect, useRef, useState } from 'react';
import { Button, Switch, Text, View } from 'react-native';
import type { CodegenTypes } from 'react-native';

type Props = {
  onShake: CodegenTypes.EventEmitter<{ sequence: number }>;
  showAddress: () => void;
};
export function Address({ onShake, showAddress }: Props) {
  const [enabled, setEnabled] = useState(true);
  const enabledNow = useRef(enabled);
  const changeEnabled = (value: boolean) => {
    enabledNow.current = value;
    setEnabled(value);
  };
  useEffect(() => {
    const subscription = onShake(() => {
      if (enabledNow.current) showAddress();
    });
    return () => subscription.remove();
  }, [onShake, showAddress]);
  return (
    <View>
      <Button title="Pokaż adres" onPress={showAddress} />
      <Text>Reaguj na potrząśnięcie</Text>
      <Switch
        accessibilityLabel="Reaguj na potrząśnięcie"
        value={enabled}
        onValueChange={changeEnabled}
      />
    </View>
  );
}

Brak buildów trzech fragmentów edukacyjnych jest przyjętym zakresem materiału edukacyjnego, nie obowiązkiem budowania dodatkowych aplikacji.

Jak sprawdzić

1. Ustal każdą funkcję korzystającą z ruchu i źródło wejścia. Sam event listener lub import sensora nie dowodzi, że uruchamia funkcję. Oceń warunek/wyjątki; dla wyjątku AT potrzebny jest test konkretnego wspieranego interfejsu.
2. Przy aktywnym wejściu wykonaj ruch i zapisz wynik. Następnie z tego samego stanu wykonaj tę samą funkcję zwykłą kontrolką, bez ruchu. Wynik i dostęp do danych powinny być równoważne.
3. Wyłącz reakcję przez osiągalną kontrolkę albo skuteczny mechanizm systemowy. Ponów wejście i sprawdź, że dotarło, lecz nie uruchomiło funkcji; zbadaj też zdarzenia oczekujące. Jeśli nie ma dowodu wejścia, wynik blokady jest nieustalony.
4. Użyj alternatywy przy nadal wyłączonym ruchu. Nie może być blokowana tym samym ustawieniem. Ponownie włącz i sprawdź, że funkcja wraca wyłącznie po świadomym wyborze. Testuj dalsze widoki, cykl życia i restart zgodnie z realnym zakresem funkcji.
5. Zbadaj działanie/nazwę/stan kontrolek właściwymi metodami dostępności. Drzewo nie zastępuje VoiceOver, Switch Control ani faktycznej technologii użytej przez użytkownika.

W tej próbie krok ruchu zastąpiono jawną symulacją semantycznego sygnału. Test hostowy używa mocka MethodChannel i stałego czasu 123, więc nie jest testem iOS ani pomiarem. XCTest wykonuje systemowe tap w uruchomionej aplikacji i odczytuje natywne kontrolki; osobno odczytuje pomocniczy JSON stanu z debug Semantics. Oczekiwania wariantu są w asercjach/checku, poza zapisanym stanem aplikacji. Dziennik pochodzący z aplikacji nie jest niezależnym pomiarem czujnika.

Wyniki wykonania, wersje, zakres i hashe mają techniczne źródło w metadanych; wyciąg testów pochodzi z rzeczywistych logów. Zegary native, Dart i XCTest nie są zsynchronizowane; sekwencja identyfikuje odbiór, bez deklaracji fizycznej latencji. Screeny nie dowodzą czasu ani ruchu.

Weryfikacja i ograniczenia

• Reguła deterministyczna: przy znanym źródle i kontrolowanej próbie można porównać skutki odbioru on/off oraz zwykłej kontrolki. Nasz check ocenia zachowane dane jednej demonstracji, nie dowolną aplikację. Rzeczywisty test sensora musi osobno wykazać detekcję i dostarczenie sygnału.
• Przybliżenie z drzewa: nazwa/rola switch i przycisku ujawnia kandydatów. Brak widocznego switch nie dowodzi braku ustawień na innym ekranie/systemie; jego obecność nie dowodzi blokady. Nie ma w drzewie dowodu fizycznego potrząśnięcia ani niezbędności.
• Proponowane reguły ACT 7677a9 i c249d5: dotyczą odpowiednio równoważnych zmian przez UI i blokowania zmian przy device motion/orientation w HTML. Ich status podczas researchu to proposed, nie normatywne brzmienie WCAG. Używają pomocniczego okna minuty, którego WCAG nie ustanawia. Nie przenosimy go na obowiązkowy czas blokady i nie deklarujemy wykonania tych reguł w Flutterze. Nie pokrywają całego gestu do kamery ani wszystkich wyjątków; wynik pozytywny wymaga dalszych sprawdzeń. Inne zdarzenia i mechanizmy systemowe mogą zmienić interpretację wyniku.
• Ocena AI: pomaga ustalić parę funkcji, sprawdzić screenshoty i zasugerować wyjątek; nie potwierdza wspieranego AT ani fizycznych pomiarów. Identyczny adres nie wystarczy, gdy akcje różnią się skutkiem ubocznym.
• Ocena człowieka: weryfikuje interpretację niezbędności, pełen zakres funkcji i konfigurację AT. W tym opracowaniu pozostaje NOT-RUN.

Brak czujnika, zgody, sygnału lub reakcji to nie automatyczny PASS. Przycisk narzędzia testowego nie jest dowodem rzeczywistego wejścia ruchowego. Oceniając instrumentowany build, nie wolno usuwać jego kontrolki z drzewa tylko dlatego, że przeszkadza oczekiwanej klasyfikacji. Etykiety „oczekiwany dobry/błędny” pozostają poza wejściem walidatora; brak alternatywy trzeba zbadać osobno bez instrumentacji UI. Niebezpiecznych ani nieodwracalnych działań nie odtwarzamy; adres demonstracyjny nie zmienia zamówienia.

Jak sprawdza Clearship

Clearship porównuje stan ekranu przed i po potrząśnięciu oraz przechyleniu w lewo. Na Androidzie korzysta z potwierdzenia podania sygnału emulatora; trwała zmiana wskazuje funkcję uruchomioną ruchem. Kandydatów na wyłącznik i alternatywną kontrolkę rozpoznaje z ról oraz polskich i angielskich etykiet.

Metoda deterministyczna pointer-cancel-motion-1 spełniła próg Androida w pomiarach 8 października 2026 r. Nie dotyka wyłącznika i alternatywy, więc sama obecność obu kontrolek prowadzi do dalszej oceny równoważności oraz skuteczności blokady. Wyłącznik poza rozpoznanym zakresem ustawień może zostać przeoczony. Ciągła reakcja, nieznana funkcja, niezbadane menu i niepotwierdzone wejście pozostają nieustalone.

Na iOS potrząśnięcie nie ma potwierdzonego skutku, a przechylenie jest niewspierane; pomiar kontrolny 2.5.4 nie został wykonany i wymagana jest ocena człowieka. Inne osie, kamera, krokomierz, skutki backendu lub dźwięku bez zmiany drzewa, oba wyjątki oraz osobna treść webowa są poza potwierdzonym zakresem. Symulacja edukacyjnego przykładu iOS z 3 października nie jest pomiarem tej metody.

Powiązane kryteria

• 2.5.1
  Gesty wskazujące

  Gest palca po ekranie jest innym rodzajem wejścia niż ruch urządzenia.

• 2.1.1
  Klawiatura

  Alternatywna kontrolka potrzebuje właściwej obsługi klawiaturą.

• 2.5.3
  Etykieta w nazwie

  Nazwa alternatywy i wyłącznika zachowuje widoczny napis.

• 1.3.3
  Właściwości zmysłowe

  Instrukcja wskazuje kontrolkę również bez rozpoznania samego ruchu.