Identyfikacja błędu

Co oznacza to kryterium

Jeśli system automatycznie wykryje błąd w danych użytkownika, wskaż element, którego dotyczy, i opisz problem tekstem. Sama czerwona ramka, ikona lub „Nie udało się” nie wyjaśnia odrzucenia. Opis może być przy polu, w podsumowaniu albo dialogu, jeżeli da się powiązać go z właściwymi danymi.

Przykłady błędów i poprawek

Własna fikcyjna Pracownia zapisuje adres do potwierdzenia zamówienia. W obu wariantach wpisano syntetyczne aleksandra; ta sama walidacja odrzuca format i nie potwierdza zapisu.

Problem: bad oznacza pole wyłącznie czerwoną ramką. Skutek: użytkownik nie otrzymuje tekstowej informacji, jakie dane są błędne i dlaczego. Poprawka: good dodaje „Adres e-mail: nieprawidłowy format. Wpisz np. ola@example.com.”, zachowując wpisaną wartość. Nazwa i opis realizują identyfikację; przykład jest osobną sugestią poprawy.

Brak wartości i poprawny zapis

Po usunięciu danych good wyświetla „Adres e-mail: brak wymaganej wartości.”. Etykieta „wymagany” sprzed próby nie zastępuje opisu wykrytego błędu. Test widgetu obejmuje pusty bad, lecz osobna natywna próba i obraz tej gałęzi są NOT-RUN.

Ogólne „Popraw dane” bez wskazania pól i problemów, sam symbol ostrzeżenia albo ciche ograniczenie wykrytej wartości wymagają oceny. Jedno dostępne podsumowanie nazywające pola i problemy może wystarczyć, bez komunikatu pod każdym polem.

Kiedy obowiązuje i gdzie są wyjątki

• Błąd danych obejmuje brak wymaganej wartości oraz wartość poza wymaganym formatem lub dozwolonym zakresem. Kryterium nie nakazuje wykrywania wszystkich możliwych pomyłek ani walidacji podczas każdego naciśnięcia klawisza.
• Wykrywanie może nastąpić lokalnie lub po odpowiedzi serwera. Odrzucenie formularza bez wyjaśnienia jest problemem niezależnie od miejsca walidacji.
• Samo automatyczne skorygowanie wykrytej wartości, np. obniżenie liczby do maksimum, nie usuwa potrzeby opisania błędu i zmiany użytkownikowi.
• Wymagane są identyfikacja elementu oraz tekstowy opis błędu. Nazwa pola może wynikać z jednoznacznego kontekstu, ale przy dwóch polach „Adres” trzeba rozróżnić np. adres dostawy i rozliczenia. Tekst oznacza znaki dostępne dla oprogramowania; obraz napisu nie jest równoważnym dowodem.
• Nie ma nakazu jednego konkretnego układu, przeniesienia fokusu ani użycia role=alert. Kolor i ikona mogą uzupełniać tekst. Dostępny opis tekstowy może też towarzyszyć oznaczeniu nietekstowemu.
• Awaria sieci, brak uprawnień lub błąd serwera nie są automatycznie błędem wpisanych danych. Nie nazywaj ich błędnym adresem, jeżeli przyczyna jest inna.

W 3.3.1 nie ma ogólnego wyjątku bezpieczeństwa pozwalającego pominąć identyfikację wykrytego błędu. Wyjątek dotyczący ujawniania sugestii należy do 3.3.3. Opis może chronić informacje wrażliwe, np. wskazać odrzucenie danych logowania bez ujawniania, czy konto istnieje; ten formularz nie testuje uwierzytelniania.

Granice innych kryteriów: 3.3.2 dotyczy etykiet i instrukcji przed wprowadzeniem danych; 3.3.3 — znanej sugestii poprawy; 1.4.1 — alternatywy dla koloru; 1.3.1, 4.1.2 i 4.1.3 mogą obejmować relacje, stany i powiadomienia. Tekstowe wskazanie błędu nie potwierdza spełnienia tych wymagań.

Platformy

Warunkiem jest automatyczne wykrycie błędu danych wprowadzanych przez użytkownika. W WCAG2ICT wymaganie stosuje się bez zmiany do dokumentów poza WWW i oprogramowania; oprogramowanie o zamkniętej funkcjonalności wymaga także rozpatrzenia sposobu udostępnienia tekstu.

Data przeglądu zastosowania: 2026-10-01, AI. Brak funkcji lub testu w jednym scenariuszu nie wyłącza platformy. WCAG2ICT jest wskazówką interpretacyjną, a tabela nie określa obowiązków prawnych ani wymagań całego sprzętu. W hybrydzie ocenia się osobno część webową i natywną.

Rozwiązania w technologiach

Poniższe fragmenty otrzymują wynik walidacji (message: brak błędu albo opis, np. „nieprawidłowy format”). Są kontrolkami do osadzenia w formularzu; logika zapisu ustawia wynik po faktycznym sprawdzeniu danych i nie potwierdza zapisu przy błędzie. Minimalne rozwiązanie to użycie tekstu i istniejącej kontrolki, bez osobnej biblioteki błędów.

import androidx.compose.material3.OutlinedTextField
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.semantics.error
import androidx.compose.ui.semantics.semantics

@Composable
fun EmailField(value: String, onChange: (String) -> Unit, message: String?) {
    OutlinedTextField(
        value = value, onValueChange = onChange,
        label = { Text("Adres e-mail (wymagany)") },
        isError = message != null,
        supportingText = { if (message != null) Text("Adres e-mail: $message") },
        modifier = Modifier.semantics {
            if (message != null) error("Adres e-mail: $message")
        },
    )
}

import SwiftUI

struct EmailField: View {
    @Binding var email: String
    let message: String?

    var body: some View {
        VStack(alignment: .leading) {
            Text("Adres e-mail (wymagany)")
            TextField("", text: $email)
                .accessibilityLabel("Adres e-mail (wymagany)")
            if let message {
                Text("Adres e-mail: \(message)")
            }
        }
    }
}

import 'package:flutter/material.dart';

Widget emailField(TextEditingController controller, String? message) => TextField(
  controller: controller,
  keyboardType: TextInputType.emailAddress,
  decoration: InputDecoration(
    labelText: 'Adres e-mail (wymagany)',
    errorText: message == null ? null : 'Adres e-mail: $message',
    errorMaxLines: 3,
  ),
);

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

export function EmailField({
  value,
  onChange,
  message,
}: {
  value: string;
  onChange: (value: string) => void;
  message: string | null;
}) {
  return (
    <View>
      <Text>Adres e-mail (wymagany)</Text>
      <TextInput
        value={value}
        onChangeText={onChange}
        accessibilityLabel="Adres e-mail (wymagany)"
        keyboardType="email-address"
      />
      {message !== null && (
        <Text accessibilityLiveRegion="polite">
          {`Adres e-mail: ${message}`}
        </Text>
      )}
    </View>
  );
}

Jak sprawdzić

1. Ustal, które wartości są wymagane lub ograniczone i kiedy system wykrywa problem. Odnotuj odpowiedź serwera, jeśli walidacja odbywa się po jego stronie.
2. Zapisz stan przed walidacją. Wprowadź błędny format albo pomiń wymaganą wartość i wykonaj akcję, która naprawdę uruchamia sprawdzenie.
3. Odczytaj wynik: czy da się wskazać element i zrozumieć wykryty problem z tekstu lub dostępnej alternatywy tekstowej? Sam kolor, ikona lub zatrzymanie procesu nie wystarcza.
4. Przy powiększeniu oraz z czytnikiem sprawdź dostępność opisu, relację z polem i możliwość jego odnalezienia. Oddziel obecność w drzewie od rzeczywistej wypowiedzi czytnika.
5. Popraw wartość i ponów zapis; potwierdź, że opis nie dotyczy już poprawionych danych. Zapisz zakres obserwacji i nie rozszerzaj wyniku na inne pola lub aplikację.

Rzeczywiste wykonanie źródła

Działający formularz /3-3-1/form/good lub /3-3-1/form/bad sprawdzono przez rzeczywiste tap i wpisy XCTest 2026-10-01. Parametr początkowego błędu nie był wejściem tej próby. Redakcja 2026-10-12 nie ponawia wykonania.

Weryfikacja i ograniczenia

Nie zgłaszaj błędu tylko dlatego, że screenshot nie zawiera komunikatu: mogło nie dojść do wykrycia błędu, dane mogły zostać zaakceptowane albo komunikat jest w dostępnym podsumowaniu. Nie wymagaj komunikatu przy każdym polu, konkretnego komponentu lub sugestii jako jedynej metody spełnienia 3.3.1. Sama flaga błędu bez tekstowego opisu nie wystarcza.

Sprawdzono także proponowaną regułę ACT dotyczącą opisów błędnych wartości pól HTML. Ma status proposed, ograniczony zakres webowy i nie zastępuje wymagania ani testu całego procesu. W szczególności wynik pozytywny lub brak zastosowania reguły nie dowodzi spełnienia całego 3.3.1.

Oczekiwane etykiety wariantów są w tym wpisie i kodzie testu, poza wejściem badanego walidatora. Do jego wejścia nie przekazywać trasy good/bad, kodu sterującego usterką ani metadanych z oczekiwaniami. Tu nie uruchomiono walidatora Clearship ani benchmarku jego skuteczności. Brak danych i niewykrycie błędu oznaczają niepewność, nie spełnienie wymagania.

Jak sprawdza Clearship

Clearship ma deterministyczny form-errors-2 w P0: porównuje segment formularza i stan po wysłaniu ze stanem przed wpisaniem. Wskazuje pole oznaczone czerwoną barwą błędu albo błędem platformy bez identyfikującego tekstu oraz ogólny komunikat bez wskazania pola. Identyfikację przybliża nazwą pola, błędem platformy Androida albo nieogólnym tekstem bezpośrednio pod polem. Na iOS rozpoznaje pola także po roli XCUITest, gdy brak stanu edycji.

Pomiar kontrolny Androida z 8 października 2026 r.: 16/16 usterek i 0/42 fałszywych alarmów, próg spełniony. iOS z 9 października: 14/16 i 0/42, poniżej progu; wynik iOS wymaga człowieka. To pomiary metody na zestawie kontrolnym, odrębne od edukacyjnej demonstracji.

Reguła nie ocenia prawdziwości i zrozumiałości opisu, relacji programowej ani odbioru AT. Obejmuje trzy rundy syntetycznych wpisów P0 i pierwszy przycisk po polach; wartości nie są błędne lub poprawne dla każdego kontraktu. Inne reguły danych, języki poza polskim/angielskim, dialogi, toasty, inne kolory błędu, motyw ciemny i treść webowa pozostają poza oceną lub idą do człowieka.

Pole bez wysłania, brak wyniku/obserwacji po akcji i pole poza obrazem dają incomplete. „Nie znaleziono w zbadanym zakresie” wymaga progu platformy oraz braku pominięć, i dotyczy wywołanych błędów. Pusta lista po awarii lub brak danych nie potwierdzają kryterium; obecność tekstu nie jest wykonaną mową czytnika. Katalog nadal wymaga oceny człowieka pełnego znaczenia komunikatu.

Powiązane kryteria

• 3.3.2
  Etykiety lub instrukcje

  Etykiety i instrukcje objaśniają dane przed wpisaniem.

• 3.3.3
  Sugestie korekty błędów

  Znana pomoc w korekcie jest odrębnym wymaganiem od identyfikacji błędu.

• 1.4.1
  Użycie koloru

  Kolor błędu potrzebuje właściwej alternatywy.

• 1.3.1
  Informacje i relacje

  Programowa relacja opisu z polem wymaga osobnej oceny.

• 4.1.2
  Nazwa, rola, wartość

  Nazwa, rola i stan pola nie wynikają z samego tekstu błędu.

• 4.1.3
  Komunikaty o stanie

  Powiadomienie o zmianie stanu bez zmiany fokusu ma osobny zakres.