Zarządzanie fokusem

Fokus klawiatury wskazuje element, który przyjmuje działania użytkownika; osoba korzystająca z klawiatury widzi go jako wyróżnioną ramkę i przesuwa klawiszem Tab. Czytnik ekranu ma własny fokus, który użytkownik przesuwa gestami lub klawiszami i słyszy zamiast widzieć. Oba często stoją na tym samym elemencie, ale czytnik odczyta też tekst, do którego fokus klawiatury nigdy nie trafia. Gdy nic na ekranie się nie zmienia, kolejność fokusu wynika z kolejności elementów w kodzie. Zarządzanie fokusem dotyczy chwil, w których ekran się zmienia: ładuje się nowa strona, otwiera się okno dialogowe, treść zostaje dodana lub usunięta albo pojawia się błąd.

W każdej takiej chwili aplikacja musi celowo gdzieś ustawić fokus. Jeśli tego nie zrobi, zgaduje platforma. Na stronie internetowej fokus może zostać na przycisku, którego już nie ma, i wrócić na początek dokumentu. W aplikacji mobilnej czytnik ekranu może trafić na pierwszy znaleziony element, często przycisk na pasku narzędzi zamiast tytułu ekranu. Użytkownik musi wtedy przeszukać ekran, żeby dowiedzieć się, co się stało.

Najwięcej uwagi wymagają okna dialogowe. Wzorzec modalnego okna dialogowego z W3C ARIA Authoring Practices Guide opisuje trzy zachowania: gdy okno modalne się otwiera, fokus przechodzi do niego; dopóki jest otwarte, fokus zostaje w środku i nie dociera do strony pod spodem; gdy się zamyka, fokus wraca do elementu, który je otworzył, zwykle do naciśniętego przycisku. W przeglądarce aria-modal i natywny element dialog otwierany metodą showModal() pomagają utrzymać czytnik ekranu w oknie. Na iOS odpowiednikiem jest właściwość accessibilityViewIsModal, a na Androidzie treść za oknem można ukryć przed TalkBackiem za pomocą importantForAccessibility.

Problemy z fokusem rzadko widać na zrzutach ekranu i w przeglądach projektu, bo kryją się w przejściach. Wymagania dla zamawianej aplikacji:

• Dla każdego ekranu projekt określa, gdzie trafia fokus po wejściu: zwykle na nagłówek ekranu albo na przycisk wstecz, jeśli tego oczekuje konwencja platformy.
• Po czynności, która zmienia ekran, np. wysłaniu formularza, fokus przechodzi do wyniku: nagłówka potwierdzenia albo pierwszego pola z błędem.
• Każde okno dialogowe działa według tych samych zasad: fokus wchodzi, zostaje w środku i wraca do przycisku, który je otworzył. Buduje się to raz, we wspólnym komponencie, i testuje na każdej platformie.
• Treść, która pojawia się bez działania użytkownika, np. pasek postępu albo odliczanie, jest ogłaszana jako komunikat o stanie, a nie przejmuje fokusu.
• Strony z przyklejonym nagłówkiem albo banerem cookies lub czatu są sprawdzane klawiaturą, bo te elementy mogą zasłonić pole z fokusem.
• Testy obejmują klawiaturę i czytnik ekranu na każdej platformie. Poprawka, która działa na Androidzie, może zawieść na iOS, więc retesty obejmują obie.

W aplikacji mobilnej Centrum Komunikacji, zbudowanej w React Native dla osób głuchych, słabosłyszących, niewidomych i głuchoniewidomych, w sierpniu 2026 r. ustaliliśmy, że właściwość accessibilityViewIsModal ustawiona na komponencie Modal z React Native nigdy nie docierała do widoku natywnego. Modal przekazuje dalej tylko wymienione w nim właściwości, a tej wśród nich nie było. Okno wyboru źródła pliku było wyświetlane jako przezroczysta nakładka (styl prezentacji overFullScreen), przy której ekran pod spodem zostaje w drzewie dostępności. Nasza analiza drzewa komponentów wykazała za oknem 25 kontrolek dostępnych dla VoiceOvera, w tym menu i powiadomienia, a w samym oknie 4. Tło okna i tak było w pełni nieprzezroczyste, więc przełączyliśmy je na styl fullScreen, w którym iOS sam usuwa ekran pod spodem z drzewa dostępności, i usunęliśmy martwą właściwość z trzech komponentów, które jej używały. Analiza obejmowała tylko drzewo Reacta, więc przed scaleniem zmian poprosiliśmy o test na fizycznym urządzeniu z VoiceOverem.

We wrześniu 2026 r. niewidomy ekspert ds. dostępności, testując aplikację produkcyjną, zgłosił, że fokus na ekranie usługi zaczynał się od przycisku zamówienia, a użytkownicy oczekują go na górze ekranu. Po poprawce fokus na ostatnim ekranie zamawiania trafiał na przycisk rozmiaru tekstu zamiast na nagłówek zamówienie przyjęte, więc zmiana przeszła kolejną rundę poprawek i retestów.

W projekcie dla PSONI testy mobilne Generatora ETR we wrześniu i październiku 2026 r. wykazały, że po otwarciu dokumentu fokus przeskakiwał na przycisk zamknięcia zamiast na tekst, a podczas wgrywania pliku trafiał na nagłówek strony zamiast na informację o postępie. Te punkty są częścią mobilnej rundy z czytnikiem ekranu, która wciąż jest w testach.