Etykiety lub instrukcje

Co oznacza to kryterium

Gdy użytkownik wprowadza lub wybiera dane, zapewnij etykiety lub instrukcje pozwalające rozpoznać oczekiwane dane. Przy szczególnym formacie pokaż regułę albo przykład w chwili użycia; wymagane pola rozpoznawalnie oznacz. Pole swobodnych uwag może potrzebować tylko informacji o przeznaczeniu.

Przykłady błędów i poprawek

Własna Pracownia zapisuje lokalnie kod odbioru syntetycznego P-104, bez kont, sieci lub backendu. Pole jest początkowo puste. Akceptuje dokładnie dwie wielkie litery ASCII A–Z i cztery cyfry, bez spacji, np. AB1042.

Problem: bad usuwa widoczny blok etykiety i instrukcji, choć zachowuje natywną nazwę, hint, walidację oraz zapis. Skutek: osoba bez odczytu drzewa widzi nieobjaśnione puste pole. Poprawka: pokazać ten sam cel, obowiązkowość i format przed wpisaniem, a następnie zachować informację podczas edycji.

Wariant format ma odczyty, bez osobnego PNG. Komunikat dopiero po odrzuceniu jest pomocą po fakcie i nie naprawia początkowego braku szczególnej instrukcji. Good/bad mają ten sam kontrakt; control celowo zmienia przeznaczenie i regułę.

Kiedy obowiązuje i gdzie są wyjątki

Etykieta identyfikuje kontrolkę i jest przedstawiona użytkownikom; może być tekstem lub innym komponentem z alternatywą tekstową. Nie oznacza wyłącznie elementu HTML label. Dostępna nazwa jest identyfikatorem przedstawianym przez oprogramowanie i może istnieć tylko w drzewie dostępności. Sama aria-label, accessibilityLabel lub Semantics.label nie dostarcza widocznej informacji osobie bez technologii asystującej.

Wymaganie obejmuje pola wymagane i opcjonalne, pola tekstu, wybory, checkboxy i przyciski radiowe związane z danymi. Każda opcja musi pozwalać rozpoznać wybór. „Wymaga wprowadzenia” nie oznacza wyłącznie technicznego required. Przy grupach potrzebna może być informacja wspólna i opis poszczególnych części, np. daty; nie wystarczy dowolny napis gdziekolwiek na ekranie.

Nie ma tu listy wyjątków bezpieczeństwa czy niezbędności. Warunek zastosowania to wprowadzanie danych; sam link albo przycisk rozwijający panel nie jest takim wejściem. Konwencjonalny symbol wyszukiwania może być widoczną etykietą, jeśli jest zrozumiały w kontekście i ma właściwą alternatywę; brak osobnego napisu nie zawsze jest błędem. Ta demonstracja używa tekstu, bez testowania symbolu.

„Etykiety lub instrukcje” nie nakazuje obu przy każdym polu ani zawsze osobnej linii opisu. Szczególne ograniczenia formatu trzeba zakomunikować odpowiednią informacją; dłuższa instrukcja może być ujawniana przy fokusie, jeśli dostępna w chwili użycia. Zawsze widoczny opis jest przyjętą tu prostą implementacją, bez nakazu jednego układu. Placeholder znikający po wpisaniu jest słabym samodzielnym rozwiązaniem; jego ocena wymaga sprawdzenia innych wskazówek i stanów, nie mechanicznego zakazu każdego placeholdera.

Granice: 1.3.1 obejmuje programowe relacje, 4.1.2 nazwę/rolę/wartość, 2.4.6 jakość opisowości etykiet. Samo 3.3.2 nie nakazuje konkretnego znacznika ani powiązania AX. 3.3.1 opisuje automatycznie wykryty błąd, a 3.3.3 znaną sugestię poprawy. Komunikat dopiero po odrzuceniu nie zastępuje informacji przed wpisaniem szczególnego formatu. 2.5.3 obejmuje obecność widocznej etykiety w nazwie. Test tego formularza nie potwierdza tych innych kryteriów.

Techniki i udokumentowany błąd

Przejrzano G131 (opis etykiet), G89 (format lub przykład), G184 (instrukcje przed grupą pól), G162 (przewidywalne położenie) i H90 (wymagane pola, objaśnienie symbolu). H44 wiąże widoczną etykietę HTML z polem, ARIA1 opis z kontrolką, ARIA9 łączy istniejący tekst, ARIA17 opisuje grupę; techniki PDF5/PDF10 dotyczą oznaczeń obowiązkowości i etykiet formularza PDF. Te sposoby mogą wykraczać poza minimum 3.3.2; nie trzeba stosować wszystkich ani używać ARIA w natywnym Flutterze.

F82 jest udokumentowanym błędem zestawu pól telefonu rozpoznawalnego tylko po nawiasach, separatorach i długości, bez widocznej etykiety lub instrukcji grupy. Nie odtwarzamy tu F82 i nie rozciągamy go na każdy podział pól. Opisane warianty formularza są odtworzeniem zasad etykiet i instrukcji, nie oficjalnym katalogiem częstości błędów.

Platformy

Ocena zastosowania: AI, 2026-10-04; człowiek NOT-RUN. WCAG2ICT 2.2, Group Note 2025-12-11, stosuje 3.3.2 bez zmiany wymagania do dokumentów i oprogramowania poza środowiskiem webowym. Jest wskazówką interpretacyjną, bez własnych normatywnych wymagań zgodności. Nie mapujemy tu EN 301 549 ani prawa.

Nie dotyczy badanego elementu: przycisk otwierający pomoc lub link nawigacyjny, gdy nie uczestniczy we wprowadzaniu danych. Brak testu platformy nie jest wyłączeniem wymagania.

Rozwiązania w technologiach

Każdy przykład dodaje informację widoczną dla użytkownika; nazwa AX i hint uzupełniają ją. Fragmenty pokazują warstwę wejścia, bez całego zapisu/walidacji. W produkcie instrukcja musi zgadzać się z faktycznymi regułami serwera. Wersje podano tylko dla wykonanego Fluttera.

import 'package:flutter/cupertino.dart';

Widget pickupInput(TextEditingController controller) {
  const label = 'Kod odbioru (wymagane)';
  const hint = 'Dwie wielkie litery A–Z i cztery cyfry, bez spacji. Przykład: AB1042.';
  return Column(crossAxisAlignment: CrossAxisAlignment.start, children: [
    const Text(label),
    const Text(hint),
    Semantics(label: label, hint: hint,
      child: CupertinoTextField(controller: controller)),
  ]);
}

import SwiftUI

struct PickupInput: View {
    @State private var code = ""
    private let label = "Kod odbioru (wymagane)"
    private let hint = "Dwie wielkie litery A–Z i cztery cyfry, bez spacji. Przykład: AB1042."
    var body: some View {
        VStack(alignment: .leading) {
            Text(label)
            Text(hint)
            TextField(label, text: $code)
                .textFieldStyle(.roundedBorder)
                .accessibilityLabel(label)
                .accessibilityHint(hint)
        }
    }
}

import androidx.compose.material3.OutlinedTextField
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

@Composable
fun PickupInput() {
    var code by remember { mutableStateOf("") }
    OutlinedTextField(
        value = code,
        onValueChange = { code = it },
        label = { Text("Kod odbioru (wymagane)") },
        supportingText = {
            Text("Dwie wielkie litery A–Z i cztery cyfry, bez spacji. Przykład: AB1042.")
        },
        singleLine = true
    )
}

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

export function PickupInput() {
  const [code, setCode] = useState('');
  const label = 'Kod odbioru (wymagane)';
  const hint =
    'Dwie wielkie litery A–Z i cztery cyfry, bez spacji. Przykład: AB1042.';
  return (
    <View>
      <Text>{label}</Text>
      <Text>{hint}</Text>
      <TextInput
        value={code}
        onChangeText={setCode}
        accessibilityLabel={label}
        accessibilityHint={hint}
      />
    </View>
  );
}

Brak buildów pozostałych frameworków jest jawnym zakresem edukacyjnym zgodnym z procesem, bez zlecania dodatkowych demonstracji. Przegląd dokumentacji nie potwierdza działania ani odczytu AT.

Jak sprawdzić

1. Ustal przyjmowane dane, opcje i rzeczywiste ograniczenia, także opcjonalnych pól i grup.
2. Przed wejściem oceń widoczną etykietę lub instrukcję, obowiązkowość i szczególny format. Sama nazwa z drzewa nie wystarcza.
3. Wpisz wartość i sprawdź dostęp do informacji podczas oraz po edycji. Instrukcję ujawnianą przy fokusie rzeczywiście otwórz w odpowiednim momencie.
4. W good i bad wpisz AB1042, zapisz i zresetuj. Oba mogą zapisać dane; tylko good pokazuje widoczny blok. Tożsamy sukces nie naprawia bad.
5. Sprawdź format i control: brak widocznej reguły ograniczonego kodu różni się od swobodnych uwag bez reguły. Powiązania programowe i opisowość sprawdź pod właściwymi kryteriami.

Historia wykonania 2026-10-04

Pierwsza próba nie dostarczyła odczytów formularza ani obrazów: runner zgłosił start, lecz XCTest nie rozpoczął testu; screenshot i zwykły restart urządzenia utknęły. Przerwane wykonanie nie jest FAIL 3.3.2. Opóźnione zakończenie urządzenia oraz boot czekający na System App pozostają obserwacjami, bez ustalonej przyczyny awarii lub przypisania jej sandboxowi.

Ponowienie: rzeczywisty formularz

Po potwierdzeniu gotowości urządzenia 2026-10-04 zbudowano świeży Runner i własny driver z bieżących źródeł. Nie użyto starszego buildu. Nie zmieniano kodu formularza ani drivera i nie powtarzano wcześniejszych analiz/testów hostowych. Nie naprawiano wspólnych usług ani nie restartowano hosta; historyczna przeszkoda została zamknięta jako nieaktualna, bez przyjęcia zgody na takie działania.

Flutter 3.44.9 / Dart 3.12.2, Xcode 27.0 (27A266a), iPhone 17 / iOS 26.5 Simulator, jasny wygląd, systemowy tekst large; widok 402×874 pt, PNG 1206×2622 px. Stan z wartością zarejestrowano po Return zamykającym klawiaturę; brak kadru podczas otwartej klawiatury. StaticText i hittability uzupełniają kadr, lecz AX nie jest uniwersalnym dowodem widoczności. PASS testu oznacza odtworzenie znanej demonstracji, w której bad nadal pokazuje barierę.

Weryfikacja i ograniczenia

Reguła deterministyczna może sprawdzić obecność widocznego tekstu, deklarowane ograniczenie wejścia i eksport relacji, lecz samo znalezienie napisu albo label nie ustala, czy wyjaśnia właściwe dane. Drzewo jest przybliżeniem: może zawierać tekst ukryty wizualnie, tak jak bad; z kolei widoczna instrukcja poza nazwą pola nie musi być błędem. OCR nie identyfikuje pewnie relacji, obowiązkowości ani reguł walidacji. Brak instrukcji przy dowolnym polu nie daje automatycznie FAIL, zwłaszcza przy swobodnym tekście.

AI może zestawić widoczną treść ze schematem wejścia i wskazać hipotezę braku informacji, ale nie wolno uznać jej za test człowieka. Weryfikacja człowieka obejmuje rozpoznawalność wskazówek, spójność reguł i moment ich podania. Usterki opisowości i relacji należy klasyfikować pod właściwym kryterium, bez mieszania z 3.3.2.

Obecna próba jest kontrolą własnej znanej fixture, bez uruchomionego walidatora i bez zaślepionej oceny skuteczności. Trasy, stopka wariantu, identyfikatory, nazwy plików i oczekiwania ujawniają wariant; trzeba wyłączyć je z wejścia badanego walidatora. Nie wyciągaj wniosku o zgodności z samego sukcesu zapisu albo braku alarmu.

Jak sprawdza Clearship

Clearship ma deterministyczny labels-input-change-1 w P0. Porównuje nazwę/podpowiedź pustego pola ze stanem po wpisaniu, szuka trwałej widocznej etykiety nad polem, po lewej albo pozostającej w polu. Druga reguła odczytuje znaki szczególnego formatu z komunikatu odrzucenia niepustej wartości i porównuje je z tekstem dostępnym przed wpisaniem.

Pomiary kontrolne Androida z 8 października i iOS z 9 października 2026 r. dały 8/10 usterek i 0/22 fałszywych alarmów na każdej platformie: oba poniżej progu, wynik wymaga człowieka. Ogólna ocena obrazu AI może wskazać kandydata braku etykiety, lecz nie jest pełnym testem instrukcji ani wynikiem progu tego kryterium.

Nazwa tylko programowa bez widocznej etykiety i podpowiedzi, brak stanu po wpisaniu oraz odrzucenie bez rozpoznanych znaków formatu idą do człowieka. Reguła formatu wymaga obecności co najmniej połowy znaków we wcześniejszym tekście; podobna liczba w niezwiązanym akapicie może ukryć brak instrukcji. Grupy opcji, instrukcje odsłaniane przy fokusie, ograniczenia niewywołane trzema rundami P0, relacje programowe, opisowość etykiet i treść webowa nie są ocenione.

Brak obserwacji i pusta lista znalezisk nie dają wyniku „nie znaleźliśmy problemów”. Człowiek ocenia znaczenie wskazówki i rzeczywiste reguły; pojedynczy placeholder wymaga kontekstu, a swobodny tekst nie potrzebuje zbędnej instrukcji. Wynik edukacyjnej fixture nie jest pomiarem metody produktu.

Powiązane kryteria

• 3.3.1
  Identyfikacja błędu

  Opis wykrytego błędu jest informacją po walidacji.

• 3.3.3
  Sugestie korekty błędów

  Znana sugestia korekty różni się od informacji przed wejściem.

• 1.3.1
  Informacje i relacje

  Programowe relacje etykiety, grupy i instrukcji wymagają osobnej oceny.

• 4.1.2
  Nazwa, rola, wartość

  Sama nazwa, rola i wartość nie zapewniają widocznej instrukcji.

• 2.4.6
  Nagłówki i etykiety

  Opisowość etykiety jest osobnym wymaganiem.

• 2.5.3
  Etykieta w nazwie

  Widoczna etykieta ma właściwą relację do nazwy dostępnej.