Zapobieganie błędom — zobowiązania prawne, finanse i dane

Co oznacza to kryterium

Przed działaniem, które wiąże prawnie, przenosi pieniądze, znacząco zmienia dane albo wysyła odpowiedzi testu, potrzebna jest skuteczna ochrona przed pomyłką. Wystarczy jedna droga: cofnięcie skutku, sprawdzenie danych z możliwością poprawy albo przegląd, poprawa i potwierdzenie przed finalizacją. Nie trzeba dodawać wszystkich trzech ani pytać „Czy na pewno?” przy każdym zapisie.

Ochrona może pomagać także innym osobom, ale ten wpis nie przypisuje automatycznie tagów hearing ani color-vision: wykazana bariera nie wynika z dźwięku lub barwy. Tagi są redakcyjnym słownikiem projektu, nie oficjalną klasyfikacją WCAG.

Przykłady błędów i poprawek

Syntetyczny test T-104 w Pracowni ma dwa kroki: „Ile boków ma kwadrat?” z początkowym 3 oraz „Przepisz literę B.” z B. Good i bad finalizują ten sam lokalny rekord odpowiedzi i zamykają jego edycję w sesji.

Problem: bad natychmiast wysyła 3 / B z drugiego kroku. Pierwsza odpowiedź nie jest tam widoczna; cały przepływ nie ma przeglądu, sprawdzenia błędów wejścia ani cofnięcia finalizacji. Skutek: wcześniejsza pomyłka trafia do końcowego rekordu. Poprawka: good przed skutkiem pokazuje obie odpowiedzi, konsekwencję oraz drogę anulowania, poprawy i potwierdzenia. Brak dialogu sam w sobie nie przesądza błędu.

Anulowanie, poprawa i finalizacja

1. Anuluj wraca do drugiego kroku, bez utworzenia wyniku.
2. Popraw wraca do pierwszej odpowiedzi 3. Zwykłe wpisanie 4 i Dalej zachowuje drugą odpowiedź B.
3. Nowy przegląd pokazuje rzeczywiste 4 / B. Dopiero Potwierdź i wyślij finalizuje ten sam snapshot. Bad kończy na 3 / B.

Odpowiedzi i szkic pozostają w pamięci lokalnej sesji, bez bazy, pliku, egzaminatora lub trwałego magazynu. Demonstracja modeluje przesłanie odpowiedzi testu; nie bada modyfikacji danych w systemie przechowywania, płatności ani skutku prawnego. Sam końcowy kadr nie dowodzi wcześniejszej sekwencji.

Kontrola zwykłej edycji szkicu

Control nie kończy testu. Zapisz szkic zmienia model i edytowalne pola z 3 / B na 4 / B; Cofnij zapis szkicu rzeczywiście przywraca model oraz pola 3 / B, przy zerze wysłanych testów. Nie wymusza przeglądu przy każdym zapisie. Reset demonstracji i zmiana wariantu rozpoczynają próbę od nowa, więc nie są ochroną realnego wysłania.

Kiedy obowiązuje i gdzie są wyjątki

Norma wymienia cztery warunki: zobowiązania prawne, transakcje finansowe, modyfikacja lub usunięcie user-controllable data w systemach przechowywania, przesłanie odpowiedzi użytkownika w teście. Zobowiązanie prawne oznacza prawnie wiążący obowiązek lub korzyść; techniczne wysłanie dowolnego formularza nie wystarcza do takiej kwalifikacji. W tym opracowaniu nie oceniamy skuteczności umowy ani prawa do odstąpienia.

Wystarczy jedna z alternatyw:

• Odwracalność: rzeczywiście można cofnąć wysłanie lub jego skutek. Powrót do wcześniejszego widoku albo komunikat „można anulować” bez skutecznej procedury nie dowodzą odwracalności.
• Sprawdzenie: dane użytkownika są sprawdzane pod kątem błędów wejścia, a użytkownik może je poprawić. Definicja błędu obejmuje wymaganą pominiętą wartość oraz niedozwolony format/wartość. To nie obowiązek automatycznego odgadnięcia zamiaru, poprawnej odpowiedzi merytorycznej na test lub gwarancja wykrycia każdej pomyłki. Nie ograniczaj sprawdzenia istotnych danych do przypadkowo wybranego nieistotnego pola.
• Potwierdzenie: dostępny mechanizm pozwala przejrzeć informacje, poprawić je i potwierdzić przed ostatecznym wysłaniem. Musi dotyczyć rzeczywistych wartości końcowych, nie starego podsumowania ani przykładowych danych. Mechanizm także podlega pozostałym kryteriom deklarowanego poziomu zgodności.

Intencja odnosząca się do danych chroni przed znaczącą utratą, np. usunięciem pliku lub rekordu. Nie wymaga potwierdzenia każdego polecenia zapisu ani prostego tworzenia lub edycji dokumentów, rekordów i innych danych. Dane kontrolowane przez użytkownika są przeznaczone do jego dostępu i celowej zmiany/usunięcia; niewidoczne logi oraz monitoring wyszukiwarki nie stają się nimi tylko dlatego, że system je zbiera. Reset fixture jest narzędziem odtwarzania demonstracji, nie ochroną wysłania i nie dowodem odwracalności.

Nie stosuj ogólnego wyjątku „bezpieczeństwo lub cel treści” z 3.3.3 do 3.3.4. Nie rozszerzaj AA do wszystkich przesłań informacji z 3.3.6 AAA. Objaśnienia i techniki są informacyjne; można zastosować inne skuteczne rozwiązanie spełniające normę.

Techniki i ich granice

W sprawdzonym Understanding nie ma listy dedykowanych błędów F dla 3.3.4. Opisany wcześniej błąd jest własnym odtworzeniem, bez przypisania numeru F i bez danych o częstości. Katalog ACT przy 3.3.4 jawnie wskazuje brak reguł; ACT NOT-RUN, brak reguły nie oznacza automatycznej zgodności.

Platformy

Data i status każdego wiersza: AI 2026-10-04; człowiek NOT-RUN. Stan zastosowania dotyczy wymagania, a kolumna wykonania tylko tej demonstracji. Nazwy środowisk pochodzą ze słownika design systemu.

Klasyfikacja nie ustala obowiązku wynikającego z regulacji lub konkretnej wersji EN 301 549; takie mapowanie wymaga odrębnej podstawy. W aplikacji hybrydowej trzeba ocenić część natywną i webową. Brak uruchomienia platformy nie oznacza jej wyłączenia.

Rozwiązania w technologiach

Wdrożenie ochrony składa się z logiki transakcji i dostępnego interfejsu. Poniższe minimalne panele przeglądu zakładają, że rodzic zachował cały draft dwóch kroków, przy wejściu do przeglądu utworzył snapshot odpowiedzi, a edit wraca do tych zachowanych pól. cancel opuszcza przegląd bez skutku. commit finalizuje ten sam snapshot, który pokazano. Callback produkcyjny musi obsłużyć rzeczywisty wynik; lokalna zmiana widoku nie dowodzi zapisu serwerowego. CSS lub nazwa przycisku samodzielnie nie zapewniają tego zachowania.

// W State, obok kontrolerów first/second oraz pending/finalAnswers.
void commit((String, String) answers) {
  finalAnswers = answers;
  reviewing = false;
  pending = null;
  message = 'Wysłano finalne odpowiedzi. Edycja zamknięta.';
}
// Wejście do przeglądu, przed skutkiem:
setState(() {
  pending = (first.text, second.text);
  reviewing = true;
});
// Przycisk w tym samym przeglądzie; tekst danych korzysta z pending.
CupertinoButton(
  onPressed: () => setState(() => commit(pending!)),
  child: const Text('Potwierdź i wyślij'),
);

import SwiftUI
struct Answers { let first: String; let second: String }
struct TestReview: View {
    let answers: Answers
    let edit: () -> Void
    let cancel: () -> Void
    let commit: (Answers) -> Void
    var body: some View {
        VStack(alignment: .leading, spacing: 12) {
            Text("Przegląd T-104").font(.headline)
            Text("1. Ile boków ma kwadrat? \(answers.first)")
            Text("2. Przepisz literę B. \(answers.second)")
            Text("Wysłanie kończy test i zamyka edycję.")
            Button("Anuluj wysyłanie", action: cancel)
            Button("Popraw odpowiedzi", action: edit)
            Button("Potwierdź i wyślij") { commit(answers) }
        }
    }
}

import androidx.compose.foundation.layout.Column
import androidx.compose.material3.Button
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable

data class Answers(val first: String, val second: String)
@Composable
fun TestReview(
    answers: Answers, edit: () -> Unit, cancel: () -> Unit,
    commit: (Answers) -> Unit
) {
    Column {
        Text("Przegląd T-104")
        Text("1. Ile boków ma kwadrat? ${answers.first}")
        Text("2. Przepisz literę B. ${answers.second}")
        Text("Wysłanie kończy test i zamyka edycję.")
        Button(onClick = cancel) { Text("Anuluj wysyłanie") }
        Button(onClick = edit) { Text("Popraw odpowiedzi") }
        Button(onClick = { commit(answers) }) { Text("Potwierdź i wyślij") }
    }
}

import { Pressable, Text, View } from 'react-native';
type Answers = Readonly<{ first: string; second: string }>;
type Props = {
  answers: Answers;
  edit: () => void;
  cancel: () => void;
  commit: (answers: Answers) => void;
};
export function TestReview({ answers, edit, cancel, commit }: Props) {
  return (
    <View>
      <Text>Przegląd T-104</Text>
      <Text>1. Ile boków ma kwadrat? {answers.first}</Text>
      <Text>2. Przepisz literę B. {answers.second}</Text>
      <Text>Wysłanie kończy test i zamyka edycję.</Text>
      <Pressable accessibilityRole="button" onPress={cancel}>
        <Text>Anuluj wysyłanie</Text>
      </Pressable>
      <Pressable accessibilityRole="button" onPress={edit}>
        <Text>Popraw odpowiedzi</Text>
      </Pressable>
      <Pressable accessibilityRole="button" onPress={() => commit(answers)}>
        <Text>Potwierdź i wyślij</Text>
      </Pressable>
    </View>
  );
}

// Zdarzenie submit: zatrzymanie domyślnej finalizacji.
e.preventDefault();
pending = [get('answer-one').value, get('answer-two').value];
render(); // pokazuje obie rzeczywiste wartości, edit/cancel/confirm
// Dopiero zwykła aktywacja przycisku potwierdzenia:
get('confirm-action').onclick = () => commit(pending);

Jak sprawdzić

1. Ustal, czy funkcja powoduje któryś z czterech skutków normy. Rozpoznaj realny moment finalizacji i istotne dane; obejmij cały proces, także wcześniejsze kroki.
2. Sprawdź każdą dostępną alternatywę, zanim zgłosisz brak ochrony. Jeśli jedna skutecznie działa, brak dwóch pozostałych nie jest sam w sobie błędem 3.3.4.
3. Dla przeglądu wprowadź świadomie inne dane w poprzednim kroku. Sprawdź, czy podsumowanie pokazuje dokładnie je, a poprawa zachowuje pozostałe dane. Anuluj, sprawdź brak skutku, ponownie przejrzyj, popraw i finalizuj. Zweryfikuj rzeczywisty rezultat.
4. Dla sprawdzenia danych przetestuj pominięcie i niedozwolony format/wartość zgodnie z regułami danego procesu; błędne dane nie powinny finalizować się bez możliwości poprawy. Nie oceniaj błędnej odpowiedzi merytorycznej testu jako automatycznie odrzucanego input error.
5. Dla odwracalności wykonaj dozwolone syntetyczne działanie i procedurę cofnięcia. Sprawdź dane i skutek po powrocie, termin i dostępność procedury. Nie wyciągaj wniosku z samej etykiety Undo lub resetu narzędzia.
6. Oceniaj dostępność samego mechanizmu: dane do odczytu, osiągalne działania, nazwy, powrót i zachowanie wpisanych wartości. Gdy potrzebny jest rzeczywisty kanał zewnętrzny lub AT, zapisuj oddzielny dowód; jego brak nie daje PASS.

Rzeczywiste wykonanie źródła

Wyniki są z 2026-10-04, bez powtórzenia w migracji.

Checker potwierdza znane stany, nie kwalifikuje dowolnej umowy, czasu anulowania lub zewnętrznego kanału. Brak dialogu przy odwracalnej operacji może dać fałszywy alarm; atrapa Undo lub ogólne pytanie mogą dać fałszywy PASS. Sekwencja, drzewo i screenshot nie zastępują skutecznego cofnięcia ani odbioru AT. Oczekiwania fixture pozostają poza wejściem zaślepionego walidatora, którego nie uruchomiono.

Jak sprawdza Clearship

Clearship zbiera kandydatów i dowody przez set-evidence-1 w P0. Rozpoznaje kontrolkę z czasownikiem zapłaty, zamówienia, rezerwacji, usunięcia lub podpisu; zestawia pola, tekst przeglądu, poprawę, potwierdzenie/anulowanie, checkbox, błędy i stan po wysłaniu. Nie wykonuje sam ochrony ani nie kwalifikuje skutku prawnego.

Wynik jest zawsze „wymaga człowieka”. Brak kandydata też nie oznacza braku problemu. Odpowiedzi testów, zmiana danych pod Zapisz zmiany i zobowiązanie bez rozpoznanego czasownika mogą nie zostać wskazane. Człowiek ocenia aktualność podsumowania, skuteczność cofnięcia oraz inne drogi finalizacji, np. Enter. Nie trzeba znaleźć wszystkich trzech ochron, jeżeli jedna działa.

Próby zestawu rozwojowego Androida z 8 października i iOS z 9 października 2026 r. wskazały 14/14 przypadków na każdej platformie. To test zbierania dowodów, bez progu lub kontrolnego pomiaru zgodności; katalog ma not-measured. Pełne aplikacje dają też kandydatów poza pulą, których znaczenie rozstrzyga człowiek. Nie badano treści webowej tą metodą, a źródłowy T-104 nie jest pomiarem produktu.

Powiązane kryteria

• 3.3.1
  Identyfikacja błędu

  Identyfikacja błędu nie zastępuje ochrony przed skutkiem wysłania.

• 3.3.2
  Etykiety lub instrukcje

  Etykiety i instrukcje pomagają wpisać dane, ale nie są same ochroną finalizacji.

• 3.3.3
  Sugestie korekty błędów

  Znana sugestia korekty ma inny warunek i wyjątek niż zapobieganie błędom.

• 3.3.6
  Zapobieganie błędom — wszystkie

  AAA rozszerza ochronę na wszystkie przesłania informacji.

  Artykuł nie jest jeszcze dostępny.