WCAG 3.2.1: Przy fokusie

Co Oznacza Ta Zasada

Kryterium sukcesu WCAG 3.2.1 On Focus (Po ustawieniu fokusu) (poziom A) stanowi: „Jeśli jakikolwiek komponent otrzymuje fokus, nie inicjuje to zmiany kontekstu.” Mówiąc prościej, samo przeniesienie fokusu na element interaktywny — poprzez naciśnięcie klawisza Tab, Shift+Tab, klawiszy strzałek lub innego mechanizmu klawiaturowego — nie może samo w sobie powodować, że na stronie wydarzy się coś dramatycznego i nieoczekiwanego.

Zmiana kontekstu jest zdefiniowana w WCAG jako istotna zmiana treści strony, która, jeśli nastąpi bez świadomości użytkownika, może go zdezorientować. Specyfikacja wyróżnia cztery konkretne typy zmiany kontekstu: zmiany w agencie użytkownika (takie jak otwarcie nowego okna lub karty przeglądarki), zmiany w obszarze widoku (takie jak automatyczne przewinięcie do odległej części strony), zmiany samego fokusu (takie jak automatyczne przeniesienie fokusu w inne miejsce) oraz zmiany treści, które znacząco zmieniają sens strony (takie jak wysłanie formularza lub załadowanie zupełnie innego widoku).

Kluczowe rozróżnienie, jakie wprowadza to kryterium, dotyczy otrzymania fokusu a aktywacji kontrolki. Przejście tabulatorem na przycisk, które powoduje natychmiastowe wysłanie formularza, jest naruszeniem. Natomiast naciśnięcie klawisza Enter lub Spacja, gdy przycisk ma fokus — czyli celowa, zamierzona aktywacja — jest całkowicie akceptowalne i wręcz oczekiwane. To intencja użytkownika odróżnia przewidywalną interakcję od dezorientującej.

Typowe wzorce, które nie spełniają tego kryterium, obejmują:

• Rozwijane menu <select>, które automatycznie nawiguje do nowego adresu URL, gdy tylko opcja otrzyma fokus (a nie gdy użytkownik potwierdzi swój wybór).
• Widżet wyboru daty, który otwiera okno modalne w momencie, gdy którykolwiek z jego pól wejściowych otrzyma fokus, bez jakiejkolwiek aktywacji przez użytkownika.
• Karuzelę lub pokaz slajdów, który automatycznie przechodzi do następnego slajdu, gdy jego kropki nawigacyjne otrzymują fokus.
• Dymek podpowiedzi lub popover, który po wywołaniu przez fokus jednocześnie przenosi fokus klawiatury na siebie bez ostrzeżenia, pozostawiając użytkownika w nieoczekiwanym miejscu.
• Pole wyszukiwania, które natychmiast wysyła zapytanie i przeładowuje stronę, gdy otrzyma fokus.

Wzorce, które wprost nie są naruszeniami, obejmują: dymek podpowiedzi lub panel opisu, który pojawia się wizualnie, ale nie przenosi fokusu ani nie zmienia głównej treści strony; wskaźnik fokusu (taki jak obrys lub pierścień) pojawiający się wokół elementu z fokusem; lub element rozwijający się, aby pokazać dodatkową treść w linii, o ile fokus pozostaje tam, gdzie umieścił go użytkownik.

W WCAG 3.2.1 nie zdefiniowano oficjalnych wyjątków. Kryterium ma zastosowanie uniwersalne do wszystkich komponentów interfejsu na stronie. Dokument „Understanding WCAG” zauważa jednak, że zmiany kontekstu wywołane przez celową aktywację przez użytkownika (kliknięcie, Enter, Spacja) wykraczają poza zakres tego kryterium, które dotyczy wyłącznie pasywnego aktu otrzymania fokusu.

Dlaczego To Ma Znaczenie

Kryterium On Focus mieści się w Zasadzie 3 — Zrozumiałość — ponieważ przewidywalność jest podstawowym warunkiem użyteczności. Gdy strona zachowuje się nieoczekiwanie w odpowiedzi wyłącznie na fokus, konsekwencje wahają się od lekkiego zagubienia po całkowitą utratę dostępu, w zależności od potrzeb i narzędzi użytkownika.

Użytkownicy korzystający wyłącznie z klawiatury (osoby, które nie mogą używać myszy z powodu niepełnosprawności ruchowej, urazów przeciążeniowych lub paraliżu) polegają wyłącznie na nawigacji klawiaturą. Gdy przejście tabulatorem do pola formularza wywołuje przeładowanie strony, mogą utracić wszystkie dane, które już wprowadzili, i zostać przekierowani z dala od swojego celu. Odzyskanie po takiej przerwie może wymagać znacznego czasu i wysiłku — lub użytkownik może po prostu całkowicie zrezygnować.

Użytkownicy czytników ekranu (którzy często są również użytkownikami korzystającymi wyłącznie z klawiatury) doświadczają dodatkowej warstwy dezorientacji. Czytniki ekranu ogłaszają użytkownikowi aktualnie fokusowany element. Jeśli fokus niespodziewanie przeskoczy do nowego elementu — na przykład do modala, który otworzył się automatycznie — czytnik ekranu ogłosi nowy kontekst, nie dając użytkownikowi żadnego punktu odniesienia, co właśnie się stało i dlaczego. Jest to analogiczne do sytuacji, w której ktoś zostaje fizycznie przeniesiony do innego pokoju bez ostrzeżenia.

Użytkownicy z niepełnosprawnościami poznawczymi, w tym osoby z ADHD, zaburzeniami lękowymi lub zaburzeniami pamięci, polegają na przewidywalnych interfejsach, aby zbudować i utrzymać mentalny model strony. Nagłe, niewyjaśnione zmiany kontekstu niszczą ten model, powodując zamieszanie, lęk i błędy. Badanie projektu WebAIM Million konsekwentnie wykazuje, że złożone komponenty interaktywne o nieoczekiwanych zachowaniach należą do głównych źródeł skarg dotyczących dostępności zgłaszanych przez użytkowników z niepełnosprawnościami poznawczymi.

Użytkownicy słabowidzący, którzy korzystają z oprogramowania powiększającego ekran (takiego jak ZoomText lub Windows Magnifier), widzą jednocześnie tylko niewielką część ekranu. Jeśli fokus powoduje automatyczne przewinięcie lub nawigację, odpowiednia treść może całkowicie zniknąć z ich powiększonego obszaru widoku, pozostawiając ich patrzących na pusty lub niepowiązany fragment ekranu.

Rozważmy konkretny scenariusz z rzeczywistości: formularz przelewu online w tureckim banku zawiera rozwijane menu do wyboru banku docelowego. Programista zaimplementował zdarzenie w stylu onchange na elemencie <select>, które uruchamia się nie przy potwierdzeniu, lecz w momencie, gdy dowolna opcja otrzyma fokus za pomocą klawiszy strzałek. Użytkownik czytnika ekranu, przechodząc tabulatorem do pola i naciskając strzałkę w dół, aby przejrzeć dostępne banki, natychmiast wywołuje wysłanie formularza lub przeładowanie strony. Nigdy nie kończy przelewu i nie jest w stanie ustalić, co poszło nie tak. Ten scenariusz nie jest hipotetyczny — był udokumentowanym wzorcem w wielu wczesnych aplikacjach jednostronicowych.

Poza dostępnością istnieją wymierne korzyści w zakresie użyteczności i biznesu. Formularze, które nie przechwytują fokusu, mają niższe wskaźniki porzucania. Strony, które zachowują się przewidywalnie, osiągają lepsze wyniki w testach użyteczności wśród wszystkich grup odbiorców. Roboty wyszukiwarek również korzystają z przewidywalnych przepływów nawigacji, ponieważ nieoczekiwane przekierowania wywoływane przez zdarzenia fokusu mogą dezorientować logikę indeksowania w niektórych scenariuszach dynamicznego renderowania.

Powiązane Zasady Axe-core

WCAG 3.2.1 On Focus wymaga testów manualnych, ponieważ narzędzia automatyczne nie są w stanie wiarygodnie określić intencji użytkownika ani przewidzieć wszystkich możliwych zmian kontekstu. Axe-core i podobne skanery automatyczne potrafią analizować statyczny kod HTML i atrybuty ARIA, ale nie mogą obserwować zachowania JavaScriptu w czasie działania w odpowiedzi na zdarzenia fokusu — w szczególności tego, czy dane zachowanie stanowi „istotną” zmianę kontekstu w rozumieniu WCAG. Skrypt, który przenosi fokus, wysyła formularz lub nawiguję do adresu URL w zdarzeniu focus, jest niewidoczny dla statycznego skanera, chyba że narzędzie faktycznie symuluje interakcje fokusu dla każdego elementu interaktywnego, a następnie analizuje, co zmieniło się w DOM, obszarze widoku i adresie URL. Taki poziom symulacji zachowania nie jest wiarygodnie osiągalny w jednym automatycznym przebiegu bez nieakceptowalnie wysokiego odsetka fałszywych alarmów.

• Wymagane testy manualne — zmiana kontekstu po ustawieniu fokusu: Testerzy muszą ręcznie przechodzić tabulatorem przez każdy element interaktywny na stronie (linki, przyciski, pola formularzy, elementy select, niestandardowe widżety) i obserwować, czy sam fokus — bez jakiejkolwiek aktywacji — wywołuje zmianę kontekstu w rozumieniu WCAG. Obejmuje to obserwowanie zmian adresu URL, otwierania nowych okien lub kart, przenoszenia fokusu z bieżącego elementu, wysyłania formularzy oraz istotnych podmian treści. Narzędzia automatyczne oznaczają nasłuchiwacze zdarzeń JavaScript podpięte do zdarzeń związanych z fokusem (focus, focusin, onfocus) jako kandydatów do przeglądu manualnego, ale nie są w stanie określić, czy te procedury obsługi powodują dyskwalifikującą zmianę kontekstu.

Jak Testować

1. Automatyczny wstępny skan: Uruchom axe DevTools (rozszerzenie przeglądarki lub CLI) lub Google Lighthouse na stronie. Choć żadne z tych narzędzi nie może jednoznacznie wykryć naruszeń On Focus, axe DevTools może ujawnić powiązane problemy z zarządzaniem fokusem (takie jak wzorce scrollable-region-focusable lub pułapki fokusu), które wymagają dokładniejszej inspekcji manualnej. Skorzystaj z panelu „Needs Review” w axe DevTools — elementy tam oznaczone często dotyczą zachowań komponentów interaktywnych, które wymagają oceny przez człowieka.
2. Identyfikacja wszystkich elementów interaktywnych: Przed testami klawiaturowymi sporządź listę wszystkich komponentów interaktywnych: linków, przycisków, pól formularzy, rozwijanych list, pól wyboru, przycisków radiowych, selektorów dat, karuzel, akordeonów, kart, okien modalnych oraz wszelkich niestandardowych widżetów używających tabindex. Zwróć szczególną uwagę na niestandardowe widżety JavaScript, które nasłuchują zdarzeń focus lub focusin.
3. Test nawigacji wyłącznie klawiaturą: Używając wyłącznie klawiatury (bez myszy), naciskaj kolejno Tab, przechodząc przez każdy element, który może otrzymać fokus na stronie. Po każdym naciśnięciu Tab, zanim naciśniesz cokolwiek innego, obserwuj: Czy adres URL się zmienił? Czy otworzyło się nowe okno lub karta? Czy fokus przeniósł się z elementu, do którego właśnie przeszedłeś? Czy formularz został wysłany? Czy główna treść strony zmieniła się dramatycznie? Każda odpowiedź „tak” jest potencjalnym naruszeniem.
4. Test elementów select: Ustaw fokus na dowolnym rozwijanym menu <select>. Użyj klawiszy strzałek w górę i w dół, aby przechodzić między opcjami bez naciskania Enter lub Spacji. Upewnij się, że nawigacja między opcjami nie wywołuje żadnej nawigacji, wysłania formularza ani zmiany kontekstu. Jest to jeden z najczęściej naruszanych wzorców.
5. NVDA + Firefox: Włącz NVDA (darmowy, na Windows). Otwórz Firefox i przejdź do strony. Naciskaj Tab, przechodząc przez wszystkie elementy interaktywne. Słuchaj komunikatów NVDA — jeśli NVDA zaczyna ogłaszać zupełnie inną część strony lub nowy kontekst strony po naciśnięciu Tab (bez naciskania Enter lub Spacji), jest to silny sygnał naruszenia.
6. JAWS + Chrome: Włącz JAWS. Otwórz Chrome. Używaj Tab do nawigacji. JAWS będzie ogłaszał każdy element z fokusem. Monitoruj nieoczekiwane komunikaty o nowych dialogach, stronach lub lokalizacjach fokusu, do których nie nawigowałeś celowo.
7. VoiceOver + Safari (macOS/iOS): Włącz VoiceOver (Cmd+F5 na macOS). Nawiguj za pomocą Tab (lub gestów przesunięcia na iOS). Monitoruj nieoczekiwane zmiany kontekstu. Na iOS przetestuj również z dostępem przełącznikowym (switch access), aby zasymulować użytkowników z poważnymi niepełnosprawnościami ruchowymi, którzy nawigują za pomocą skanowania.
8. Inspekcja nasłuchiwaczy zdarzeń w narzędziach deweloperskich przeglądarki: W Chrome DevTools wybierz dowolny podejrzany element interaktywny, przejdź do panelu Elements i kliknij „Event Listeners”. Poszukaj nasłuchiwaczy focus lub focusin. Jeśli są obecne, przeanalizuj powiązany kod JavaScript, aby ustalić, czy procedura obsługi wywołuje nawigację, wysłanie formularza, przeniesienie fokusu lub inne działania zmieniające kontekst.

Jak Naprawić

Automatycznie wysyłające się rozwijane menu select — Nieprawidłowe

<!-- FAIL: Selecting an option via arrow key immediately navigates to a new URL -->
<label for='region'>Select Region</label>
<select id='region' onchange='window.location = this.value;'>
  <option value='/istanbul'>Istanbul</option>
  <option value='/ankara'>Ankara</option>
  <option value='/izmir'>Izmir</option>
</select>

Automatycznie wysyłające się rozwijane menu select — Prawidłowe

<!-- PASS: Navigation only occurs when the user explicitly activates the Go button -->
<label for='region'>Select Region</label>
<select id='region'>
  <option value='/istanbul'>Istanbul</option>
  <option value='/ankara'>Ankara</option>
  <option value='/izmir'>Izmir</option>
</select>
<button type='button' onclick='navigateToRegion()'>Go</button>

<script>
function navigateToRegion() {
  var select = document.getElementById('region');
  window.location = select.value; // Only fires on deliberate button activation
}
</script>

Otwieranie modala przy ustawieniu fokusu na polu — Nieprawidłowe

<!-- FAIL: Focusing the date input immediately opens a modal dialog and moves focus -->
<label for='departure'>Departure Date</label>
<input type='text' id='departure' onfocus='openDatePickerModal()' />

<script>
function openDatePickerModal() {
  var modal = document.getElementById('date-modal');
  modal.style.display = 'block';
  modal.querySelector('button').focus(); // Moves focus away without user intent
}
</script>

Otwieranie modala przy ustawieniu fokusu na polu — Prawidłowe

<!-- PASS: The date picker opens only when the user explicitly clicks or presses Enter/Space -->
<label for='departure'>Departure Date</label>
<input type='text' id='departure' readonly aria-haspopup='dialog'
       aria-label='Departure Date — press Enter to open date picker' />
<button type='button' id='open-picker'
        aria-controls='date-modal'
        onclick='openDatePickerModal()'>
  Choose Date
</button>

<script>
function openDatePickerModal() {
  // Only called on explicit activation (click or Enter/Space on the button)
  var modal = document.getElementById('date-modal');
  modal.removeAttribute('hidden');
  modal.querySelector('[data-initial-focus]').focus();
}
</script>

Karuzela automatycznie przechodząca do kolejnego slajdu po ustawieniu fokusu — Nieprawidłowe

<!-- FAIL: Focusing a navigation dot advances the carousel slide, changing page content -->
<div class='carousel-dots'>
  <button class='dot' onfocus='showSlide(0)'>1</button>
  <button class='dot' onfocus='showSlide(1)'>2</button>
  <button class='dot' onfocus='showSlide(2)'>3</button>
</div>

Karuzela automatycznie przechodząca do kolejnego slajdu po ustawieniu fokusu — Prawidłowe

<!-- PASS: The carousel only changes slides when the dot is explicitly activated (click/Enter) -->
<div class='carousel-dots' role='tablist' aria-label='Carousel navigation'>
  <button class='dot' role='tab' aria-selected='true'
          aria-controls='slide-0' onclick='showSlide(0)'>
    Slide 1
  </button>
  <button class='dot' role='tab' aria-selected='false'
          aria-controls='slide-1' onclick='showSlide(1)'>
    Slide 2
  </button>
  <button class='dot' role='tab' aria-selected='false'
          aria-controls='slide-2' onclick='showSlide(2)'>
    Slide 3
  </button>
</div>
<!-- onclick only fires on deliberate activation, not on Tab focus -->

Typowe Błędy

• Używanie onfocus jako zamiennika onclick w elementach nawigacyjnych: Programiści czasem podpinają procedury onfocus do linków lub przycisków nawigacyjnych, aby „wstępnie załadować” miejsce docelowe, przypadkowo wywołując pełną nawigację zamiast samego wstępnego pobrania. Zawsze używaj onclick lub onkeydown (sprawdzając Enter/Spację) dla wszelkich akcji, które zmieniają kontekst.
• Podpinanie onchange do elementów <select> bez akcji wysyłania: W przeglądarkach desktopowych onchange na <select> uruchamia się, gdy opcja zostanie potwierdzona, ale w niektórych starszych implementacjach i niektórych przeglądarkach mobilnych może uruchamiać się przy przechodzeniu między opcjami klawiszami strzałek. Zawsze łącz nawigację opartą na select z wyraźnym przyciskiem wysyłania lub użyj <form> z <button type='submit'>.
• Programowe przenoszenie fokusu wewnątrz procedury obsługi zdarzenia focus: Wywołanie element.focus() wewnątrz procedury onfocus lub focusin innego elementu powoduje nieoczekiwany skok fokusu. Jest to bezpośrednie naruszenie — użytkownik przeszedł tabulatorem do elementu A, a fokus po cichu przeniósł się do elementu B. Zawsze przenoś fokus wyłącznie w odpowiedzi na celowe działania użytkownika.
• Otwieranie okien modalnych w odpowiedzi na zdarzenia fokusu elementu wyzwalającego: Częstym skrótem jest podpinanie procedury otwierającej modal do zdarzenia focus przycisku lub pola wejściowego. Modale muszą otwierać się wyłącznie w odpowiedzi na kliknięcie, naciśnięcie Enter lub Spacji — nigdy tylko na fokus.
• Automatyczne odtwarzanie multimediów lub animacji, które zmieniają kontekst obszaru widoku po ustawieniu fokusu: Baner główny, który rozpoczyna pełnoekranowe wideo lub dużą animację w momencie, gdy jego przycisk odtwarzania otrzyma fokus, znacząco zmienia kontekst wizualny. Powiąż akcje odtwarzania ze zdarzeniami aktywacji, a nie fokusu.
• Wywoływanie aktualizacji regionów live, które przewijają stronę do nowej treści po ustawieniu fokusu: Niektóre dynamiczne widżety aktualizują region live, a następnie przewijają obszar widoku do tego regionu, gdy tylko pole wejściowe otrzyma fokus. Zmienia to kontekst obszaru widoku i dezorientuje użytkowników powiększających ekran. W miarę możliwości oddziel aktualizacje regionów live od zdarzeń fokusu.
• Implementowanie niestandardowych pułapek fokusu, które natychmiast „uwięziają” użytkowników bez poinformowania: Niestandardowy komponent, który przechwytuje wszystkie naciśnięcia Tab w momencie, gdy otrzyma fokus, bez ogłoszenia użytkownikowi, że znajduje się w pułapce fokusu, narusza zarówno literę, jak i ducha tego kryterium. Pułapki fokusu są odpowiednie wyłącznie wewnątrz w pełni otwartych okien modalnych, a użytkownicy muszą być poinformowani, jak z nich wyjść.
• Używanie CSS :focus do wyzwalania display: block w menu rozwijanych zawierających elementy z fokusem, co powoduje kaskadowe, nieoczekiwane ruchy fokusu: Menu oparte wyłącznie na CSS, sterowane fokusem, które ujawniają elementy z możliwością ustawienia fokusu, mogą powodować mylące skoki, gdy kolejność fokusu przeglądarki przechodzi do nowo widocznych elementów. Upewnij się, że ujawniane menu są oczekiwane i jasno komunikowane za pomocą atrybutów ARIA, takich jak aria-expanded.
• Poleganie na bibliotekach widżetów firm trzecich bez audytu ich zachowania fokusu: Wiele bibliotek komponentów interfejsu (selektory dat, edytory tekstu sformatowanego, rozwijane listy w stylu select2) historycznie naruszało 3.2.1, otwierając wyskakujące okna lub przenosząc fokus w odpowiedzi na zdarzenia focus. Zawsze przeprowadzaj manualny audyt komponentów firm trzecich przed wdrożeniem, niezależnie od deklaracji dostępności biblioteki.
• Zapominanie o testowaniu w kontekście routingu aplikacji jednostronicowych (SPA): W aplikacjach SPA React, Vue i Angular zdarzenia fokusu na linkach nawigacyjnych mogą czasem wywoływać zmiany tras za pośrednictwem logiki prefetch routera lub propagacji zdarzeń, zwłaszcza gdy zdarzenia fokusu nie są prawidłowo zatrzymywane przed propagacją. Testuj komponenty nawigacyjne SPA pod kątem zgodności z 3.2.1 w sposób szczególny.

Związek z Tureckimi Regulacjami Dotyczącymi Dostępności

Prezydencki Okólnik Turcji 2025/10, opublikowany w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia obowiązkowe wymagania dotyczące dostępności stron internetowych, które wprost odwołują się do WCAG 2.2 jako standardu technicznego. WCAG 3.2.1 On Focus jest kryterium poziomu A, co oznacza, że znajduje się na podstawowym poziomie obowiązkowej zgodności na mocy okólnika. Nie ma żadnych zwolnień dla kryteriów poziomu A — wszystkie podmioty objęte zakresem muszą je spełnić w określonych terminach.

Instytucje publiczne są zobowiązane do osiągnięcia pełnej zgodności w ciągu jednego roku od daty publikacji okólnika. Podmioty prywatne objęte zakresem mają na to dwa lata. Podmioty objęte Prezydenckim Okólnikiem 2025/10 obejmują szeroką gamę organizacji: wszystkie instytucje i agencje publiczne, platformy e-commerce i rynki internetowe, banki i instytucje finansowe, szpitale i prywatnych świadczeniodawców opieki zdrowotnej, firmy telekomunikacyjne z 200,000 lub większą liczbą abonentów, biura podróży i platformy rezerwacyjne, prywatne firmy transportowe oraz prywatne szkoły i placówki edukacyjne upoważnione przez Ministerstwo Edukacji Narodowej (MoNE).

Znaczenie WCAG 3.2.1 On Focus dla tych typów podmiotów jest bezpośrednie i praktyczne. Rozważmy platformę e-commerce, na której rozwijane menu kategorii produktów automatycznie nawiguję po ustawieniu fokusu — klient korzystający z klawiatury z niepełnosprawnością ruchową nie może przeglądać kategorii produktów i porzuci zakup. Formularz przelewu online banku z wysyłaniem wywoływanym przez fokus może powodować niezamierzone transakcje finansowe lub powtarzające się nieudane próby dla użytkowników czytników ekranu. System rezerwacji wizyt w szpitalu, w którym pola daty otwierają modale po ustawieniu fokusu, może uniemożliwić osobom z niepełnosprawnościami samodzielne umawianie się na opiekę.

Zgodnie z okólnikiem, brak zgodności naraża podmioty objęte zakresem na sankcje administracyjne i ryzyko reputacyjne. Dla podmiotów będących obecnie w trakcie transformacji cyfrowej lub nabywających nowe systemy internetowe, uwzględnienie zgodności z WCAG 3.2.1 w wymaganiach przetargowych i wytycznych dla deweloperów już teraz — zamiast wprowadzania poprawek po złożeniu skargi — jest zarówno bardziej opłacalne, jak i lepiej zgodne z duchem regulacji. Organizacje korzystające z Accsible overlay SDK korzystają z wbudowanych narzędzi zarządzania fokusem, które pomagają identyfikować i usuwać nieoczekiwane zachowania związane z fokusem jako część szerszego procesu zapewniania zgodności z WCAG 2.2 na poziomie A.