Sugestie korekty błędów

Co oznacza to kryterium

Jeśli system automatycznie wykryje błąd danych i zna sposób poprawy, przekaż tę pomoc użytkownikowi. Może to być reguła formatu, przykład, dozwolone wartości lub sposób ich znalezienia. Nie trzeba zgadywać nieznanej odpowiedzi ani zmieniać wpisu za użytkownika. Wyjątek dotyczy sugestii zagrażającej bezpieczeństwu lub celowi treści.

Przykłady błędów i poprawek

Własna Pracownia używa syntetycznych danych: kod 00001, uwagi Dwa kubki, akcja Zapisz. Jeden lokalny validator odrzuca format. Good i bad zachowują wpisy oraz identyfikują pole i problem; różni je tylko treść znanej pomocy.

Problem: bad kończy komunikat na „Kod pocztowy: niepoprawny format.”. Skutek: użytkownik wie, co jest odrzucone, ale musi odgadnąć znaną systemowi składnię. Poprawka: good dodaje „Wpisz dwie cyfry, łącznik i trzy cyfry, np. 00-001.”. To uproszczony kontrakt formatu, bez sprawdzania rejestru kodów lub rzeczywistego adresu.

Korekta i pominięcie wartości

Ręczne zastąpienie wpisu przez 00-001 oraz ponowne Zapisz usuwa błąd i potwierdza „Zapisano kod 00-001. Uwagi: Dwa kubki.” w obu wariantach, na iOS i w odbiorniku webowym. Bad nie blokuje osoby znającej format; barierą jest brak pomocy. To regresja formularza, bez pomiaru doświadczenia użytkownika.

Po wpisaniu tylko uwag good opisuje brak wymaganego kodu i podaje ten sam znany format; zachowuje uwagi. Wykonano tę gałąź na iOS i w formularzu webowym. Osobne wykonanie pustej wartości bad jest NOT-RUN; kod zawiera tylko opis braku.

Kontrola nieznanego zamierzonego numeru

Control odrzuca P-999, mimo poprawnej składni numeru podanej przed polem. System zna syntetyczny rekord P-104, lecz nie wie, którego zamówienia szuka osoba. Istnienie rekordu nie uzasadnia przedstawienia go jako właściwej korekty. Kontekst wskazuje potwierdzenie jako sposób znalezienia własnego numeru.

Driver ma wcześniej posiadany P-104 z potwierdzenia i wpisuje go zwykłym wejściem. Wynik „P-104: gotowe. Dwa kubki.” potwierdza lookup i zachowanie uwag; nie rozstrzyga automatycznie 3.3.3 w control. W prawdziwym audycie ustal każdą znaną bezpieczną pomoc. Nieznana konkretna odpowiedź nie wyłącza obowiązku wszelkiej pomocy, a fixture nie dowodzi ochrony prawdziwych danych.

Dalsze scenariusze edukacyjne — niewykonane

Wszystkie trzy scenariusze są NOT-RUN. Nieznana trasa otwiera delivery/good. Cykl good → bad → control → good czyści kod i komunikat, zachowując uwagi; reset wraca do good i czyści wszystkie dane. To narzędzia demonstracji, bez obchodzenia bariery ocenianego wariantu.

Kiedy obowiązuje i gdzie są wyjątki

Warunek ma dwie części jednocześnie: system automatycznie wykrył błąd wejścia, a sugestie korekty są znane. Błędem wejścia jest nieakceptowana informacja, w tym pominięta wymagana wartość, nieakceptowany format lub wartość. Awaria sieci lub serwera sama w sobie nie jest błędem danych użytkownika. Kryterium nie ustanawia obowiązku walidacji każdej informacji, tworzenia nieznanej odpowiedzi, zgadywania zamierzonego adresu ani zmiany wpisu bez decyzji użytkownika.

Znana pomoc może opisywać format, przedstawiać przykład, podawać dozwolone wartości lub wskazywać dostępny sposób wyboru. Nie musi być jedną pewną odpowiedzią. Stwierdzenie „Niepoprawny format” identyfikuje naturę problemu, ale w badanej parze nie przekazuje znanej składni NN-NNN. Pomoc ma umożliwiać poprawę konkretnego błędu, nie sprowadzać się do „Spróbuj ponownie”. Sam ogólny komunikat nad formularzem nie dowodzi braku pomocy, jeżeli właściwa sugestia jest dostępna w kontekście.

Wyjątek dotyczy sugestii, której przekazanie zagroziłoby bezpieczeństwu lub celowi treści. Przykładowo ujawnienie prawidłowego sekretu lub odpowiedzi w teście sprawdzającym wiedzę może niweczyć cel. Nie jest to zwolnienie całego formularza: bezpieczna instrukcja formatu przy innym polu nadal może być wymagana. Nie odtwarzano prawdziwego sekretu, uwierzytelniania lub testu egzaminacyjnego.

Identyfikacja, instrukcja i sugestia

Techniki i ich ograniczenia

Sprawdzono pełne Understanding z aktualizacją 2026-03-09, G177 2026-08-10, G84 i G85 2025-07-15. Są informacyjne; norma określa wynik, a techniki przykładowe sposoby jego osiągnięcia.

• G177: tekst sugerowanej korekty lub podobne wartości, ewentualnie bliski link do listy/sposób wyboru. Nie ustanawia obowiązku autoCorrect; zwykły tekst z wyborem użytkownika może wystarczyć. Bliskość i wygodny wybór są rozwiązaniem techniki, nie nowym bezwzględnym wymogiem geometrii 3.3.3.
• G85: pomoc dla formatu lub wartości — opis prawidłowego wpisu, przykład albo podobne poprawne wartości z instrukcją użycia. Procedura obejmuje także ponowne pokazanie innych wpisanych danych, poza polami bezpieczeństwa, których zachowanie byłoby nieodpowiednie. Nasze uwagi pozostają; nie badamy hasła. Ten element techniki nie tworzy osobnego bezwarunkowego nakazu zachowania wszystkich danych w tekście 3.3.3.
• G84: przy zamkniętej liście opis wyjaśnia ograniczenie i, gdy możliwe, przedstawia listę lub podobną dozwoloną wartość. Jej uproszczona procedura testowa sprawdza tylko tekstowy opis problemu. Sam PASS tej procedury nie potwierdza pełnego 3.3.3, jeżeli pominięto znaną pomoc.
• ARIA18: modalny alertdialog z dostępnym opisem błędu i znaną sugestią może realizować technikę; sam dialog bez pomocnej treści nie wystarcza. Tutaj użyto tekstu przy polu, bez modalu.
• PDF22: przykład walidacji formatu/wartości w formularzu PDF. Zależny od obsługi formularza i skryptów przez odbiornik; nie wykonano PDF. Nie przenosimy wyniku HTML lub iOS na dokument.
• G83, aktualizacja 2025-09-24, dotyczy pominiętych wymaganych pól: katalogowo 3.3.1, 3.3.2 w odpowiedniej kombinacji i 4.1.3 z ARIA19. Nie jest katalogową sufficient technique 3.3.3. Wymagane pominięcie pozostaje jednak błędem wejścia w normie 3.3.3.
• Understanding wymienia jako dodatkowe G139 (przejście do błędów), G199 (feedback sukcesu), SCR18 i SCR32. Tytuł strony z błędem, jump-to-error, modal i komunikat sukcesu nie są samodzielnymi obowiązkami 3.3.3. Sukces zachowano jako dowód rzeczywistej akceptacji, a nie warunek normatywny.

Understanding nie podaje osobnego katalogu numerowanych failures dla 3.3.3. Opisany wariant bad jest własnym odtworzeniem bariery, bez twierdzenia o częstości lub przypisywania mu identyfikatora błędu W3C. Katalog ACT 2026-10-04 wskazuje brak reguł dla 3.3.3. Proponowana reguła error-invalid-form-field / 36b590 opisuje 3.3.1: przyczynę lub sposób poprawy, widoczny tekst i dostępność w drzewie. Jej PASS nie dowodzi 3.3.3; nie wykonano formalnego ACT.

Platformy

Wszystkie wiersze: merytoryczny przegląd AI 2026-10-04; człowiek NOT-RUN. Podstawa poza WWW to informacyjna nota WCAG2ICT z 2025-12-11, obejmująca WCAG 2.2; nie jest osobną normą zgodności. Sekcja 3.3.3 stosuje wymaganie bez zmian.

Brak testu nie wyłącza platformy. Hybryda wymaga rozróżnienia części webowej i natywnej. Nie oceniono obowiązków prawnych ani mapowania do EN 301 549.

Rozwiązania w technologiach

We wszystkich rozwiązaniach walidacja powinna zwracać przyczynę oraz znaną bezpieczną pomoc. Kod pocztowy w przykładach ma uproszczony kontrakt NN-NNN; wzorzec nie ocenia adresu. Stan danych i sugestia są osobne, dzięki czemu walidacja nie kasuje innych bezpiecznych wpisów. Obsługę AT, relacje i sposób ogłoszenia bada się dodatkowo.

final value = code.text.trim();
error = value.isEmpty
    ? 'Kod pocztowy: brak wymaganej wartości.'
    : RegExp(r'^[0-9]{2}-[0-9]{3}$').hasMatch(value)
    ? ''
    : 'Kod pocztowy: niepoprawny format.';
if (error.isNotEmpty) {
  error += ' Wpisz dwie cyfry, łącznik i trzy cyfry, np. 00-001.';
}
// W setState; kod i note nie są nadpisywane przez walidację.
// CupertinoTextField(controller: code), Text(error) pod badanym polem.

import SwiftUI

struct DeliveryForm: View {
    @State private var code = ""
    @State private var note = ""
    @State private var error = ""
    var body: some View {
        VStack(alignment: .leading) {
            Text("Kod pocztowy (wymagany)")
            TextField("Kod pocztowy", text: $code)
            Text(error)
            Text("Uwagi (opcjonalnie)")
            TextField("Uwagi", text: $note)
            Button("Zapisz") {
                let value = code.trimmingCharacters(in: .whitespacesAndNewlines)
                let valid = value.range(of: #"^[0-9]{2}-[0-9]{3}$"#,
                                        options: .regularExpression) != nil
                error = valid ? "" : "Kod pocztowy: wpisz dwie cyfry, łącznik "
                    + "i trzy cyfry, np. 00-001."
                // Dopiero valid uruchamia właściwy zapis; code i note zostają.
            }
        }
    }
}

import androidx.compose.foundation.layout.Column
import androidx.compose.material3.Button
import androidx.compose.material3.Text
import androidx.compose.material3.TextField
import androidx.compose.runtime.*

@Composable
fun DeliveryForm() {
    var code by remember { mutableStateOf("") }
    var note by remember { mutableStateOf("") }
    var error by remember { mutableStateOf("") }
    Column {
        TextField(value = code, onValueChange = { code = it },
            label = { Text("Kod pocztowy (wymagany)") })
        Text(error)
        TextField(value = note, onValueChange = { note = it },
            label = { Text("Uwagi (opcjonalnie)") })
        Button(onClick = {
            val valid = Regex("^[0-9]{2}-[0-9]{3}$").matches(code.trim())
            error = if (valid) "" else
                "Kod pocztowy: wpisz dwie cyfry, łącznik i trzy cyfry, np. 00-001."
            // Właściwy zapis tylko przy valid; nie kasuj code ani note.
        }) { Text("Zapisz") }
    }
}

import React, { useState } from 'react';
import { Button, Text, TextInput, View } from 'react-native';

export function DeliveryForm() {
  const [code, setCode] = useState('');
  const [note, setNote] = useState('');
  const [error, setError] = useState('');
  return (
    <View>
      <Text>Kod pocztowy (wymagany)</Text>
      <TextInput
        accessibilityLabel="Kod pocztowy"
        value={code}
        onChangeText={setCode}
        autoCorrect={false}
      />
      <Text>{error}</Text>
      <Text>Uwagi (opcjonalnie)</Text>
      <TextInput
        accessibilityLabel="Uwagi"
        value={note}
        onChangeText={setNote}
      />
      <Button
        title="Zapisz"
        onPress={() => {
          const valid = /^[0-9]{2}-[0-9]{3}$/.test(code.trim());
          setError(
            valid
              ? ''
              : 'Kod pocztowy: wpisz dwie cyfry, łącznik i trzy cyfry, np. 00-001.',
          );
          // Właściwy zapis tylko przy valid; zachowaj pozostałe dane.
        }}
      />
    </View>
  );
}

<label for="code">Kod pocztowy</label>
<input id="code" required aria-describedby="instruction error" />
<p id="error" aria-live="polite"></p>

Jak sprawdzić

1. Ustal kontrakt, przyczynę odrzucenia, automatyczne wykrycie oraz znaną bezpieczną pomoc. Wyjątek uzasadnij dla konkretnej sugestii.
2. Wpisz Dwa kubki, pomiń kod i Zapisz: good ma opisać brak, podać format oraz zachować uwagi.
3. Wpisz 00001 i Zapisz w obu wariantach. Pole i natura błędu mają być wskazane w obu; znana pomoc pojawia się w good.
4. Zwykłą edycją wpisz 00-001, ponów zapis i potwierdź akceptację, zniknięcie błędu oraz zachowanie uwag. Samo pojawienie się tekstu nie dowodzi jego pomocności.
5. W control odrzuć P-999, odczytaj kontekst potwierdzenia, następnie wpisz posiadany P-104 i odczytaj wynik. Rozpoznany rekord nie jest automatycznie zamierzonym numerem.
6. Sprawdź cykl, reset i fallback. Zapisz rzeczywiste wejścia i stany; w pełnej ocenie osobno sprawdź dostępność oraz użyteczność pomocy z człowiekiem i odpowiednim AT.

Rzeczywiste wykonanie źródła

Wyniki pochodzą z 2026-10-04. Migracja 2026-10-12 nie jest nowym wykonaniem.

Xcode 27.0 (27A266a), SDK symulatora 27.0, iPhone 17 / iOS 26.5 Simulator: widok 402×874 pt, PNG 1206×2622 px. Odbiornik webowy Codex IAB/macOS: 1280×720 CSS px, DPR 1, JPEG 1280×720. Nie zmieniano ustawień OS. Build i instalacja odpowiadały źródłom przed/po; historyczne dowody zachowują własne hashe. Własne procesy i karta zakończyły się przed końcowymi hashami, bez resetu usług lub danych symulatora.

Weryfikacja i ograniczenia

Deterministyczny checker zna fixture i oczekiwane komunikaty. Potwierdza kompletność dowodów, nie rozstrzyga, czy każda sugestia realnego produktu jest znana, bezpieczna, poprawna i pomocna. Wynik bad odtwarza brak pomocy, a PASS harnessu oznacza prawidłowe odtworzenie pary, nie zgodność wariantu bad. Oczekiwane etykiety są w driverze/checkerze, poza surową obserwacją; nie podano ich niezależnemu badanemu walidatorowi, którego nie uruchamiano.

Screenshot pokazuje tekst, drzewo jego eksport oraz zwykłe interakcje działanie lokalnego formularza. Nie dowodzą odczytu AT, pełnego audytu, skuteczności dla osób z niepełnosprawnościami lub poprawności rzeczywistych adresów. Ocena AI jest interpretacją wymagającą przeglądu. Nieobecność błędu w automacie nie oznacza spełnienia kryterium. Przy braku kontekstu potrzebna jest dalsza ocena, a nie automatyczne PASS lub FAIL.

Jak sprawdza Clearship

Clearship ma deterministyczny form-errors-2 w P0. Dla komunikatu wskazującego pole z niepustą wartością szuka formatu, wzorca, przykładu, zakresu, liczby znaków lub listy wartości w słowniku polskim/angielskim. Brak rozpoznanej sugestii wskazuje jako usterkę, jeśli odpowiednia instrukcja nie była już dostępna przy polu. Wskazanie pominiętej wymaganej wartości traktuje jako wystarczającą pomoc tej gałęzi.

Pomiary kontrolne Androida z 8 października i iOS z 9 października 2026 r. dały 6/6 usterek i 0/36 fałszywych alarmów na każdej platformie; próg spełniony. To wąski test obecności sugestii, bez oceny czy jest znana, prawdziwa, bezpieczna i pomocna. Pełne znaczenie pozostaje oceną człowieka, zgodnie z katalogową metodą ręczną.

Możliwy wyjątek bezpieczeństwa/celu treści i błąd bez tekstu wskazującego pole idą do człowieka. Reguła opiera się na trzech rundach syntetycznych wartości P0 i widocznym wyniku po wysłaniu, nie obejmuje dowolnego kontraktu danych, sugestii spoza słownika, wszystkich kolorów błędu, dialogów/toastów, relacji programowych, czytnika ani treści webowej. Słowo hasło lub test na ekranie może skierować niepowiązany przypadek do człowieka.

Wynik „nie znaleziono w zbadanym zakresie” wymaga progu platformy i braku pominięć, a nie pustej listy po awarii lub brakującej obserwacji. Regresja edukacyjnej pary nie jest pomiarem tej metody. Wskazanie pola z 3.3.1, rozpoznany rekord lub samo słowo popraw nie potwierdzają pomocności sugestii.

Powiązane kryteria

• 3.3.1
  Identyfikacja błędu

  Identyfikacja pola i natury błędu nie zastępuje znanej sugestii.

• 3.3.2
  Etykiety lub instrukcje

  Wcześniej dostępna instrukcja może też dostarczyć właściwy kontekst korekty.

• 4.1.3
  Komunikaty o stanie

  Udostępnienie zmiany komunikatu bez zmiany fokusu ma osobny zakres.

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

  Ochrona przed skutkami przesłania jest innym zagadnieniem niż pomoc w poprawie.