Komunikaty o stanie

Co oznacza to kryterium

Wynik działania może pojawić się obok pola bez przeniesienia użytkownika do tego tekstu. Jeśli jest komunikatem o stanie w treści zapisanej w znacznikach, udostępnij jego pełne znaczenie przez rolę lub właściwości, aby technologia asystująca mogła je przedstawić bez nadawania fokusu. Widoczność komunikatu i możliwość późniejszego znalezienia go w drzewie nie potwierdzają powiadomienia o zmianie.

Tagi z design systemu służą prezentacji, nie wyznaczają zamkniętej listy odbiorców.

Przykłady błędów i poprawek

Pracownia wyszukuje syntetyczne produkty. Po notes i Szukaj/Enter pokazuje Notes lniany oraz Notes w kropki, z „Wyszukiwanie: 2 wyniki.”. Po zastąpieniu zapytania przez zzz pokazuje brak wyników. Nie ma serwera, zakupów ani kont.

Problem: bad ma tę samą funkcję, tekst i wyniki, lecz bez liveRegion lub ARIA status. Skutek przewidywany: informacja o zmianie może pozostać niezauważona przez AT. Poprawka: good zachowuje istniejący węzeł statusu i pełny kontekst, bez zabierania fokusu pola. Potwierdzono różnicę właściwości, a nie mowę lub ciszę VoiceOver i nie pełny FAIL F103.

Kontrola zmiany kontekstu

Control po tym samym wyszukaniu otwiera dialog, przenosi fokus wejścia do Zamknij i przywraca go po zamknięciu. To zmiana kontekstu poza definicją statusu; nie rekomendacja zastępowania każdego powiadomienia modalem.

Dodatkowe scenariusze są NOT-RUN: koniec oczekiwania po zniknięciu spinnera, etapowy postęp, pilny lub powtórzony błąd po submit i dopisywany log. Dobierz status końca pracy, właściwe okresowe powiadomienia, istniejący region błędu albo log nowych wpisów. Cykl, reset i fallback odtwarzają fixture, bez potwierdzenia AT.

Kiedy obowiązuje i gdzie są wyjątki

Status jest zmianą treści, która informuje o powodzeniu lub wyniku działania, oczekiwaniu, postępie procesu albo istnieniu błędu, bez zmiany kontekstu. Lista znalezionych produktów sama nie jest statusem; jej liczba i informacja o braku wyników są statusami. Wymaganie nie nakazuje autorowi tworzenia nowego komunikatu, którego nie udostępnia. Obejmuje także modyfikację istniejącego tekstu, informujące usunięcie „Trwa praca”, ikonę lub dźwięk statusu; alternatywa musi przekazać równoważne znaczenie i zakończenie oczekiwania.

Dialog przejmujący fokus jest zmianą kontekstu. Rozwinięcie sekcji, ujawnienie menu, wybór zakładki oraz stan kontrolki mają inny zakres; nie należy dopisywać live region do każdego takiego zdarzenia. Ich nazwa, rola, wartość i dostępność zmiany stanu należą m.in. do 4.1.2. Dodanie pytań formularza również nie staje się statusem tylko dlatego, że jest dynamiczne.

Nie każdy status wymaga role="status" i nie każdy komunikat wymaga assertive. Dobierz mechanizm do znaczenia i pilności. Dla liczby w koszyku przekazuj pełne „Koszyk: 3 produkty”, gdy samo „3” pozbawiłoby użytkownika kontekstu. Ustawienia, opóźnienie, kolejka lub decyzja AT o niewypowiadaniu komunikatu nie są automatycznie błędem autora; badaj wsparcie mechanizmu, jego właściwe użycie i doświadczenie odbiorcy.

Techniki i granice ich procedur

Techniki W3C są pomocniczymi sposobami spełnienia wymagania, nie dodatkową normą ani obowiązkiem zastosowania wszystkich przykładów.

Platformy

Weryfikacja podstaw: AI 2026-10-04. WCAG jest podstawą dla WWW; WCAG2ICT 2.2 z 2025-12-11 jest informacyjną interpretacją, nie normą nakładającą obowiązek prawny. EN 301 549 nie jest podstawą tej karty; nie przenosimy tu jej klauzul ani wyłączeń.

Rozwiązania w technologiach

Dokumentacja oficjalnych API sprawdzona 2026-10-04. Wszystkie fragmenty są własnymi przykładami edukacyjnymi. Budowa Fluttera nie potwierdza SwiftUI, Compose lub React Native. Mechanizm zawsze należy sprawdzić w docelowym zestawie OS/AT; nie dublować automatycznego live region z dodatkowym announcement tej samej wiadomości.

import 'package:flutter/cupertino.dart';
// W istniejącym State: message aktualizuje zwykła akcja wyszukiwania.
Semantics(
  container: true,
  excludeSemantics: true,
  label: message, // pełne „Wyszukiwanie: 2 wyniki.”
  liveRegion: true,
  child: Text(message),
)

import SwiftUI
import Accessibility

@available(iOS 17.0, *)
struct SearchStatus: View {
    @State private var message = "Wyszukiwanie: gotowe."
    var body: some View {
        VStack {
            Button("Szukaj") {
                message = "Wyszukiwanie: 2 wyniki."
                AccessibilityNotification.Announcement(message).post()
            }
            Text(message)
        }
    }
}

import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.semantics.LiveRegionMode
import androidx.compose.ui.semantics.liveRegion
import androidx.compose.ui.semantics.semantics

@Composable
fun SearchStatus(message: String) {
    Text(message, Modifier.semantics {
        liveRegion = LiveRegionMode.Polite
    })
}

import React, { useEffect, useRef } from 'react';
import { AccessibilityInfo, Platform, Text } from 'react-native';

export function SearchStatus({ message }: { message: string }) {
  const previous = useRef(message);
  useEffect(() => {
    if (previous.current !== message && Platform.OS === 'ios') {
      AccessibilityInfo.announceForAccessibilityWithOptions(message, {
        queue: true,
      });
    }
    previous.current = message;
  }, [message]);
  return (
    <Text
      accessibilityLiveRegion={Platform.OS === 'android' ? 'polite' : undefined}
    >
      {message}
    </Text>
  );
}

<form id="search-form">
  <label for="query">Nazwa produktu</label><input id="query" />
  <button>Szukaj</button>
</form>
<p id="status" role="status" aria-atomic="true">Wyszukiwanie: gotowe.</p>
<script>
  const form = document.getElementById('search-form');
  form.addEventListener('submit', (event) => {
    event.preventDefault();
    // Tutaj wynik normalnej funkcji; nie dodawaj roli dopiero po zmianie.
    document.getElementById('status').textContent = 'Wyszukiwanie: 2 wyniki.';
  });
</script>

Jak sprawdzić

1. Ustal, czy zmiana spełnia definicję statusu; zanotuj kontekst i dane przed akcją. Oddziel listę wyników, stan kontrolki i dialog.
2. Sprawdź obecność mechanizmu przed aktualizacją: stały region, rola/właściwość lub właściwe API. Odczytaj cały komunikat i kontekst.
3. Wpisz notes, naciśnij klawisz Szukaj/Enter i zapisz zmianę statusu oraz faktyczny fokus przed/po. Zastąp zapytanie zzz, ponów działanie. Good/bad mają tę samą funkcję.
4. Uruchom kontrolę: po wyszukaniu dialog przejmuje fokus, zamknięcie go przywraca. Sprawdź cykl, reset i fallback.
5. Plan AT, NOT-RUN: użyj rzeczywistego VoiceOver/czytnika WWW; sprawdź ogłoszenie pełnego wyniku bez ręcznego szukania komunikatu, brak niepotrzebnego przerwania, brak wyników i powtórzenie po kolejnej akcji. Zapisz kolejkę, preferencje AT, OS/przeglądarkę, rzeczywiste wypowiedzi i rezultat. Wynik odróżnij od samej właściwości i zdarzenia API.

Rzeczywiste wykonanie źródła

Wyniki z 2026-10-04, bez ponowienia badań w migracji.

Środowisko: iPhone 17 / iOS 26.5 Simulator, Xcode 27.0 / SDK 27.0, 402×874 pt i PNG 1206×2622. Odczyt light/content size large, bez zmiany OS. Kadry i odczyty są sekwencyjne. Właściwość renderera, natywny label, zdarzenie powiadomienia platformy i odsłuch są osobnymi dowodami; dwóch ostatnich nie zebrano.

Zachowana historia nieudanych prób

• Pierwsza analiza FAIL: zbędny import i focusNode/autofocus nieobsługiwane przez CupertinoDialogAction; przed buildem poprawiono przez Focus wokół akcji.
• Driver v1 FAIL kompilacji: XCUIElementType zmieniono na XCUIElement.ElementType; install/runtime v1 NOT-RUN.
• Runtime iOS v2 FAIL: 94,123 s / 102,317 s orkiestracji, zachowane 25 STATE/TREE, 13 INPUT i 11 PNG. Observer z tła był niedostępny po modalu, choć komunikat istniał. Ten sam pasywny observer przeniesiono także do dialogu przed v3. Osobne historyczne SHA i manifests zachowano; pełnej historycznej kopii Dart nie zapisano.
• Przygotowanie z błędnego cwd FAIL; poprawiono z root. Późniejszy formatter exit 1: surowy log i dokładny powód NOT-RECORDED, bo log nadpisano kolejnym formatowaniem. Nie oznaczono tej próby PASS lub NOT-RUN.

Weryfikacja i ograniczenia

Drzewo i renderer pokazują właściwości, odczyty fokusu oraz zwykłe działania potwierdzają funkcję. Nie dowodzą zdarzenia powiadomienia platformy lub wypowiedzi czytnika. AI kwalifikuje zmianę jako status z kontekstu; statyczny screenshot nie pokazuje semantyki. Checker zna własną fixture, nie jest zaślepiony ani niezależnym audytem. Brak danych lub znalezisk nie oznacza zgodności.

Jak sprawdza Clearship

Deterministyczny status-messages-1 analizuje P0: nowe teksty po wysłaniu formularza lub dotknięciu, zmianę kontekstu i fokus. Status rozpoznaje po zmianie tekstu tego samego węzła albo słowniku wyniku, postępu i błędu. Na Androidzie szuka w oknie akcji zdarzeń live-region, announcement, error lub pane. Wskazuje rozpoznany status bez fokusu i zdarzenia, gdy kanał jest obsługiwany i nie utracił zdarzeń.

Kontrolny Android z 8 października 2026 r.: 6/6 usterek, 0/20 fałszywych alarmów, próg spełniony. Wynik „nie znaleziono w zbadanym zakresie” dotyczy wyłącznie osiągniętych akcji bez pominięć. Na iOS zdarzenia są unsupported, więc statusy idą do człowieka: zestaw rozwojowy z 9 października 0/6 i 0/20; kontrolny NOT-RUN, katalog not-measured.

Zdarzenie nie wskazuje węzła i może należeć do innego regionu w tym samym oknie. Metoda nie ocenia czytnika, kolejki, pilności, powtórzeń, statusów po czasie lub wpisywaniu, Toast poza drzewem ani treści webowej. Nieklasyfikowana zmiana, brak obserwacji i utracone zdarzenia wymagają człowieka. Ani zdarzenie Androida, ani liveRegion z edukacyjnej fixture nie potwierdzają wypowiedzi VoiceOver/TalkBack.

Powiązane kryteria

• 3.3.1
  Identyfikacja błędu

  Treść i wskazanie błędu są osobnym warunkiem niż dynamiczne przekazanie.

• 4.1.2
  Nazwa, rola, wartość

  Nazwy, role i wartości kontrolek mają inny zakres niż status bez fokusu.