Po otrzymaniu fokusu

Co oznacza to kryterium

Przejście fokusem na pole lub przycisk pozwala rozpoznać jego działanie przed uruchomieniem. Sam fokus nie może wysłać formularza, otworzyć okna ani przenieść użytkownika do innego widoku. Taki skutek powinien wynikać z osobnej aktywacji. Lokalna podpowiedź może pojawić się przy fokusie, jeśli zachowuje kontekst zadania.

Nie dodajemy automatycznie słuchu ani rozróżniania barw; nie są warunkiem tych scenariuszy. Kategorie są redakcyjnymi tagami potrzeb, nie diagnozami ani oficjalną klasyfikacją WCAG.

Przykłady błędów i poprawek

Własna demonstracja Pracowni pokazuje odbiór syntetycznego P-104 przy ul. Ogrodowej 8, piątek 10:00–18:00. Good i bad mają identyczne dane, kontrolki i funkcje. Bad dodatkowo wywołuje tę samą funkcję w CupertinoButton.onFocusChange przy true; good uruchamia ją tylko z onPressed.

Problem: zwykły Tab otwiera modal pomocy albo wymienia formularz na podsumowanie, zanim użytkownik aktywuje przycisk. Skutek: użytkownik traci miejsce pracy podczas poznawania dostępnych akcji. Poprawka: usuń otwieranie widoku z handlera fokusu i zachowaj je w aktywacji. Nie usuwaj samej funkcji ani widocznego wskaźnika fokusu.

W adaptacji mobilnej pomoc uruchamia przycisk, a nie pole numeru ze starszej wersji webowej. Tab rozdziela fokus od aktywacji bez otwierania klawiatury ekranowej. Oba przyciski istnieją w obu scenariuszach; w good oba działania zbadano w jednym przebiegu help/good. Kadry review-good-* przedstawiają funkcję podsumowania na rzeczywistej trasie help/good, nie oddzielne przechwycenie review/good. Test widgetu obejmował również review/good. Bad wykonano oddzielnie dla help i review.

Space na good otwiera identyczny modal, a Space na „Zamknij pomoc” wraca do inicjatora. Oba warianty pomijają ponowne samoczynne otwarcie przy jednym powrocie z modalu; nie usuwa to początkowego błędu bad. Escape działał w teście widgetu, lecz nie dotarł do Fluttera w XCTest; nie potwierdzono go na iOS.

„Wróć do formularza” odtwarza widok; reset przywraca początkowy scenariusz i wariant. To podgląd offline, bez wysłania zamówienia. Oczekiwania pozostają w testach, poza obserwatorem; wariant jest jawny i nie jest zaślepionym wejściem walidatora.

Historyczny przykład WWW

We wcześniejszej próbie 2026-10-03 Tab na pole numeru w help/bad otwierał modal, a trzy Tab na przycisk w review/bad wymieniały widok przy stałym adresie. Ta sama funkcja pozostawała dostępna przez aktywację przycisku w good. Control pokazywał podpowiedź w zarezerwowanym miejscu. Blur wykonywał DOM blur() i pozostawiał aktywny BODY. To wcześniejsze wykonanie desktopowego HTML, a nie wynik native iOS.

Kiedy obowiązuje i gdzie są wyjątki

• Wymaganie normatywne: każdy komponent, który otrzymuje fokus, nie inicjuje zmiany kontekstu. W 3.2.1 nie ma wyjątku „użytkownik został wcześniej ostrzeżony” ani wyjątku „niezbędne”. Uprzedzenie nie legalizuje nawigacji wyzwalanej samym fokusem.
• Zmiana kontekstu: duża zmiana mogąca dezorientować osobę niewidzącą całej strony naraz. Obejmuje zmianę odbiornika, obszaru widoku, fokusu lub treści zmieniającej znaczenie strony. Nowe okno, przeniesienie fokusu do innego komponentu, nowa strona lub pozornie nowa strona oraz istotne przeorganizowanie treści są przykładami.
• Nie oceniaj tylko adresu: pełna wymiana formularza na podsumowanie w SPA może zmienić kontekst przy tym samym URL. Sam inny URL też nie jest kompletnym dowodem związku z fokusem; trzeba odtworzyć wyzwalacz.
• Wskazówka Understanding: otrzymanie fokusu może wynikać z Tab lub kliknięcia w pole. Sam hover zwykle nie ustawia fokusu; skrypt może jednak go ustawić. Kliknięcie przycisku może jednocześnie ustawić fokus i uruchomić aktywację. Ustal, czy działanie następuje po aktywacji, czy już po samym fokusie; test Tab rozdziela te zdarzenia.
• Technika pomocnicza G107: zmiana kontekstu po aktywacji, np. przycisku, zamiast po fokusie. Technika nie jest jedynym dopuszczalnym rozwiązaniem ani dodatkowym normatywnym zakazem wszystkich aktualizacji.
• Udokumentowany błąd F55: skrypt usuwa fokus zaraz po jego otrzymaniu, np. przez blur(). Ukrycie obrysu w CSS jest odrębnym problemem widoczności fokusu; nie jest tym samym co usunięcie fokusu.
• Zmiana koloru obrysu, drobna informacja pomocnicza albo lokalne rozwinięcie treści nie muszą zmieniać kontekstu. Oceniaj skutek: czy fokus pozostał, zadanie i znaczenie widoku są te same, a treść nie została istotnie przeorganizowana. Nie przyjmuj „brak zmiany fokusu = zawsze PASS”.
• Modal odbierający fokus przy wejściu w pole jest błędny. Modal otwarty świadomą akcją „Pomoc z numerem” może poprawnie przejąć fokus. Zamknięcie po Escape i powrót do inicjatora to zarządzanie fokusem po działaniu użytkownika, a nie samoczynna zmiana przy wejściu na kontrolkę.
• Przewinięcie potrzebne do pokazania elementu wybranego przez użytkownika nie oznacza automatycznie naruszenia; badaj duży, dezorientujący skutek i przyczynę. Nie ustanawiamy progu pikseli ani czasu z definicji 3.2.1.
• Fokus klawiatury i fokus dostępności nie są identycznymi mechanizmami natywnych platform. Sam odczyt etykiety, onAppear, hover lub uruchomienie aplikacji nie dowodzi otrzymania fokusu. W aplikacji mobilnej trzeba odtworzyć właściwe sterowanie; otwarcie klawiatury do pola nie jest automatycznie dowodem błędu autora.
• Granica 3.2.2: zmiana wartości opcji lub pola jest osobnym wyzwalaczem; tam występuje warunek uprzedzenia użytkownika. Nie przenosić go do 3.2.1. Ustawienia iOS działają po aktywacji przycisku; historyczne WWW przeładowuje demonstrację po zmianie opcji, nie po fokusie selecta.
• Granica 3.2.5 (AAA): szersza ocena zmian kontekstu, niezależna od samego otrzymania fokusu. Aktualizacje po zegarze nie stają się automatycznie naruszeniem 3.2.1 bez związku przyczynowego. Podpowiedź na fokusie może wymagać osobnej oceny 1.4.13; wynik 3.2.1 jej nie zastępuje.

Platformy

Domyślna podstawa to WCAG 2.2. Poza WWW zastosowano informacyjną Group Note WCAG2ICT z 2025-12-11, która dla 3.2.1 zachowuje wymaganie bez zmiany. Interpretacja nie jest samodzielną normą zgodności ani wyborem podstawy prawnej audytu. W hybrydzie część HTML i część natywną badać osobno.

WCAG2ICT zwraca uwagę na dokumenty złożone, np. prezentację z osadzonym arkuszem. Zmiana narzędzi po jawnej komendzie menu lub specjalnym geście wyboru trybu nie jest skutkiem samego fokusu; nie oznacza to ogólnego wyjątku dla wszystkich dokumentów złożonych. Definicję zmiany kontekstu odnosimy do dokumentu albo oprogramowania, a nie tylko do URL.

Oddzielne mapowanie EN 301 549

Sprawdzono EN 301 549 V3.2.1 (2021-03), AI 2026-10-03. To jawnie określona wersja, a nie deklaracja najnowszej ani obowiązującej prawnie podstawy. Innych wersji EN nie mapowano w tym wpisie; nie przenosić numerów ani wyłączeń do innej wersji.

Uwagi 10.3.2.1 i 11.3.2.1 dotyczą jawnego wejścia w część dokumentu złożonego inną akcją niż samo ustawienie fokusu. Żaden wiersz nie oznacza „brak odpowiednika we wskazanej normie”. Nie dotyczy badanego scenariusza: dokument złożony, zamknięty kiosk i TV nie są częścią wykonanych demonstracji iOS/WWW; nie wyłącza to platform. Test według kompletnej EN i przegląd człowieka NOT-RUN. Klasyfikacja nie ustala obowiązków prawnych.

Rozwiązania w technologiach

Minimalne fragmenty umieszczają zmianę kontekstu w aktywacji. showSummary jest callbackiem aplikacji otwierającym podsumowanie; powinien zarządzać fokusem dopiero w wyniku tej akcji. Nie podłączaj go do odbioru fokusu, onFocusChange, onFocusChanged ani zdarzenia samego odczytania elementu. Obsługa zdarzenia fokusu może aktualizować obrys albo lokalną wskazówkę.

import 'package:flutter/cupertino.dart';

Widget pickupButton(VoidCallback showSummary) => CupertinoButton(
  onPressed: showSummary,
  child: const Text('Przejdź do podsumowania'),
);

<button id="review" type="button">Przejdź do podsumowania</button>
<script>
  document.getElementById('review').addEventListener('click', showSummary);
  // showSummary jest funkcją aplikacji; brak wyzwalania jej przy focus.
</script>

import androidx.compose.material3.Button
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable

@Composable
fun PickupButton(showSummary: () -> Unit) {
    Button(onClick = showSummary) { Text("Przejdź do podsumowania") }
}

import SwiftUI

struct PickupButton: View {
    let showSummary: () -> Void
    var body: some View {
        Button("Przejdź do podsumowania", action: showSummary)
    }
}

import React from 'react';
import { Pressable, Text } from 'react-native';

export function PickupButton({ showSummary }: { showSummary: () => void }) {
  return (
    <Pressable accessibilityRole="button" onPress={showSummary}>
      <Text>Przejdź do podsumowania</Text>
    </Pressable>
  );
}

Stan dokumentacji, kompilacji i działania

Brak buildów edukacyjnych fragmentów nie zobowiązuje do tworzenia czterech aplikacji. Składnia i build nie potwierdzają działania odbiornika ani technologii asystującej.

Jak sprawdzić

1. Na świeżym ekranie zapisz aktywny element, widok, okna i stan zadania przed wejściem. Rozróżnij fokus wejścia i dostępności oraz rzeczywiste sposoby otrzymania fokusu.
2. Przejdź Tab i Shift+Tab bez Enter/Space. Po każdym kroku zapisz odebrane wejście, fokus, callbacki i widok. Sprawdź wszystkie osiągalne komponenty, nie tylko pierwszy przycisk.
3. W good oczekuj zachowania formularza po fokusie, a modalu lub podsumowania dopiero po aktywacji. W bad samo otrzymanie fokusu wyzwala ten skutek. Sprawdź powrót do inicjatora po zamknięciu.
4. Osobno sprawdź kliknięcie pola i aktywację przycisku; kliknięcie przycisku może łączyć oba zdarzenia. Lokalna podpowiedź nie daje automatycznego FAIL, a stały URL nie daje automatycznego PASS. Oceniaj znaczenie zmiany i przyczynę.
5. Zbadaj kontrolę usunięcia fokusu oraz późniejsze skutki, jeśli występują. Nie ustanawiaj własnego progu pikseli albo czasu jako WCAG. Odsłuch i sterowanie AT wymagają osobnej próby.

Wyniki źródłowej próby mobilnej

Próba 2026-10-03: Flutter 3.44.9 / Dart 3.12.2, Xcode 27.0 / SDK 27.0, iPhone 17 Simulator / iOS 26.5. Ramka 402 × 874 pt, PNG 1206 × 2622 px, DPR 3, pion i jasny wygląd. Ustawienia systemowego tekstu nie zostały zmienione ani odczytane. Pasek 09:41 jest prezentacyjny. Finalne próbki obejmują 18:44:59–18:46:05 Europe/Warsaw; dwa testy, 0 failures, 72,761 s wykonania, bez pomiaru czasu reakcji produktu.

XCTest dostarczał klawisze przez XCUIApplication.typeKey. Aplikacja odczytywała niesyntetyzowane HardwareKeyboard.KeyDownEvent, aktualny fokus Fluttera, callbacki i zmianę widoku; natywne drzewa potwierdzały modal i podsumowanie. Driver nie ustawiał fokusu i nie zastępował wejścia wywołaniem callbacka. Programowe requestFocus w aplikacji było badanym skutkiem autora.

Zachowano wcześniejsze nieudane próby. Pierwsza: 25 odczytów, 22 żądania, 4 PNG; FAIL dostarczenia Escape. Helper miał błędny HID Escape, ale jego korekta nie zapewniła odbioru; końcowa próba użyła działającego Space. Druga: 27 odczytów, 24 żądania, 5 PNG; FAIL selektora StaticText dla nagłówka, który UIKit eksportował jako Other. Test poprawiono na etykietę niezależnie od typu. Aplikacja nie zmieniła się między próbami.

Wyniki wcześniejszej próby WWW

Próba 2026-10-03: Codex IAB na macOS 27.0, 1280 × 720 CSS px / DPR 1, zoom domyślny, JPEG 1280 × 720. Wersji silnika nie ustalono. Finalny przebieg 17:26:49–17:27:03 Europe/Warsaw dotyczył HTML.

Pierwsza próba WWW: 31 odczytów, 26 żądań, 5 JPEG, FAIL asercji resetu. Enter przeładował dokument na keydown, a nowy dokument zarejestrował keyup; oczekiwanie pustego dziennika było błędne. Poprawiono wyłącznie asercję. Finalny przebieg i niezmienione oryginały mają odrębne pochodzenie; historyczny FAIL nie jest nową usterką produktu. Powtarzające się nazwy initial/reset należy odróżniać kolejnością i czasem, nie nadpisywać po nazwie próbki.

Weryfikacja i ograniczenia

• Reguła deterministyczna na demonstracji: porównaj ciąg wejść, odebrany fokus i wynik. Tab bez click powodujący modal/fokus innego elementu lub zmianę całego widoku jest konkretnym negatywnym wynikiem. Oczekiwania PASS/FAIL są w runnerze i checkerze, poza obserwatorem aplikacji.
• Mobilny fokus: eksport FocusNode nie jest niezależnym odczytem systemowego fokusu iOS ani fokusu dostępności. XCTest dostarcza rzeczywiste klawisze i natywne drzewa UI, które potwierdzają skutek widokowy; nie potwierdza to VoiceOver lub Full Keyboard Access.
• Przybliżenie z DOM/AX: różne drzewa, URL, focus lub liczba okien wskazują zdarzenie do zbadania. Brak zmiany URL nie dowodzi PASS; lokalne rozwinięcie treści nie dowodzi FAIL. Trzeba też poznać zmianę znaczenia i przyczynę. Sam tekst onfocus nie jest naruszeniem.
• Potrzebny jest odczyt przed/po, typ wejścia, odebrane zdarzenia, aktywny komponent, widok i okna oraz stan zadania. isTrusted=true mówi o zdarzeniu odbiornika przeglądarki, nie o pochodzeniu od fizycznego człowieka. Sam fokus programowy też może emitować trusted event.
• Kliknięcie przycisku miesza fokus z aktywacją; kontrola Tab pomaga je oddzielić. Ukryte lub opóźnione skutki, rozgałęzienia zależne od danych, iframe, nowa karta i błędy czytnika mogą wymagać osobnych testów. Próbki nie są gwarancją braku efektu po dowolnym czasie.
• Ocena AI: interpretacja źródeł, odczyt i oględziny ośmiu nowych PNG i sześciu historycznych JPEG. Nie jest przeglądem merytorycznym człowieka. Człowiek: NOT-RUN. Nie testowano badanego walidatora Clearship ani nie mierzono skuteczności wykrywania na niezależnych przypadkach.
• Demonstracja ma selektor oczekiwanych wariantów dla odtwarzania. Przed przyszłym badaniem walidatora oddziel tę konfigurację i oczekiwania od jego wejścia; UI i eksport zawierają również scenario/good/bad. To test mechaniki własnej demonstracji, bez zaślepionej oceny jakości. Niewykrycie problemu lub brak danych nie oznaczają zgodności.

Bez filmu i audio: sekwencja wejść i trwałe stany opisują wyzwalacz, ale nie potwierdzają płynności, czasu reakcji ani wypowiedzi czytnika. Przegląd człowieka, VoiceOver, FKA, fizyczna klawiatura/iPhone i Android pozostają NOT-RUN. Systemowe Escape na iOS pozostaje FAIL dostarczenia, Enter NOT-RUN; działanie widgetu nie zastępuje tej drogi wejścia.

Jak sprawdza Clearship

Na Androidzie Clearship porównuje obserwacje przed i bezpośrednio po Tab/Shift+Tab, oddzielając je od aktywacji. Deterministyczna metoda focus-order-1 wskazuje wyjście z aplikacji, inny ekran lub nową treść z przeniesionym fokusem oraz próbuje ustalić komponent wyzwalający. Pomiar kontrolny z 7 października 2026 r. spełnił próg 3.2.1: 6/6 usterek, 0 fałszywych alarmów na 80 poprawnych ekranach.

Nieznany wyzwalacz, komponenty bez zbadanego fokusu, brak obserwacji, limit czasu i błąd klawiatury wymagają człowieka. Analiza obserwuje tylko skutek tuż po klawiszu: nie potwierdza braku opóźnionych przejść, fokusu czytnika ani wszystkich istotnych zmian znaczenia treści bez przeniesienia fokusu. Lokalna podpowiedź sama nie oznacza zmiany kontekstu, a procent zachowanych napisów jest parametrem detektora, nie regułą WCAG.

Na iOS przejście klawiaturowe P4 produktu jest niedostępne; kryterium pozostaje niezbadane i bez pomiaru. Edukacyjny XCTest Fluttera z 3 października nie uruchamia tej metody Clearship. Treść WWW i rzeczywiste AT są poza potwierdzonym zakresem.

Powiązane kryteria

• 3.2.2
  Podczas wprowadzania danych

  Zmiana wartości jest innym wyzwalaczem; dopuszczone tam uprzedzenie nie jest wyjątkiem dla samego fokusu.

• 2.4.3
  Kolejność fokusu

  Kolejność fokusu opisuje porządek obsługi i powroty po jawnych akcjach.

• 2.1.1
  Klawiatura

  Dostęp do funkcji klawiaturą jest osobnym wymaganiem.

• 2.1.2
  Brak pułapki na klawiaturę

  Modal musi pozwalać na wyjście klawiaturą.

• 2.4.7
  Widoczny fokus

  Ukrycie obrysu różni się od usunięcia fokusu.

• 1.4.13
  Treść po najechaniu lub otrzymaniu fokusu

  Dodatkowa treść na fokusie wymaga osobnej oceny.

• 3.2.5
  Zmiana na żądanie

  AAA obejmuje szerszy zakres inicjowania zmian kontekstu.

  Artykuł nie jest jeszcze dostępny.