Fokus niezasłonięty — minimum

Co oznacza to kryterium

Osoba korzystająca z klawiatury musi widzieć, na jaki element właśnie przeszła. Automatyczny banner lub nakładka nie może całkowicie zakryć tego elementu. W AA wystarczy, że część komponentu pozostaje widoczna; dobrą praktyką jest odsłonięcie go w całości. Sam widoczny obrys poza całkowicie ukrytym przyciskiem nie usuwa tego błędu.

Przykłady błędów i poprawek

Pracownia pokazuje informację „Odbiór dzisiaj do 18:00.” i przyciski „Pokaż adres” oraz „Pokaż godziny” dla P-104. Space na adresie zwiększa licznik i wyświetla „P-104: ul. Przykładowa 12. Wyświetlenia: 1.” Dane, cel, callbacki i kolejność kontrolek są wspólne; istotna różnica to umieszczenie powiadomienia względem treści.

Powiadomienie pojawia się od początku, bez aktywnego otwarcia regionu. Uwaga 2 nie ma zastosowania. Nie dodano pułapki, usuwania fokusu ani blokady Space w bad. Kontrola nie demonstruje prawidłowego wyglądu całego ekranu: pozostaje celowo częściowo zasłonięta.

Dodatkowe scenariusze, opisane bez wykonania: automatyczny toast nad celem — przenieść powiadomienie lub przewinąć cel przed zasłonięciem; panel narzędzi — poprawić pozycję początkową; chat otwarty przez użytkownika — sprawdzić odsłonięcie przez Escape przy zachowanym fokusie; dialog — rzeczywiście przejąć fokus do widocznej zawartości. Nie przypisujemy im PASS na podstawie bieżącego fixture.

Przewinięcie ponad stopkę

Kiedy obowiązuje i gdzie są wyjątki

Oceniany jest komponent przy otrzymaniu fokusu klawiatury, czyli postrzegana pojedyncza kontrolka pełniąca odrębną funkcję. Nie utożsamiaj komponentu z dowolnym węzłem DOM/AX. Jego widoczna treść, tło i granica pomagają ustalić obszar. Zewnętrzny wskaźnik nie wchodzi do komponentu w tym sprawdzeniu; wskaźnik wewnętrzny albo zmiana wyglądu samego komponentu może się do niego zaliczać.

Całkowite zasłonięcie narusza AA. Częściowe zasłonięcie może spełniać 2.4.11, choć nie spełnia AAA 2.4.12 — Focus Not Obscured (Enhanced). AA nie ustanawia tu progu procentowego widocznej powierzchni. Widoczna niewielka część nie jest rekomendowanym celem projektowym ani dowodem spełnienia innych kryteriów.

Uwaga 1 — regiony przemieszczane przez użytkownika: oceniamy początkowe położenie takich regionów w konfigurowalnym interfejsie. Nie oceniamy każdej pozycji, do której użytkownik sam przeciągnie panel. Nie jest to zwolnienie dla źle umieszczonego panelu początkowego ani każdej nakładki.

Uwaga 2 — treść aktywnie otwarta przez użytkownika: region celowo pozostający otwarty może zasłonić kolejny cel, jeżeli użytkownik może go odsłonić bez przesuwania fokusu dalej i bez powrotu do kontrolki zamknięcia. Przykładowo Escape zamyka chat, klawisze przewijają widok przy zachowanym celu albo polecenie zmienia kolejność warstw. Nie rozszerzamy tego na automatycznie wyświetloną stopkę, banner lub ostrzeżenie; ich cel musi być niecałkowicie ukryty już przy otrzymaniu fokusu. Nieprzetrwałe menu, combobox czy tooltip powinny odpowiednio znikać po zakończeniu interakcji; samo nazwanie ich „otwartymi przez użytkownika” nie uzasadnia pozostawienia zasłaniającej warstwy.

Poprawny modal przejmuje rzeczywisty fokus do widocznego komponentu i utrzymuje interakcję w swojej treści do zamknięcia. Sama nazwa modal lub rola dialog nie dowodzi tego zachowania. W tej demonstracji nie ma modalu, przemieszczalnego panelu ani wyjątku uwagi 2 — te przypadki opisano, ale nie odtworzono.

Przezroczystość, przyciemnienie i blur wymagają oceny rzeczywistego obrazu. Jeżeli komponent nadal widać, nie jest całkowicie ukryty z samego powodu nakładania ramek; kontrast może jednak wymagać osobnego sprawdzenia. Klawiatura ekranowa OS i nakładka user agenta nie są automatycznie treścią autora; rozróżnij pochodzenie warstwy i właściwą odpowiedzialność poza kontekstem webowym.

Brak obrysu sam w sobie należy do 2.4.7 — Widoczny fokus, a nie automatycznie do 2.4.11. AAA 2.4.13 — Focus Appearance opisuje wygląd fokusu. 1.4.11 ma własny zakres kontrastu. Dostępność aktywacji i wyjścia oceniają także 2.1.1 i 2.1.2.

Technika, błąd i ACT

Understanding sprawdzono w całości: aktualizacja 2026-06-15. Techniki i opis błędu są pomocnicze, nie normatywne:

• C43, aktualizacja 2025-09-25: scroll-padding wyznacza obszar dla odsłaniania komponentu. Potrzebne jest również rzeczywiste miejsce na przewijanie, np. padding dokumentu, i wysokość dostosowana do nakładki. Dekoracyjne CSS bez takiego miejsca nie wystarcza. Przykład W3C przechodzi z fixed do przepływu przy małym widoku około 800 px; nasz próg obejmuje szerokości do 800 px włącznie. Test #1 dotyczy całkowitego zasłonięcia/AA; test #2 również częściowego/AAA.
• F110.html, aktualizacja 2025-07-15: sticky nagłówek lub stopka całkowicie ukrywa komponent otrzymujący fokus. Procedura przechodzi klawiaturą w obie strony. Własny WWW odtwarza stopkę fixed; mobilna nakładka jest analogią tego zasłaniania, nie identycznym CSS.
• ACT: aktualny katalog sprawdzony 2026-10-04 nie zawiera reguły dla 2.4.11. Reguła widocznego fokusu dla 2.4.7 nie staje się regułą zasłonięcia 2.4.11. Nasz checker bada fixture i integralność materiału; nie jest wykonaniem ACT ani niezależnym walidatorem.

Platformy

WCAG2ICT stosuje 2.4.11 bez zmiany brzmienia, jako informacyjną interpretację poza WWW, nie osobną normę zgodności. Nie analizowano EN 301 549 ani obowiązków prawnych. Brak testu innej platformy nie oznacza jej wyłączenia; w hybrydzie rozróżniamy część natywną i webową.

Rozwiązania w technologiach

Przegląd oficjalnej dokumentacji: AI 2026-10-04. Fragmenty edukacyjne zakładają lokalny podgląd adresu, a nie wysłanie zamówienia. Sama poprawna geometria przykładu nie potwierdza wszystkich kombinacji tekstu, rozmiaru okna i dynamicznych powiadomień.

import 'package:flutter/cupertino.dart';

Widget pickup(VoidCallback onShow) => SingleChildScrollView(
  child: Column(
    crossAxisAlignment: CrossAxisAlignment.stretch,
    children: [
      const Text('Odbiór dzisiaj do 18:00.'),
      CupertinoButton(
        onPressed: onShow,
        child: const Text('Pokaż adres'),
      ),
    ],
  ),
);

import SwiftUI

struct PickupView: View {
    let onShow: () -> Void
    var body: some View {
        VStack(spacing: 12) {
            Text("Odbiór dzisiaj do 18:00.")
            ScrollView {
                Button("Pokaż adres", action: onShow)
            }
        }
    }
}

import androidx.compose.foundation.layout.Column
import androidx.compose.foundation.layout.padding
import androidx.compose.foundation.rememberScrollState
import androidx.compose.foundation.verticalScroll
import androidx.compose.material3.Button
import androidx.compose.material3.Scaffold
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier

@Composable
fun Pickup(onShow: () -> Unit) {
    Scaffold(bottomBar = { Text("Odbiór dzisiaj do 18:00.") }) { insets ->
        Column(Modifier.padding(insets).verticalScroll(rememberScrollState())) {
            Button(onClick = onShow) { Text("Pokaż adres") }
        }
    }
}

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

export function Pickup({ onShow }: { onShow: () => void }) {
  return (
    <View style={{ flex: 1 }}>
      <ScrollView style={{ flex: 1 }}>
        <Button title="Pokaż adres" onPress={onShow} />
      </ScrollView>
      <View>
        <Text>Odbiór dzisiaj do 18:00.</Text>
      </View>
    </View>
  );
}

:root {
  --notice-height: 180px;
  --space: calc(var(--notice-height) + 20px);
}
body {
  padding-bottom: var(--space);
}
html {
  scroll-padding-bottom: var(--space);
}
.notice {
  position: fixed;
  inset: auto 0 0;
}
@media (max-width: 800px) {
  .notice {
    position: static;
  }
  body {
    padding-bottom: 0;
  }
  html {
    scroll-padding-bottom: 0;
  }
}

Jak sprawdzić

1. Ustal komponent, pochodzenie nakładki, warunek klawiatury i wyjątki. Nie porównuj tylko prostokątów AX ani samego obrysu.
2. Otwórz scenariusz w początkowym układzie. Przejdź rzeczywistymi Tab i Shift+Tab, zapisując fokus, ramki, warstwy oraz obraz przy otrzymaniu fokusu. Nie ustawiaj celu testowym setterem po jego odsłonięciu.
3. Dla każdego badanego celu ustal, czy jest całkowicie ukryty przez treść autora. Częściowe zasłonięcie oddziel od AA i AAA. Uwzględnij opacity, z-order, clipping, blur i widoczną treść komponentu.
4. Gdy rozważasz uwagę 2, potwierdź aktywne otwarcie utrzymującego się regionu przez użytkownika i odsłonięcie bez zmiany celu fokusu. Sam możliwy powrót Tab do zamknięcia nie wystarcza.
5. Dla poprawki przewijania sprawdź prawdziwe miejsce na końcu treści, zmienną wysokość powiadomienia, oba kierunki i breakpoint. CSS deklaracja bez obserwacji nie jest PASS.
6. Uruchom zwykłą akcję celu oraz sprawdź wyjście, cykl i reset. Zapisz oczekiwany oraz faktyczny wynik osobno; bad może pozostawać operowalny, a mimo to naruszać zasłonięcie.

Zaobserwowany zakres: przycisk adresu w trzech wariantach, oba kierunki i aktywacja; godziny jako następny cel, reset/fallback; dodatkowo WWW 800 px. Nie badano wszystkich okien, systemowych ustawień ani konfiguracji powiększenia. Przebadany good spełnia warunek w zapisanych otrzymaniach fokusu; nie oznacza zgodności całej aplikacji.

Weryfikacja i ograniczenia

Wyniki, pochodzenie i nieudane próby

Jedna natywna próba: 2026-10-04, iPhone 17 Simulator / iOS 26.5, Flutter 3.44.9 / Dart 3.12.2, Xcode 27.0; SDK 27.0 jest odrębne od runtime 26.5. XCTest wysłał Tab, Shift+Tab i Space, odebrane przez aplikację jako KeyDown/KeyUp bez synthesized. Obserwowano rzeczywisty primary focus oraz geometrię przy otrzymaniu fokusu. Wszystkie warianty pozwoliły uruchomić adres; bad izolował zasłonięcie, bez pułapki i blokady klawisza.

Good miał przycisk 24,321,354,52 i banner 24,233,354,80 logical px. Bad: przycisk 24,241,354,52 pod nieprzezroczystym bannerem 24,233,354,68. Control zasłaniał dolne 26 logical px. W testowanym pasie PNG bad miał 13 104 piksele banneru; control połowę tego pasa, a good zachował tło przycisku. To kontrola konkretnej pary, nie próg WCAG ani ogólna segmentacja komponentów.

W przeglądarce 1280×720 good rezerwował 200 CSS px pod stopką o wysokości 180 px oraz scroll-padding 200 px. Pierwszy Tab przewinął scrollY 0 → 359 i odsłonił cel nad nakładką. Bad pozostał całkowicie ukryty; control zachował 7,25 CSS px wysokości komponentu. Oba kierunki i Space odtworzono. Przy szerokości 800 px stopka przechodziła do przepływu, padding i scroll-padding wynosiły 0. Po przywróceniu szerokości zachowano późniejsze zasłonięcie istniejącego fokusu, bez nowego otrzymania fokusu i bez rozszerzania wyniku na każdy resize.

pointer-events:none przepuszczał wejście, a hit-test wskazywał przycisk również w bad. Nie dowodzi to widoczności: wymagane są warstwy, style i obraz. paintOrder pozostało puste; kolejność potwierdzają kod Stack i obraz, bez przypisywania nieistniejącego pomiaru.

Nie było FAIL lub przerwania XCTest. Dwa odczyty webowe miały AX i obraz bez DOM z powodu niepełnego callbacku; zachowano je jako historię, nie kompletne próbki. Ograniczenia sandboxu/cache SDK, odczytu ps i nieobsługiwanej jakości obrazu były błędami przygotowania, nie wynikiem aplikacji. Końcowe 19 stanów/drzew i 18 wejść iOS oraz 28 AX (26 DOM) i 25 akcji webowych nie są testem czytnika ani ciągłą obserwacją między próbkami. Filmu i audio nie wykonano.

Granice oceny

Deterministyczny checker może porównać known fixture, zdarzenia, ramki, piksele i hashe. Nie ustala automatycznie pochodzenia każdej nakładki, postrzeganej granicy komponentu lub wyjątku aktywnie otwartego regionu. Drzewo to przybliżenie: całkowicie zakryty przycisk nadal istnieje w AX, a hit-test może go zwracać. Ocena AI obrazu jest oddzielna od pomiaru i przeglądu człowieka. Niepełny obraz/stan oznacza brak danych, nie spełnienie kryterium.

Manifest oczekiwanych wariantów jest poza wejściem przyszłego badanego walidatora. Obecny fixture/checker nie jest zaślepiony ani niezależnym benchmarkiem. Wynik kontroli dotyczy integralności i tej pary, nie skuteczności wykrywania dowolnej aplikacji.

NOT-RUN: przegląd człowieka; zaślepiony walidator; AT/VoiceOver/przełączniki; fizyczny iPhone i sprzętowa klawiatura; Android, desktop, kiosk i odbiornik dokumentu; własne fragmenty SwiftUI/Compose/RN i niewykonane ustawienia OS; modal, użytkownikowe przemieszczanie i aktywnie otwarty region z uwagi 2. Nie są to FAIL ani wyłączenia platform. Brak buildów innych frameworków jest uzgodnionym zakresem, nie automatycznym TODO.

Jak sprawdza Clearship

Clearship sprawdza na Androidzie element otrzymujący fokus w przejściu klawiaturowym. Łączy pokrycie jego ramy innymi węzłami z porównaniem obrazu; osobno rozpoznaje region otwarty przez użytkownika i odsłonięty przez Escape bez zmiany fokusu. Progi techniczne analizatora są heurystyką, a nie procentowym minimum WCAG.

Metoda spełniła próg kontrolny Androida 7 października 2026 r. w ograniczonym zbiorze przypadków. Nie obejmuje wszystkich stanów, pozycji przemieszczanych paneli, osobnej treści webowej ani nakładek poza drzewem aplikacji. Nieosiągnięte komponenty, brak obrazu i niepotwierdzone warstwy wymagają człowieka. iOS nie ma dostępnego przejścia klawiaturowego produktu i jest niezbadany. Wynik bez problemów dotyczy jedynie faktycznie ocenionego zakresu bez pominięć.

Powiązane kryteria

• 2.4.7
  Widoczny fokus

  Widoczność wskaźnika nie potwierdza odsłonięcia komponentu.

• 1.4.11
  Kontrast elementów nietekstowych

  Widoczny komponent może nadal wymagać oceny kontrastu.

• 2.1.1
  Klawiatura

  Ukryta kontrolka może działać klawiaturą; to osobna właściwość.

• 2.1.2
  Brak pułapki na klawiaturę

  Modal i wyjście z pułapki wymagają odrębnego sprawdzenia.