Podczas wprowadzania danych

Co oznacza to kryterium

Zmiana opcji lub wpisanie danych powinny mieć przewidywalny skutek. Jeśli sama zmiana wartości przenosi użytkownika do innego widoku, okna lub miejsca pracy, trzeba go o tym uprzedzić przed użyciem kontrolki. Można też pozostawić wybór w formularzu i przejść dalej osobnym, jasno nazwanym przyciskiem. Uprzedzenie dopuszczone tutaj nie usprawiedliwia zmiany kontekstu po samym otrzymaniu fokusu.

Nie dodajemy automatycznie słuchu ani rozróżniania barw. Tagi opisują potrzeby w tych scenariuszach, nie diagnozy ani oficjalną klasyfikację WCAG.

Przykłady błędów i poprawek

Pracownia pokazuje syntetyczne P-104, ul. Ogrodowa 8, piątek 10:00–18:00. Obie pary zaczynają z wyłączonym odbiorem i pustym kodem; wpisywany kod to 104. Good i bad mają te same etykiety, dane i funkcje. Różnica dotyczy automatycznego przejścia po zmianie wartości, zamiast oczekiwania na osobną aktywację.

Problem: włączenie odbioru lub wpisanie trzeciej cyfry w bad zastępuje formularz podsumowaniem bez wcześniejszej informacji. Skutek: edycja kończy się przed świadomym zatwierdzeniem, użytkownik traci możliwość bieżącej korekty. Poprawka: onChanged aktualizuje dane, a onPressed osobnego przycisku przechodzi do podsumowania. Wariant warned pokazuje drugą dopuszczoną drogę — konkretną instrukcję przed zmianą. Late informuje dopiero po przejściu i pozostaje błędny.

Wybór odbioru

1. Pierwszy Tab ustawia fokus bez zmiany wartości i widoku we wszystkich pięciu wariantach pickup.
2. Space zmienia false → true. Good zachowuje formularz i fokus; bad przechodzi bez uprzedzenia. Dotknięcie switcha zbadano osobno w obu wariantach.
3. W good Tab na przycisk i Space otwierają ten sam widok docelowy co bad, z inną przyczyną i w wybranym momencie.
4. Control zmienia tylko cenę 14,90 → 0,00 zł w stałym miejscu; odwrócenie i ponowny wybór nie przechodzą dalej.

Wpisanie kodu

Końcowy XCTest dotykał pola i wpisywał oddzielnie 1, 0, 4. Good po każdej cyfrze zachowywał edycję; Tab po 104 nie wysyłał formularza. Bad przechodził po trzeciej cyfrze. Trzy cyfry są warunkiem tej demonstracji, nie progiem WCAG. Wcześniejsza nieudana sesja Tab do pola nie jest zaliczeniem końcowej ścieżki; test widgetu badał Tab osobno.

Kiedy obowiązuje i gdzie są wyjątki

• Wymaganie normatywne: zmiana ustawienia dowolnej kontrolki nie powoduje automatycznie zmiany kontekstu, chyba że o zachowaniu uprzedzono przed użyciem kontrolki. Nie ma osobnego wyjątku „niezbędne” ani listy dozwolonych typów aplikacji.
• Zmiana ustawienia: trwała wartość lub stan po zakończeniu interakcji: zaznaczenie checkboxa, przełączenie switcha, wybrana opcja, wpisany tekst. Przycisk przełączający stan lub wyłączający się po użyciu także może zmieniać ustawienie. Nie klasyfikuj wyzwalacza wyłącznie po nazwie typu widgetu.
• Aktywacja: link albo przycisk wysyłający formularz, otwierający modal czy przechodzący dalej uruchamia polecenie. Nie jest automatycznie zmianą ustawienia tylko dlatego, że użytkownik go kliknął. Przy mieszanym działaniu przeanalizuj rzeczywisty stan i przyczynę, zamiast wyłączać wszystkie przyciski.
• Zmiana kontekstu: duży skutek mogący dezorientować osobę niewidzącą całego widoku naraz; dotyczy m.in. odbiornika, obszaru widoku, fokusu i treści zmieniającej znaczenie strony. Nowe okno, przeniesienie fokusu do innej kontrolki, inny albo pozornie nowy ekran i znaczne przeorganizowanie treści są przykładami. Brak zmiany URL nie dowodzi braku zmiany kontekstu.
• Lokalna aktualizacja: zmiana ceny, podpowiedzi lub zależnych pól nie musi zmieniać kontekstu, jeśli pozostaje ten sam formularz, zadanie, znaczenie i fokus. Sam DOM diff, nowy tekst, animacja albo otwarcie klawiatury systemowej nie są wystarczającym dowodem naruszenia autora.
• Uprzedzenie: opisz konkretny skutek przed użyciem, w osiągalnej instrukcji lub wcześniejszym kroku. G13 dopuszcza instrukcję poprzedzającą kontrolkę, wcześniejszy etap procesu, a w określonym intranecie wcześniejsze wymagane szkolenie. Programowe powiązanie instrukcji z kontrolką jest pomocną techniką. Nie ustanawiamy dodatkowego normatywnego obowiązku checkboxa zgody ani ostrzeżenia po każdym ponownym użyciu.
• „Odbiór w Pracowni” samo w sobie nie zapowiada podsumowania. Tekst „wartość zmieniona” jest zbyt ogólny. Komunikat po przejściu, toast znikający przed odczytem lub instrukcja niedostępna przed pierwszą zmianą nie realizują warunku uprzedzenia. Sama obecność tekstu w kodzie nie dowodzi dostępności instrukcji dla użytkownika.
• Granica 3.2.1: samo otrzymanie fokusu jest odrębnym wyzwalaczem. Uprzedzenie dopuszczone w 3.2.2 nie usprawiedliwia zmiany kontekstu przy samym fokusie. Końcowy XCTest potwierdza pierwszy Tab bez zmiany wartości i widoku w pięciu wariantach pickup. Pole kodu otrzymuje fokus przez dotknięcie; próby Tab z wcześniejszej nieudanej sesji nie stanowią końcowego zaliczenia tej ścieżki. Test widgetu sprawdza Tab także dla pola kodu, w osobnym środowisku testowym Fluttera.
• F36/F37: opisane błędy WWW dotyczą automatycznej zmiany kontekstu po uzupełnieniu/opuszczeniu pola oraz nowego okna po zmianie wyboru bez uprzedzenia. Opisane mobilne przejścia są własnymi analogicznymi scenariuszami, nie dosłownym wykonaniem HTML F36/F37 ani testem otwarcia nowego okna.
• Techniki pomocnicze: G80 oddziela zmianę wartości od zatwierdzenia; H32/H84 pokazują rozwiązanie HTML. G13 wyjaśnia uprzedzenie, SCR19 lokalną aktualizację bez zmiany kontekstu. Nie są jedynymi sposobami spełnienia wymagania ani nowymi obowiązkami natywnych API.
• Dopuszczalne uprzedzenie nie potwierdza wszystkich innych kryteriów: np. nawigacja po grupie opcji może wciąż uniemożliwić wybór klawiaturą. 3.2.5 (AAA) obejmuje szerszy zakres zmian kontekstu; 3.3.2 dotyczy instrukcji danych, 3.3.1 błędów, a 4.1.3 komunikatów statusu. Nie oceniono ich zgodności tutaj.

Platformy

Domyślna podstawa to WCAG 2.2. Poza WWW zastosowano Group Note WCAG2ICT z 2025-12-11: 3.2.2 stosuje się bez zmiany brzmienia do dokumentów poza WWW i oprogramowania, z odniesieniem do intencji Understanding. WCAG2ICT jest wskazówką informacyjną, nie osobną normą zgodności ani wyborem podstawy prawnej. Zmianę znaczenia strony odnosimy do kontekstu dokumentu lub oprogramowania.

Oddzielne mapowanie EN 301 549

Sprawdzono EN 301 549 V3.2.1 (2021-03), AI 2026-10-03. Nie deklarujemy, że jest najnowszą wersją lub właściwą podstawą prawną konkretnego audytu. Innych wersji EN nie mapowano.

To bezpośrednie klauzule wskazanej EN, odrębne od WCAG2ICT. Żaden wiersz nie oznacza „brak odpowiednika we wskazanej normie”. Nie dotyczy badanego scenariusza: statyczny dokument, kiosk i TV nie występują w demonstracji; nie wyłącza to platform. Nie wykonano pełnego testu EN ani oceny obowiązków prawnych.

Rozwiązania w technologiach

Poniższe fragmenty pokazują zasadę wartość → lokalny stan; przycisk → przejście. Dane i callback podsumowania są własnym kontekstem aplikacji; nie traktujemy ich jako API platform. Minimalny wspólny przykład ma switch, więc nie wymusza czterech dodatkowych aplikacji lub pól kodu.

import 'package:flutter/cupertino.dart';
// W State<StatefulWidget>: bool pickup = false; void openSummary() { ... }
Column(children: [
  Row(children: [
    const Expanded(child: Text('Odbiór w Pracowni')),
    Semantics(label: 'Odbiór w Pracowni', child: CupertinoSwitch(
      value: pickup,
      onChanged: (value) => setState(() => pickup = value),
    )),
  ]),
  CupertinoButton(onPressed: openSummary,
    child: const Text('Przejdź do podsumowania')),
]);

import androidx.compose.foundation.layout.Column
import androidx.compose.material3.Button
import androidx.compose.material3.Switch
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.runtime.getValue
import androidx.compose.runtime.mutableStateOf
import androidx.compose.runtime.remember
import androidx.compose.runtime.setValue
import androidx.compose.ui.Modifier
import androidx.compose.ui.semantics.contentDescription
import androidx.compose.ui.semantics.semantics

@Composable
fun Pickup(onReview: (Boolean) -> Unit) {
    var pickup by remember { mutableStateOf(false) }
    Column {
        Text("Odbiór w Pracowni")
        Switch(checked = pickup, onCheckedChange = { pickup = it },
            modifier = Modifier.semantics {
                contentDescription = "Odbiór w Pracowni"
            })
        Button(onClick = { onReview(pickup) }) {
            Text("Przejdź do podsumowania")
        }
    }
}

import SwiftUI

struct Pickup: View {
    @State private var pickup = false
    let onReview: (Bool) -> Void
    var body: some View {
        VStack {
            Toggle("Odbiór w Pracowni", isOn: $pickup)
            Button("Przejdź do podsumowania") { onReview(pickup) }
        }
    }
}

import React, { useState } from 'react';
import { View, Text, Switch, Pressable } from 'react-native';

export function Pickup({ onReview }: { onReview: (pickup: boolean) => void }) {
  const [pickup, setPickup] = useState(false);
  return (
    <View>
      <Text>Odbiór w Pracowni</Text>
      <Switch
        accessibilityLabel="Odbiór w Pracowni"
        value={pickup}
        onValueChange={setPickup}
      />
      <Pressable accessibilityRole="button" onPress={() => onReview(pickup)}>
        <Text>Przejdź do podsumowania</Text>
      </Pressable>
    </View>
  );
}

Status dokumentacji i wykonania

Brak buildów fragmentów edukacyjnych jest jawnym zakresem materiału, bez obowiązku tworzenia czterech aplikacji. Analiza składni nie potwierdza doświadczenia użytkownika ani czytnika.

Jak sprawdzić

Dobór wykonania: wybrano główną demonstrację mobilną we wspólnej aplikacji Flutter/Cupertino, zgodnie z zakresem zlecenia. Switch i pole kodu pozwalają oddzielić otrzymanie fokusu, zmianę wartości oraz aktywację; wymiana formularza na podsumowanie jest zmianą kontekstu bez udziału adresu strony. Nie zbudowano osobnego HTML, aplikacji Compose, SwiftUI lub React Native ani nie uruchamiano Androida.

1. Na świeżej trasie ustal wartości, widok, etykiety, fokus i dostępną instrukcję przed użyciem. Dane startowe i końcowe muszą być takie same w parze.
2. Przejdź Tab na switch bez Space. Widok i wartość pozostają; ten krok kontroluje granicę 3.2.1. Dopiero Space zmienia wartość. Osobno wykonaj dotknięcie switcha w obu wariantach.
3. Po zmianie wartości w good przejdź Tab na przycisk i aktywuj go Space. Przejście dopiero po aktywacji ma inny wyzwalacz niż automatyczne przejście w bad.
4. Przy kodzie dotknij widocznego pola i wpisz osobno 1, 0, 4. Odczytaj odebrane callbacki, tekst i widok po każdej cyfrze. W good sprawdź opuszczenie pola Tab bez przejścia, potem osobną aktywację przycisku.
5. Porównaj bad z warned: taka sama automatyczna zmiana po wartości, ale w warned instrukcja istnieje przed użyciem i opisuje dokładny skutek. Sprawdź jej widoczność, kolejność, powiązanie i dostępność. W late instrukcja pojawia się dopiero po przejściu.
6. W control zmień opcję w obu kierunkach i ponownie ją wybierz. Lokalna cena zmienia się w zarezerwowanym miejscu, przycisk ma ten sam prostokąt, fokus i zadanie pozostają. Nie opieraj tej oceny tylko na prostokącie.
7. Sprawdź powrót, reset danych i trasy, wybór scenariusza/wariantu i bezpieczny fallback. Nie mieszaj ustawień demonstracji z kontrolkami zamówienia.

Wyniki źródłowej próby — 2026-10-03

Flutter 3.44.9 / Dart 3.12.2, Xcode 27.0 / SDK 27.0, macOS 27.0, iPhone 17 Simulator / iOS 26.5. Ramka 402 × 874 pt, PNG 1206 × 2622 px, DPR 3, jasny wygląd i tekst large. Pasek 9:41 jest prezentacyjny; końcowe odczyty obejmują 19:33:13–19:36:05 Europe/Warsaw.

Zachowano 54 odczyty aplikacji, 54 natywne drzewa i 51 żądań: 30 Tab/Space, 12 pojedynczych cyfr, 5 dotknięć kontrolek i 4 środka pola. Są 52 różne nazwy próbek; oba startowe odczyty good/bad pickup zachowano dla osobnego przebiegu dotykowego. Callback potwierdza każdą zmianę kodu. Natychmiastowe zwrócenie tap i aktualizacja AX nie są atomowe, więc fokus potwierdzano późniejszym odczytem. Odebrane klawisze miały właściwe HID i nie były oznaczone jako synthesized.

Wcześniejsze nieudane próby

Pierwsze testy widgetów ujawniły nieaktualny eksport fokusu i dodatkowy przystanek Tab opakowania Focus; poprawiono obserwację oraz skipTraversal. Przy teście semantyki skorygowano moment zwolnienia SemanticsHandle. Nie są to końcowe wyniki ani dowody błędu 3.2.2 w good. Snapshot pierwszego testu zrekonstruowano przez przywrócenie wcześniejszego Tab; nie twierdzono, że hash zebrano podczas pierwszej próby.

Część nieudanych procesów xcodebuild nadal zbierała diagnostykę po starcie następnej próby, więc diagnostyka wcześniejszych xcresult może być niepełna. Końcowa sesja zakończyła się kodem 0; wcześniejsze FAIL zachowano. Łącznie źródło zachowuje 17 PNG: osiem końcowych, osiem historycznych z A i jeden debug po C, oraz odrębne obserwacje, drzewa i metadane.

Weryfikacja i ograniczenia

• Deterministyczne odtworzenie demonstracji: ciąg wejść i odebranych zmian wartości oraz widoku pozwala sprawdzić konkretne pary. Oczekiwania PASS/FAIL znajdują się w testach i checkerze, poza obserwatorem aplikacji. PASS testu reprodukcji bad lub late oznacza odtworzenie usterki; oba warianty nadal mają negatywną ocenę 3.2.2.
• Przybliżenie z drzewa: rola Switch/TextField, wartość, nagłówek, zniknięcie formularza i fokus wskazują zachowanie do interpretacji. Drzewo nie rozstrzyga samo, czy treść zmieniła znaczenie i czy użytkownik mógł wcześniej poznać skutek. Nie wystarczy wykrycie callbacka onChanged, nowego tekstu lub brak nowego URL.
• Dla uprzedzenia potrzeba odczytu przed pierwszym użyciem, konkretnej treści zapowiadającej skutek oraz sposobu jej poznania. Instrukcja widoczna dopiero po zdarzeniu nie może zostać dopisana jako wcześniejsze ostrzeżenie. Tekst w semantycznym hint nie jest dowodem jego wypowiedzenia przez VoiceOver.
• Żądanie XCTest i odczyt aplikacji nie są jedną atomową próbką. Aktualizacja drzewa po dotknięciu pola może być opóźniona; driver czeka na rzeczywiście odczytany fokus. Zdarzenie dotknięcia, świeża próbka oraz callback tekstu mają osobne role. Obrys lub kursor nie zastępują potwierdzenia odbioru.
• Flutter primaryFocus jest obserwacją frameworka, a nie nagraniem fokusu VoiceOver. Natywne drzewa pokazują nazwę, rolę, wartość i układ, nie doświadczenie czytnika. Wejścia XCTest są rzeczywistymi wejściami systemowymi w Simulatorze, lecz nie fizycznym dotykiem ani klawiaturą człowieka.
• Ocena AI obejmuje research, odczyty i oględziny mediów. Ocena człowieka oraz badanie skuteczności walidatora Clearship na niezależnych przypadkach są NOT-RUN. Brak danych, brak wykrycia lub test własnych przykładów nie dowodzą uogólnienia ani zgodności aplikacji.
• Ustawienia demonstracji, trasy, identyfikatory próbek i stopka ujawniają wariant. To ograniczenie przyszłej zaślepionej oceny: wyłączyć konfigurację, nazwy good/bad i oczekiwania z wejścia badanego walidatora, udostępniając wyłącznie neutralne obserwacje produktu. Obecny przebieg nie jest taką oceną. Nie kopiować kompletnego katalogu assetów do wejścia walidatora.

Weryfikacja zapisanych danych zna oczekiwania demonstracji i bada integralność; nie powtarza UI ani nie mierzy skuteczności Clearship. Obserwator rejestruje wartości, fokus, wejścia i instrukcję, ale nie ocenia zgodności. Semantyczny hint i natywne drzewa nie dowodzą wypowiedzi czytnika. Wejście systemowe XCTest nie jest fizycznym dotykiem człowieka.

Przegląd człowieka i zaślepiona ocena walidatora pozostają NOT-RUN. VoiceOver/FKA, przełączniki, fizyczny iPhone, inne odbiorniki i buildy fragmentów edukacyjnych nie są wykonane. Nie przygotowano filmu ani audio, nie badano płynności ani czasu reakcji. Wcześniejsze FAIL pozostają historią, a redakcja nie ponawia tych prób.

Jak sprawdza Clearship

Clearship na Androidzie odczytuje stan przed i po dotknięciu kontrolki ustawienia. Deterministyczna metoda labels-input-change-1 wskazuje przejście do innego ekranu lub zmianę języka treści; AI ocenia, czy przed użyciem była instrukcja zapowiadająca ten skutek. Sam detektor nie zgłasza usterki bez oceny uprzedzenia. Do AI trafia obraz i ograniczone drzewo przed akcją, do 200 węzłów.

Pomiar kontrolny z 8 października 2026 r. pozostał poniżej progu: 4/6 usterek i 2 fałszywe alarmy na 24 poprawnych ekranach. Wynik wymaga człowieka. Brak obserwacji po zmianie, niedotknięta kontrolka, niepewność lub błąd AI nie dają wyniku pozytywnego. Ta sama lokalna aktualizacja tekstu może mieć inny skutek dla zadania i wymaga oceny znaczenia.

Metoda nie wykrywa zmian kontekstu po wpisaniu lub opuszczeniu pola, nowych okien, wyjścia z aplikacji, skutków opóźnionych ani zmiany znaczenia bez zmiany języka. Nie wybiera pozycji pickerów i list rozwijanych. Uprzedzenie dostępne tylko czytnikowi nie jest oceniane osobno; WWW jest poza zakresem.

Na iOS P0 nie dotykało badanych przełączników, a opcje przedstawione jako przyciski nie miały selected przed pierwszym wyborem. Brak kandydatów nie potwierdza poprawności: pomiar kontrolny 3.2.2 jest NOT-RUN, a wynik wymaga człowieka. Końcowe XCTest edukacyjnej demonstracji iOS nie potwierdza tej metody produktu.

Powiązane kryteria

• 3.2.1
  Po otrzymaniu fokusu

  Samo otrzymanie fokusu ma inny wyzwalacz i nie dopuszcza wyjątku uprzedzenia.

• 2.4.3
  Kolejność fokusu

  Kolejność fokusu po jawnej akcji jest osobnym zagadnieniem.

• 3.3.1
  Identyfikacja błędu

  Błąd danych wymaga tekstowej identyfikacji, niezależnie od momentu przejścia.

• 3.3.2
  Etykiety lub instrukcje

  Instrukcje wprowadzania danych różnią się od uprzedzenia o zmianie kontekstu.

• 4.1.3
  Komunikaty o stanie

  Komunikat lokalnej aktualizacji może wymagać udostępnienia statusu bez zmiany fokusu.

• 3.2.5
  Zmiana na żądanie

  AAA dotyczy szerszego zakresu inicjowania zmian kontekstu.

  Artykuł nie jest jeszcze dostępny.