Wróć do wszystkich kryteriów

3.2.1 Przy fokusie (ang.) On focus

Specjalizacje:

  • Designer
  • Deweloper

Elementy:

  • Dialogi i warstwy
  • Formularze
  • Przyciski i kontrolki

Poziomy:

  • A

Spis treści

    Istota i cel kryterium

    Gwarancja stabilności oraz pełnej przewidywalności interfejsu stanowi absolutny fundament bezpiecznej i przyjaznej przestrzeni cyfrowej. Niniejsze kryterium sukcesu jednoznacznie zakazuje inicjowania jakichkolwiek niespodziewanych, radykalnych zmian w strukturze lub zachowaniu witryny w momencie, gdy dany komponent interaktywny otrzyma fokus. Pełna kontrola zachowań nad aplikacją przez użytkownika – to klucz do zrozumienia kryterium.

    Sam fakt przemieszczania się po elementach strony nie może automatycznie wywoływać akcji. Każda operacja musi wynikać wyłącznie ze świadomej decyzji odbiorcy. Pamiętaj, że najechanie fokusem oznacza wyłącznie gotowość do wejścia w interakcję, a nie jej natychmiastowe, wymuszone uruchomienie. Całkowicie losowa i chaotyczna nawigacja będąca skutkiem niekontrolowanych skryptów to najpoważniejsze uchybienie projektowe, które drastycznie niszczy doświadczenie użytkownika.

    Definicja w j. angielskim

    Definicja dostępna pod adresem (link otworzy się w nowej karcie):
    https://www.w3.org/WAI/WCAG22/quickref/#on-focus

    Definicja w j. polskim

    Definicja dostępna pod adresem (link otworzy się w nowej karcie):
    https://www.w3.org/Translations/WCAG21-pl/#po-otrzymaniu-fokusu

    Słownik pojęć

    Fokus (ang.) focus
    –

    stan aktywnego wyróżnienia elementu interfejsu (takiego jak odnośnik, przycisk czy pole formularza), który wskazuje gotowość komponentu na przyjęcie akcji lub danych wprowadzanych przez użytkownika.

    Zmiana kontekstu (ang.) change of context
    –

    to istotna i głęboka modyfikacja zawartości bądź działania strony, która gwałtownie przekształca środowisko użytkownika. Do tej kategorii zaliczasz przejście do nowej podstrony, przeniesienie punktu uwagi na inny komponent, automatyczne przeładowanie danych, nieoczekiwane otwarcie wyskakującego okna czy zmianę celu albo funkcji samego komponentu.

    Wpływ na dostępność (Kogo wspierasz?)

    • Osoby z dysfunkcjami poznawczymi: Eliminujesz przeciążenie poznawcze oraz frustrację wynikającą z niespodziewanych przeskoków, dając im komfort niezbędny do bezbłędnego ukończenia zadań.
    • Użytkowników nawigujących wyłącznie klawiaturą: Zapewniasz im stabilne środowisko podczas korzystania z klawiszy Tab oraz Shift+Tab. Dzięki temu eliminujesz ryzyko przypadkowego wysłania formularza czy wymuszonego otwarcia nowego okna.
    • Użytkowników czytników ekranu: Chronisz ich przed nagłym i całkowicie dezorientującym odczytywaniem nowych, nieoczekiwanych sekcji. Nagła transformacja interfejsu odcina użytkowników od nawigacji i całkowicie niszczy ich orientację w treści.
    • Użytkowników słabowidzących korzystających z powiększenia ekranowego: Zapobiegasz sytuacji, w której kluczowe komponenty nagle przesuwają się daleko poza aktywny obszar widzenia na skutek nieprzewidywalnej zmiany układu strony.

    Zasady wdrażania i wymagania techniczne

    • Kategorycznie zablokuj automatyczne przesyłanie formularzy: Zadbaj o to, aby przejście fokusem na pole tekstowe lub inny komponent edycyjny nigdy nie uruchamiało wysyłki danych. Każdą operację przekazania informacji do bazy danych uzależniaj wyłącznie od świadomej aktywacji przycisku zatwierdzającego przez użytkownika.
    • Unikaj samoczynnego otwierania nowych okien lub kart: Wyeliminuj stosowanie instrukcji window.open() bezpośrednio wewnątrz zdarzenia onfocus odnośnika – to krytyczny błąd projektowy. Nowe przestrzenie przeglądarki otwieraj tylko i wyłącznie po pełnej, celowej aktywacji elementu (np. po kliknięciu lub wciśnięciu klawisza Enter).
    • Wyeliminuj agresywną przebudowę drzewa DOM: Zrezygnuj z dynamicznego ukrywania elementów, dodawania dużych bloków tekstu czy automatycznego odświeżania zawartości strony. Żadna z tych operacji nie ma prawa zaistnieć tylko dlatego, że użytkownik przeniósł fokus na dany element nawigacyjny.
    • Kontroluj zachowanie dynamicznych widżetów: Projektuj komponenty takie jak listy rozwijane <select> czy mechanizmy autouzupełniania ((ang.) autocomplete) tak, aby wyświetlały zestaw opcji po otrzymaniu fokusu, lecz nigdy nie wymuszały natychmiastowego wyboru wartości ani przeładowania podstrony przed decyzją użytkownika.
    • Oddzielaj wyrazistość wizualną od akcji systemowych: Wykorzystuj zmianę stylu elementu po uzyskaniu fokusu (np. dodanie ramki czy zmianę tła) wyłącznie do celów orientacji przestrzennej. Pod żadnym pozorem nie łącz tych modyfikacji estetycznych z uruchamianiem skryptów, które zmieniają kontekst strony.

    Wyjątki i sytuacje szczególne

    Standard wyznacza precyzyjne granice, dopuszczając specyficzne zachowania elementów interaktywnych, które nie łamią zasad dostępności:

    • Sygnalizacja estetyczna: Wykorzystuj swobodnie wszelkie zmiany graficzne (np. modyfikację kontrastu czy pojawienie się obrysu). Te modyfikacje stanowią oczekiwaną informację zwrotną i pomagają użytkownikowi w nawigacji, więc reguła ich nie ogranicza.
    • Prezentacja list i podpowiedzi: Wyświetlaj zestaw dostępnych opcji w elemencie rozwijanym lub menu podręcznym w odpowiedzi na fokus. Działanie to jest w pełni legalne, ponieważ nie zmienia całego kontekstu – pod warunkiem, że zablokujesz automatyczne zatwierdzanie wartości bez udziału użytkownika.

    Przykłady implementacji

    Najczęstsze błędy

    • F55: Stosowanie skryptu, który usuwa fokus z elementu natychmiast po jego otrzymaniu, co uniemożliwia użytkownikowi dostrzeżenie wskaźnika fokusu oraz całkowicie blokuje interakcję klawiaturową.
    • Automatyczne uruchamianie okien dialogowych pomocy ((ang.) help dialogs) w momencie, gdy pole formularza otrzyma fokus. Taki zabieg kradnie punkt uwagi, przenosi fokus w nowe miejsce i uniemożliwia użytkownikowi dalsze przechodzenie po stronie za pomocą klawisza Tab.
    • Angażowanie zdarzenia onfocus w skryptach JavaScript do realizowania operacji modyfikujących układ strony lub podmieniających kluczowe bloki informacyjne bez wyraźnego polecenia użytkownika.
    • Konstruowanie formularzy, które uruchamiają procedurę submit automatycznie po przejściu użytkownika klawiatury do pola tekstowego, przez co odbierasz mu szansę na wprowadzenie jakichkolwiek danych.
    • Inicjowanie otwierania nowych kart przeglądarki bezpośrednio w reakcji na pojawienie się fokusu na odnośniku, zamiast czekać na jego kliknięcie lub zatwierdzenie.

    Najlepsze praktyki

    • Bezkompromisowo rozróżniaj intencję badania od intencji wykonania akcji: Traktuj przesunięcie fokusu wyłącznie jako akt eksploracji i zapoznawania się z elementem. Zostaw użytkownikowi czas na analizę, a właściwe operacje przypisuj wyłącznie pod zdarzenie click lub naciśnięcie klawiszy Enter i Spacja.
    • Zachowaj szczególną ostrożność z atrybutem autofocus: Stosuj automatyczne nadawanie fokusu z ogromnym umiarem. Jeśli użyjesz go na elemencie, który nie jest oczekiwany jako pierwszy punkt interakcji, całkowicie zniszczysz ścieżkę nawigacji osób korzystających z technologii wspomagających. Ograniczaj go do uzasadnionych przypadków (np. pole wyszukiwania na dedykowanej stronie wyszukiwarki).
    • Wykorzystuj atrybuty ARIA do komunikowania zmian stanów: Implementuj właściwości takie jak aria-expanded czy aria-live do informowania technologii wspomagających o dynamicznych zmianach – pamiętaj jednak, aby aktywować je wyłącznie po faktycznym zatwierdzeniu przycisku, a nie po samym fokusie.
    • Zabezpieczaj i precyzyjnie opisuj świadomie otwierane odnośniki: Kiedy projektujesz link uruchamiający nową kartę poprzez atrybut target="_blank", zawsze przekaż jasne ostrzeżenie tekstowe lub użyj atrybutu title. Dodatkowo obowiązkowo zastosuj deklarację rel="noopener noreferrer" w celu ochrony bezpieczeństwa.

    Metody testowania

    • Narzędzie deweloperskie (ang.) Developer Tools: Otwórz drzewo strukturalne podglądu kodu i drobiazgowo przeanalizuj zdarzenia przypisane do elementów interaktywnych. Upewnij się, że nie zaimplementowano tam skryptów reagujących na zdarzenie onfocus, które wymuszają przeładowanie zawartości, usuwanie punktu uwagi lub automatyczną wysyłkę formularza.
    • NVDA: Uruchom czytnik ekranu i wykonaj pełne przejście po wszystkich aktywnych komponentach witryny za pomocą klawisza Tab. Sprawdź, czy syntezator mowy nie zaczyna nagle odczytywać nieoczekiwanych komunikatów z innych części serwisu i czy nie dochodzi do wymuszonych przeskoków bez Twojej wiedzy.

    Sprawdź swoją wiedzę

    W linku poniżej znajduje się 6 interaktywnych przykładów. Twoim zadaniem jest nawigowanie po nich za pomocą klawiatury (używając klawisza Tab) i ocena, czy zachowują się one zgodnie z kryterium 3.2.1.

    Jak to sprawdzić?

    1. Używaj wyłącznie klawiszaTab, aby przenosić fokus na kolejne elementy.
    2. Obserwuj, co dzieje się w momencie, gdy element otrzymuje fokus (zanim cokolwiek klikniesz lub wciśniesz Enter).
    3. Zwróć uwagę na niespodziewane zmiany kontekstu: automatyczne wysyłanie formularzy, otwieranie nowych okien, nagłe zmiany układu strony.
    4. Pamiętaj, że zmiany czysto wizualne (np. pojawienie się ramki, zmiana koloru) lub wyświetlenie podpowiedzi są dozwolone.

    Notatka: Zanim zajrzysz do rozwiązania, przetestuj i zapisz swoje wnioski na kartce.
    Proponowane narzędzia: Klawiatura (Tab, Shift + Tab), Narzędzie deweloperskie (ang.) Developer Tools

    Link: https://pdc.ambiscale.com/training/wcag-3-2-1/

    #1 BŁĄD

    Problem: Zastosowano technikę F55. Skrypt usuwa fokus z elementu (wywołuje blur()) natychmiast po jego otrzymaniu.
    Dlaczego: Uniemożliwia to użytkownikowi dostrzeżenie wskaźnika fokusu oraz całkowicie blokuje interakcję klawiaturową (nie da się wpisać tekstu do pola).
    Naprawa: Usuń skrypt wywołujący blur() w obsłudze zdarzenia focus. Pozwól przeglądarce naturalnie zarządzać fokusem.

    #2 BŁĄD

    Problem: Przeniesienie fokusu na odnośnik automatycznie otwiera nowe okno przeglądarki (lub wywołuje okno dialogowe/alert).
    Dlaczego: Jest to drastyczna zmiana kontekstu. Użytkownik nawigujący klawiaturą zostaje wyrwany ze swojego środowiska bez żadnego ostrzeżenia i bez własnej woli.
    Naprawa: Otwieranie nowych okien przypisuj wyłącznie do zdarzenia click (które obsługuje również klawisz Enter), a nie focus.

    #3 BŁĄD

    Problem: Skonstruowano formularz, który uruchamia procedurę submit automatycznie po przejściu użytkownika klawiatury do pola wyboru (select).
    Dlaczego: Odbierasz użytkownikowi szansę na zapoznanie się z opcjami i dokonanie wyboru. Zmiana kontekstu (wysłanie danych) następuje przedwcześnie.
    Naprawa: Zawsze wymagaj świadomego potwierdzenia (np. przycisku „Wyślij” lub zatwierdzenia klawiszem Enter).

    #4 DOBRZE

    Dlaczego: Przycisk po otrzymaniu fokusu agresywnie zmienia swój wygląd (kolor, obramowanie, powiększenie). Jest to jednak w pełni dozwolone, ponieważ są to wyłącznie zmiany wizualne (sygnalizacja estetyczna). Nie dochodzi do zmiany kontekstu, a użytkownik dostaje wyraźną informację zwrotną, gdzie aktualnie się znajduje.

    #5 DOBRZE

    Dlaczego: Wyświetlanie dodatkowych informacji (tooltipów, menu rozwijanych) w momencie otrzymania fokusu jest zgodne z kryterium 3.2.1. Warunkiem jest to, że pojawienie się podpowiedzi nie kradnie fokusu, nie przesuwa go w inne miejsce i nie przeładowuje strony.

    #6 BŁĄD

    Problem: Agresywna przebudowa drzewa DOM. Po najechaniu fokusem na przycisk, zawartość kontenera zostaje całkowicie podmieniona na komunikat błędu.
    Dlaczego: Żadna operacja modyfikująca układ strony lub podmieniająca kluczowe bloki informacyjne nie ma prawa zaistnieć tylko dlatego, że użytkownik przeniósł fokus na dany element nawigacyjny.
    Naprawa: Takie akcje powinny być wywoływane wyłącznie intencjonalnie, po aktywacji przycisku (kliknięcie / Enter).

    Źródła

    Dodatkowe linki

    Wróć do wszystkich kryteriów